To wrap up this mini-series on using VPN tunnels as backup links, I want to take a different approach than we have done in the previous articles. In this article, we will consider a scenario where you have two VPN tunnels, but the backup tunnel should only be used when the primary VPN tunnel goes down. This can happen if you are connected to two ISPs and you want to achieve VPN tunnel redundancy.

For this article, I will take it a step further: Both sides of the VPN tunnel will have dual-ISP connection, so we must achieve failover on both sides. The diagram we will be using for this article is shown below:

The GNS topology is as shown below:

Note: This is just a simulation and that’s why I have a router acting as the “Internet”. In real life, the devices will most likely be connected to different routers of different ISPs.

The configuration in this article will be similar to the configuration in the first article of this series, i.e., crypto-map, static routes and SLA tracking. This is because the Cisco ASA does not support GRE tunnels or site-to-site VPN using VTIs.

Let’s begin by configuring SITE-A-ASA. For this article, we will assume that the 41.1.1.0/30 link is the link to the primary ISP and should always be used when available. The 41.1.2.0/30 link should be used as the backup link. To achieve this, we can use SLA tracking on the route pointing to the primary ISP so that the route through the backup ISP will be used when that primary link goes down.

The configuration, including routing and SLA tracking on the ASA is as follows:

hostname SITE-A-ASA
!
interface GigabitEthernet0
 nameif outside-pri
 security-level 0
 ip address 41.1.1.1 255.255.255.252
 no shut
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0
 no shut
!
interface GigabitEthernet3
 nameif outside-bkup
 security-level 0
 ip address 41.1.2.1 255.255.255.252
 no shut
!
sla monitor 1
 type echo protocol ipIcmpEcho 41.1.1.2 interface outside-pri
 frequency 5
sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
!
route outside-pri 0.0.0.0 0.0.0.0 41.1.1.2 track 1
route outside-bkup 0.0.0.0 0.0.0.0 41.1.2.2 10

I have configured my Internet router so if I check the routing table of the ASA, I should see the default route pointing towards the primary link, i.e., 41.1.1.2.

Now let’s configure our NAT rules. Traffic to be encrypted, i.e., 10.10.10.0/24 to 10.10.20.0/24 should be exempted from NAT while all other traffic to the Internet should be translated to the ASA’s public IP address. Since we have two ISPs, we need to do two sets of NAT configuration.

object network inside-network
 subnet 10.10.10.0 255.255.255.0
object network remote-network
 subnet 10.10.20.0 255.255.255.0
!
nat (inside,outside-pri) source static inside-network inside-network destination static remote-network remote-network
nat (inside,outside-pri) source dynamic inside-network interface
!
nat (inside,outside-bkup) source static inside-network inside-network destination static remote-network remote-network
nat (inside,outside-bkup) source dynamic inside-network interface

Let’s finish up the ASA with the VPN configuration. We can use the same crypto-map configuration on the two ISP interfaces and we can also use only one crypto-map entry by specifying two peers in that entry. The configuration is as follows:

crypto ikev1 policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
access-list CRYPTO_ACL extended permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0
!
crypto ipsec ikev1 transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 match address CRYPTO_ACL
crypto map CRYP_MAP 10 set peer 41.2.1.1 41.2.2.1
crypto map CRYP_MAP 10 set ikev1 transform-set TRANS_SET
crypto map CRYP_MAP interface outside-pri
crypto map CRYP_MAP interface outside-bkup
crypto ikev1 enable outside-pri
crypto ikev1 enable outside-bkup
!
tunnel-group 41.2.1.1 type ipsec-l2l
tunnel-group 41.2.1.1 ipsec-attributes
 ikev1 pre-shared-key cisco

tunnel-group 41.2.2.1 type ipsec-l2l
tunnel-group 41.2.2.1 ipsec-attributes
 ikev1 pre-shared-key cisco

Even though I have specified two peer IP addresses (41.2.1.1 and 41.2.2.1), the ASA will establish only one VPN tunnel with the first listed peer IP address if that IP address is reachable. It will attempt to establish a VPN tunnel with the second peer IP address only if the first peer IP address is unreachable.

The configuration on the opposite end of the tunnel is similar, as shown below:

