03-07-2009 05:17 AM - edited 02-21-2020 04:10 PM
Hi,
On my remote end I have a ASA 5505 initiating an IPSEC site to site tunnel to my head end (5540). We have multiple sites connecting to this 5540 with the same exact config at each remote end.
What's different with this particular remote site is the Internet service: it's an ethernet hand-off from a 29xx LRE switch which I have no control over.
Every once in awhile the handoff to me flaps (the iface goes down hard and then 5-10 seconds later comes back up-up).
When this happens, the head end breaks the tunnel as it should, but the remote end does not. I've tried changing the arp cache timeout on the ASA to 60 seconds, adding "isakmp keepalive 10", but to no avail... when the iface flops, the tunnel doesn't break and re-negotiate.
Any suggestions on what I can do?
03-07-2009 02:21 PM
Is it possible to paste the configuration of your Firewalls and router?
thanks and regards,
03-08-2009 05:54 AM
Hi,
Did you configure DPD at both ends of the tunnel? The settings should be something like this
ASA:
isakmp keepalive threshold 10 retry 2
IOS:
crypto isakmp keepalive 10 2
Dead peer detection is suppossed to stop this from happening. In fact it sounds like IOS has detected the tunel was down and deleted the keys however the ASA hasn't?
Also what code versions are you running at both ends?
Another feature that is suppossed to stop this from happening is IKE DELETE messages. IOS should have sent one of these to the ASA when it deleted the SA (however if the line was down maybe it didn't recieve the message??)
Regards
03-08-2009 07:50 AM
Yes, I've tried DPD on both sides.
I'm running ASA's on both sides (5505 remote end and 5540 at the hq) version 8.04.
Relevant config below:
!
!
! DEFINE VPN SITE TO SITE / ACCESS RULES
access-list outside_1_cryptomap extended permit ip [***REMOVED LOCAL NET***] [***REMOVED HEADQUARTER NETS***]
!
! DEFINE VPN SITE TO SITE NAT RULES
access-list inside_nat0_outbound extended permit ip [***REMOVED LOCAL NET***] [***REMOVED HEADQUARTER NETS***]
!
!
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 [***REMOVED LOCAL NET***]
!
!
route outside 0.0.0.0 0.0.0.0 [**REMOVED***] 1
!
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group1
crypto map outside_map 1 set connection-type originate-only
crypto map outside_map 1 set peer [***REMOVED HQ PEER***]
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map 1 set security-association lifetime seconds 28800
crypto map outside_map 1 set security-association lifetime kilobytes 4608000
crypto map outside_map 1 set nat-t-disable
crypto map outside_map interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
!
tunnel-group DefaultRAGroup ipsec-attributes
isakmp keepalive threshold 10 retry 2
tunnel-group DefaultWEBVPNGroup ipsec-attributes
isakmp keepalive threshold 10 retry 2
tunnel-group [***REMOVED HQ PEER***] type ipsec-l2l
tunnel-group [***REMOVED HQ PEER***] ipsec-attributes
pre-shared-key [***REMOVED PSK***]
!
!
Thank you!
03-08-2009 09:08 AM
Hi,
If DPD is enabled on both ends you shouldn't have an issue, so this is an interesting issue.
Perhaps you should try disabling DPD on both ends. In that case both ends should keep their keys even after a network disruption. However if your head end connects to many other sites, this may not be advisable.
If you can arrange some downtime then I would debug both ends and try clearing keys at one end (clear crypto isakmp sa). Restart tunnel and clear keys from the other end. Then also try simulating a link break (maybe with an ACL blocking ESP/IKE so you can still access both ends). Compare all the debugs and what happens to the keys in each scenario, things to try to spot are
If one end is reset does the other clear its keys or carry on trying to use the old keys?
Do you see IKE delete message being sent from either or both ends?
Regards
03-08-2009 09:46 AM
Hi,
Breaking the tunnel from the head end is fine... the remote end re-establishes the tunnel when this happens.
Clearing the keys at the remote-end also re-establishes the tunnel. I might try the latest 8.04 interim release to see if a new version code might help.
Everything works as it should until the interface flap from the ethernet handoff. Since the flapping is so short (5-10 seconds), it appears the remote-end ASA thinks everything is still fine, but DPD isn't kicking in to re-establish the tunnel.
03-10-2009 11:23 AM
I've been able to duplicate the issue in a test lab I've set up.
How it's wired:
[ remote pc ] -> [ remote switch ] - [ remote ASA ] -> [ provider switch ]
Attached is a log of things I did and the resulting log on the ASA. In short:
+ I issued a 'ping inside' command on the ASA to test for end to end connectivity to HQ.
+ Ping is successful
+ I issue a quick shut / no shut on the ethernet iface on the provider switch to my ASA
+ Tunnel breaks on the HQ side
+ Remote ASA appears to remove the tunnel peer
+ Issue 'ping inside' from remote ASA - fails
+ Issue 'clear isakmp sa' - tunnel re-establishes
+ Issue 'ping inside' from remote ASA - success.
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