ASA Failover - problem with remote VPN connections when failover occurs

Unanswered Question
Sep 16th, 2008
User Badges:

We have a primary ASA5540 at our head office which provides our main site internet connection and terminates all the IPSEC VPNs to our remote sites.

We also have a secondary ASA5540 at our “failover” site where we have another internet pipe. The idea being that, if there is a problem with our main internet pipe or primary ASA, comms will failover to the secondary ASA and we will still have connectivity.

The head office and failover sites are a few miles apart and are connected by a LES (LAN Extension Service) circuit. We have a core switch at each site with an isolated “failover” VLAN configured for the connections between the 2 ASA firewalls. The switch ports are configured with “spanning-tree portfast” enabled and trunking disabled ("switchport mode access")

The issue we are facing is that, whenever a failover occurs (e.g. if main internet pipe goes down) then the failover to the secondary unit happens but we seem to lose connectivity with all our remote offices.

I have attached a diagram to show the basic set-up and also included the "show run failover" and "show failover" output (with IP addresses removed) from each unit.

Does anyone have any suggestions as to what the issue might be and how we can set this up so that all connectivity (including remote VPN connections) will resume when a failover occurs?

It's also a difficult one to troubleshoot as we need downtime in order to test it (as all remote sites connect over the primary internet pipe) - if we organise a test window, can anyone suggest the best debugging/troubleshooting commands to run in order to help us resolve the issue?

Any help/advice on this one would be greatly appreciated!


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (2 ratings)
Marwan ALshawi Tue, 09/16/2008 - 04:55
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

as long as u are runing active/standby NOT active/active failover mode then u can use stateful failover to support IPsec vpn

and u need to consider stateful failover on ur firewalls

have alook at the following link which is very helpful :

for show and debuge use:

show failover

show failover | include Failed

debug fo ?

exec mode commands/options:

cable Failover LAN status

fail Failover internal exception

fmsg Failover message

ifc Network interface status trace

open Failover device open

rx Failover Message receive

rxdmp Failover recv message dump (serial console only)

rxip IP network failover packet recv

switch Failover Switching status

sync Failover config/command replication

tx Failover Message xmit

txdmp Failover xmit message dump (serial console only)

txip IP network failover packet xmit

verify Failover message verify

To troubleshoot issues related to failover timing, use the debug fo rxip and debug fo txip commands to determine if the packets are being exchanged according to the configured polltimes

good luck

if helpful Rate

mitchen Tue, 09/16/2008 - 06:01
User Badges:

Thanks - I'll have a look at some of those commands you've suggested.

As far as the stateful failover is concerned, I believe we have that configured already:

failover interface ip failover *.*.*.1 *.*.*.* standby *.*.*.2

Any further advice/suggestions would be welcome!

Marwan ALshawi Tue, 09/16/2008 - 06:10
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

if u are not concerned too much about the session get disconnected and reconnected again

on the remote routers u can make another crypto map with the same name but higher sequence number includ the same interesting traffic and other option except the set peer command which will be the secondary ASA

so u will have one crypto map on each remote router with two sequence numbers fist map with lower sequence number point to ASA 1 and the second one point to the secondary ASA

but this way one ASA one or its link gos down the remote routers will re intiate the tunnel again to the second one when they get interesting traffic

and works even without failover this way

good luck

if helpful Rate

if helpful Rate

mitchen Tue, 09/16/2008 - 08:26
User Badges:

Thanks for the further suggestion.

I wouldn't be too concerned about the sessions disconnecting and reconnecting again (as long as it was for a reasonably short time period)

However, unless I've not quite understood things correctly, I'm not sure your suggestion would work with our set-up. Because, with failover, the ASA devices "share" the same IP addresses (so the secondary ASA would take over the primary's IP addresses in a failover situation) which would mean configuring a second peer in the remote router would have no effect.

If we disabled failover and just included the secondary ASA as an alternative peer on the remote routers, I still don't think it would help as a) our head office users would still lose their internet access if the primary internet pipe failed (since no failover) and b) the routing back out to the remote offices would fail since head office devices would still be routing to the primary ASA.

mitchen Fri, 10/24/2008 - 07:51
User Badges:

Just in case anyone is suffering a similar problem, this turned out to be a Cisco software bug. We were running 7.2(4) when we experienced the failover problem but upgraded to 7.2(4)9 and this resolved the issue.

The related bugs seem to have been:

CSCsl52895 - ASA 7.2.3 number of IPSec SA not replicated in failover unit.

CSCsl82200 - IPSec not encrypting after failover

broeder Mon, 03/09/2009 - 07:34
User Badges:

There is also another bug to be aware of: search for CSCsi18736 in the bug toolkit.

hope this helps

Richard Clayton Mon, 03/29/2010 - 06:35
User Badges:

Failover does not work properly over LES circuits, it has something to do with the switches in the provider not coping with the mac address swap

mitchen Mon, 03/29/2010 - 06:58
User Badges:

Thats interesting, do you have any more information on that?

Our failover seems to work ok now and we are still using LES circuits.  However, I've never been completely convinced by it!


This Discussion