ASA Site-to-Site VPN Failover “Preemption”

In this post I will show you how to configure Cisco ASA site-to-site VPN failover. As we know, Cisco ASA IPsec site-to-site VPN preemption is not supported on Cisco ASA. Therefore, this means if the primary VPN peer recovers from a failure the VPN tunnel will remain active with the secondary VPN peer.

In other words, if you configure a site-to-site VPN tunnel crypto map with two peers, one as the primary, and another as the secondary, the ASA will always try to initiate the tunnel with the primary peer first. If the primary peer fails and become unreachable, then the ASA will initiate the tunnel with the secondary peer.

When the primary peer comes back online, the ASA will not do anything, as long as the secondary peer is reachable. In other words, the primary peer will not take over the control from the secondary, instead the tunnel will remain initiated with the secondary peer.

In some cases, this would cause performance issues, or even productivity issues. Let’s assume the following scenario. Say we have two sites, one is a primary with our production environment, and another as a disaster recovery site with a limited production environment.

Or, let’s assume that we have same data replica across both the primary and the disaster recovery sites, but the secondary VPN peer connected to the disaster recovery site has less resources over the primary. Or maybe the WAN connection where the secondary peer is connected is much slower than the primary site. let’s see together how we can apply a workaround to get the Cisco ASA IPsec site-to-site VPN preemption to work.

 

Recommendation

 

For Cisco ASA IPsec site-to-site VPN preemption Cisco recommends configuring a SLA monitor to keep track of the primary peer IP address and creating a conditional route of the primary peer IP address tied to the SLA monitor. Then, to create an EEM applet to trigger the command “clear crypto ipsec sa peer <the secondary peer IP address>”. However, this command must be run only after the  the message ID 622001 is seen twice on the ASA. More about message ID 622001 below.

The command in itself will clear the tunnel with the secondary peer and as a result it will re-initiate the tunnel with the primary peer.

 

Message ID 622001

 

The message ID 622001 is generated every time the ASA adds or removes a route from its routing table. In our example, this means the ASA will generate the first message ID 622001 when the primary peer fails, and another message ID 622001 when the primary peer comes back online.

The message ID 622001 looks similar to these:

 

Or

 

Issue

 

The problem with that recommendation would arise if you have multiple conditional routes on the ASA that are tied to multiple SLA monitors. The reason behind this, is because as mentioned above every time the ASA adds or removes a route from/to its routing table, it will generate a message ID 622001. Therefore, the ASA will not make any distinction between which routes could cause the message ID 622001 generation.

As a result, the EEM applet would trigger the command to clear the VPN tunnel with no valid reason or even when it is not required. In other words, the EEM will trigger the clear crypto ipsec command each time the ASA generates two message ID 622001. That happens regardless of which conditional route has been added or removed to the ASA routing table.

 

Solution

 

Here is a workaround to make the ASA always initiate the VPN tunnel with the primary peer, as long as it is reachable. What I would do is configuring a SLA monitor, checking the availability of the primary peer, and creating a conditional route for the secondary peer pointing to a dummy next hop.

This means that as long as the primary peer IP address is reachable, the secondary peer IP route will always be installed in the routing table pointing to a fake next hop. In other words the secondary peer IP will never be reachable as long as the primary peer IP is alive.

When the primary peer fails, the track of the SLA monitor will cause the removal of the conditional route of the secondary peer that was pointing to the dummy next hop. As a result, now the route that will be used to reach the secondary peer will be the default route configured on the ASA.

When the primary peer comes back online, the SLA monitor will go again in UP state, and it will trigger the installation of the secondary peer route again. So, the ASA will add back the fake next hop route into its routing table to reach the secondary peer.

According to those route removals and additions, the VPN tunnel will automatically switch between the peers. When the primary peer is reachable, the VPN tunnel will always be initiated with the primary peer. And when the primary peer is unreachable, the VPN tunnel will be initiated with the secondary peer.

Here is the topology and the configuration I have used in my lab to prove this.

 

Topology

 

 

ASA IPsec Site-to-Site VPN Preemption Configuration

 

asav-1:

 

asav-2:

 

 

asav-3:

 

 

Verification

 

First, let’s very the VPN tunnel on the HQ-ASA:

 

 

Now, let’s break the link with the primary peer and see what happens:

 

As you can see, after the VPN tunnel with the primary timed out the ASA reinitiated the tunnel with the secondary peer:
 

 

Here is after we re-enabled the link with the primary peer:
 

 

Because the secondary peer is now not reachable anymore due to the fake next hop we have on the conditional router, the VPN tunnel with the secondary peer timed out and the ASA reinitiated the tunnel with the primary peer:
 

 

   If you are wondering how I could use the ? in the pre-shared key for the VPN tunnels, then here is the trick: When you type a pre-shared key, and you want to use the ? as a character, it would be enough to type ctrl+v right before typing the ? and then you continue typing the rest of the pre-shared key. That is valid on the ASA for anywhere you might need to use the ? as a normal character, not only for pre-shared keys.

This wraps up this post about Cisco ASA site-to-site VPN failover. I hope you enjoyed reading this post, and as always, I would love to hear your feedback.

 

Thanks for reading!