hostname SITE-B-ASA
!
interface GigabitEthernet0
 nameif outside-pri
 security-level 0
 ip address 41.2.1.1 255.255.255.252
 no shut
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 10.10.20.1 255.255.255.0
 no shut
!
interface GigabitEthernet3
 nameif outside-bkup
 security-level 0
 ip address 41.2.2.1 255.255.255.252
 no shut
!
sla monitor 1
 type echo protocol ipIcmpEcho 41.2.1.2 interface outside-pri
 frequency 5
sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
!
route outside-pri 0.0.0.0 0.0.0.0 41.2.1.2 track 1
route outside-bkup 0.0.0.0 0.0.0.0 41.2.2.2 10
!
object network remote-network
 subnet 10.10.10.0 255.255.255.0
object network inside-network
 subnet 10.10.20.0 255.255.255.0
!
nat (inside,outside-pri) source static inside-network inside-network destination static remote-network remote-network
nat (inside,outside-pri) source dynamic inside-network interface
!
nat (inside,outside-bkup) source static inside-network inside-network destination static remote-network remote-network
nat (inside,outside-bkup) source dynamic inside-network interface
!
crypto ikev1 policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
access-list CRYPTO_ACL extended permit ip 10.10.20.0 255.255.255.0 10.10.10.0 255.255.255.0
!
crypto ipsec ikev1 transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 match address CRYPTO_ACL
crypto map CRYP_MAP 10 set peer 41.1.1.1 41.1.2.1
crypto map CRYP_MAP 10 set ikev1 transform-set TRANS_SET
crypto map CRYP_MAP interface outside-pri
crypto map CRYP_MAP interface outside-bkup
crypto ikev1 enable outside-pri
crypto ikev1 enable outside-bkup
!
tunnel-group 41.1.1.1 type ipsec-l2l
tunnel-group 41.1.1.1 ipsec-attributes
 ikev1 pre-shared-key cisco

tunnel-group 41.1.2.1 type ipsec-l2l
tunnel-group 41.1.2.1 ipsec-attributes
 ikev1 pre-shared-key cisco

Now for the interesting part – testing! In our first test, I will initiate a connection from a host on LAN-A (10.10.10.10) to a host on LAN-B (10.10.20.20). Since all links are up, I expect the VPN tunnel to be terminated between 41.1.1.1 (SITE-A-ASA Primary ISP link) and 41.2.1.1 (SITE-B-ASA Primary ISP link).

For our second test, I will bring down the link between SITE-A-ASA and its primary ISP. The SLA tracking object will go down and the backup ISP route is installed.

Also, the current VPN tunnel between the devices is torn down.

Now I will try to initiate that ping again from 10.10.10.10 to 10.10.20.20. I expect the tunnel to be set up between 41.1.2.1 (SITE-A-ASA Backup ISP link) and 41.2.1.1 (SITE-B-ASA Primary ISP link).

Now, let us assume that the primary link on SITE-A-ASA comes back up, it means the SLA tracking object will come back up and the static route through the outside-pri interface will be installed.

Another thing that happens is that the ASA loses connection with the current VPN peer and so the VPN tunnel is torn down.

So if we ping again, the VPN tunnel will be re-established.

I can also perform a repeated ping while shutting down and bringing back up the primary link.

The first loss occurred when I shut down the primary link and the ASA switched over to the backup link. The second loss occurred after I brought that primary link back up. You can test the other possibilities, e.g., shut down and bring back up the primary link on SITE-B-ASA, shut down both primary links on SITE-A-ASA and SITE-B-ASA.

Note: I tried using a Cisco IOS router on the other side of the VPN tunnel, but it doesn’t work quite as smoothly as the Cisco ASA. The reason is that the router does not delete the SAs when the interface goes down/comes back up. To remedy this, you may have to set an idle-timeout for the SAs using the command set security-association idle-time 60 under the crypto map configuration.

Summary

In this article, we have deployed an active/standby VPN configuration where one tunnel is always used when available and the other is used as backup. Our VPN tunnel endpoints were Cisco ASAs and we made use of static routes, SLA tracking and normal crypto maps.

I hope you have found this article insightful and this brings us to the end of this mini-series on using VPN tunnels as backup links.

References and Further Reading