09-28-2006 11:54 PM - edited 03-03-2019 02:10 PM
Hi,
I have a VPN session which is working good.
For some reason there was some trouble at some ISP between the two VPN peers and the packets are not passing to two VPN peers.
The ISP problem has been for more than 8 hrs, but my doubt is that, when I check the peer crypto session details, it is UP-ACTIVE now also.
Why the session is not going down once three keepalive packets are missed, and why not IPSec termination point not concludes that it has lot connectivity with its peer?
I have given the command:
crypto isakmp keepalive 30 periodic
crypto ipsec security-association lifetime seconds 86400
aaa#show cry session remote A.B.C.24 detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: GigabitEthernet0/1
Session status: UP-ACTIVE
Peer: A.B.C.24 port 500 fvrf: (none) ivrf: (none)
Desc: Tunnel toA.B.C.24 (AAA)
Phase1_id: A.B.C.24
IKE SA: local P.Q.R.1/500 remote A.B.C.24/500 Active
Capabilities:(none) connid:269 lifetime:21:53:23
IPSEC FLOW: permit ip 172.17.12.0/255.255.255.0 10.11.6.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 1254709 drop 1 life (KB/Sec) 4449894/78804
Outbound: #pkts enc'ed 1330421 drop 2989 life (KB/Sec) 4449877/78804
aaa#show cry isa sa
dst src state conn-id slot status
A.B.C.24 P.Q.R.1 QM_IDLE 269 0 ACTIVE
aaa#ping 10.11.6.18 source 172.17.12.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.11.6.18, timeout is 2 seconds:
Packet sent with a source address of 172.17.12.11
.....
Success rate is 0 percent (0/5)
aaa#
aaa#ping A.B.C.24
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to A.B.C.24, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
aaa#
09-29-2006 02:51 AM
Hi
Can you post out the config of both the routers?
regds
10-01-2006 06:23 PM
Hi,
VPN is working good.
The problem is that the VPN session is not expiring, when three keepalive packets are missed and IPSec termination point is not concluding that it has lot connectivity with its peer.
Why is it so?
My end vpn router config details is below, other end vpn box is not cisco.
version 12.4
ip cef
ip sla monitor logging traps
ip sla monitor 21
type echo protocol ipIcmpEcho 10.11.6.10 source-interface GigabitEthernet0/0
ip sla monitor schedule 21 life forever start-time now
crypto logging session
crypto isakmp policy 2
encr 3des
authentication pre-share
group 2
crypto isakmp key xxxxxxxxxx address A.B.C.24 255.255.255.240 no-xauth
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 30 periodic
crypto isakmp nat keepalive 30
crypto isakmp peer address A.B.C.24
description Tunnel toA.B.C.24 ()
crypto ipsec security-association lifetime seconds 86400
crypto ipsec transform-set vpnset esp-3des esp-sha-hmac
crypto ipsec df-bit clear
no crypto ipsec nat-transparency udp-encaps
crypto map vpnmap1 redundancy replay-interval inbound 10 outbound 1000
crypto map vpnmap1 27 ipsec-isakmp
description Tunnel toA.B.C.24()
set peer A.B.C.24
set transform-set vpnset
match address 130
interface Null0
no ip unreachables
interface GigabitEthernet0/0
description LAN
ip address 172.17.12.11 255.255.255.0
ip access-group 100 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat inside
ip virtual-reassembly
no ip route-cache cef
ip route-cache flow
ip tcp adjust-mss 1376
duplex auto
speed auto
no mop enabled
standby version 2
standby 10 ip 172.17.12.10
standby 10 timers 1 10
standby 10 priority 105
standby 10 preempt
standby 10 name vpn-in
standby 10 track GigabitEthernet0/1
standby 10 track GigabitEthernet0/0
interface GigabitEthernet0/1
description WAN
ip address P.Q.R.11 255.255.255.192
ip access-group 101 in
ip verify unicast reverse-path
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
ip route-cache flow
duplex auto
speed auto
no mop enabled
standby version 2
standby 20 ip P.Q.R.1
standby 20 timers 1 10
standby 20 priority 105
standby 20 preempt
standby 20 name vpn-out
standby 20 track GigabitEthernet0/1
standby 20 track GigabitEthernet0/0
crypto map vpnmap1 redundancy vpn-out stateful
ip route 0.0.0.0 0.0.0.0 P.Q.R.1
ip route 10.11.6.0 255.255.255.0 GigabitEthernet0/1
ip nat Stateful id 20
redundancy vpn-out
mapping-id 20
as-queuing disable
protocol udp
ip nat pool nat-out-pool P.Q.R.11 P.Q.R.11 prefix-length 26
ip nat inside source route-map vpn_rmap1 pool nat-out-pool mapping-id 20 overload
logging trap debugging
access-list 100 deny ip P.Q.R.0 0.0.0.255 any
access-list 100 deny ip host 255.255.255.255 any
access-list 100 deny ip 127.0.0.0 0.255.255.255 any
access-list 100 permit ip any any
access-list 101 permit icmp any any
access-list 101 remark IPSec Rule
access-list 101 permit udp any P.Q.R.0 0.0.0.255 eq non500-isakmp
access-list 101 permit udp any P.Q.R.0 0.0.0.255 eq isakmp
access-list 101 permit esp any P.Q.R.0 0.0.0.255
access-list 101 permit ahp any P.Q.R.0 0.0.0.255
access-list 101 deny ip any any log
access-list 104 deny ip 172.17.12.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 104 permit ip 172.17.12.0 0.0.0.255 any
access-list 130 remark IPSec -
access-list 130 permit ip 172.17.12.0 0.0.0.255 10.11.6.0 0.0.0.255
route-map vpn_rmap1 permit 1
match ip address 104
end
10-10-2006 07:19 PM
crypto isakmp keepalive 30 periodic
crypto ipsec security-association lifetime seconds 86400
Your problem is above. The periodic command does not work correctly and is unreliable.
Go back to only "cry is keepalive 30" and it will be fine.
10-11-2006 05:33 PM
Hi,
Thank you very much for the reply.
Is there any bug in the command "crypto isakmp keepalive 30 periodic"?
Problem is that cisco never re-establishes the tunnel within the assigned lifetime 86400.
If the other end peer?s tunnel got broken within 86400 and it tries to re-establish the connection, Cisco is not re-establishing it and our network is down for so many hours, till Cisco automatically re-establish the connections after its lifetime 86400.
How to solve this problem?
Cisco doc says:
The IPSec Dead Peer Detection Periodic Message Option feature allows you to configure your router to query the liveliness of its Internet Key Exchange (IKE) peer at regular intervals. The benefit of this approach over the default approach (on-demand dead peer detection) is earlier detection of dead peers.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide