ASA 8.0 Site to Site IPSEC Tunnel Stalls

Unanswered Question
Mar 7th, 2009

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
oabduo983 Sat, 03/07/2009 - 14:21

Is it possible to paste the configuration of your Firewalls and router?

thanks and regards,

JamesLuther Sun, 03/08/2009 - 05:54

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

stevenlau Sun, 03/08/2009 - 07:50

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!

JamesLuther Sun, 03/08/2009 - 09:08

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

stevenlau Sun, 03/08/2009 - 09:46

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.

stevenlau Tue, 03/10/2009 - 11:23

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.

Actions

This Discussion