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.
Did you configure DPD at both ends of the tunnel? The settings should be something like this
isakmp keepalive threshold 10 retry 2
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??)
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?
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :