In this blog post lets discuss on the procedure to setup Redundant IPSEC VPN connections to leverage Redundant ISP links for an ASA (the logic and procedure is the same for IOS routers, except for change in command syntaxes for routing, crypto maps and crypto pre-shared keys).
To achieve this kind of VPN redundancy, we need to configure the following:
A) Setup ISP redundancy with for example, SLA monitoring
B) Setup the VPN on the ASA to use primary and secondary ISP links for VPN redundancy
C) Setup the remote VPN endpoints to use the headend ASA’s primary and secondary ISP links as VPN peers (whichever is active)
Let’s look into configuring these stages in detail:
(Please refer to the attached network diagram, the config examples discussed below are based on this)
1. We need to setup a way to monitor the interfaces as to when the connectivity through primary ISP link goes down and then fallback to a backup ISP link. This is possible using SLA monitoring, as shown in the section below. With this, we will be configuring the ASA to switch to Backup ISP interface, when the primary ISP is down and fallback to primary when it comes back up.
ip address 172.16.10.1 255.255.255.0
ip address 172.16.20.1 255.255.255.0
route primary 0.0.0.0 0.0.0.0 172.16.10.10 1
route backup 0.0.0.0 0.0.0.0 172.16.20.10 254
sla monitor 123
type echo protocol ipIcmpEcho 10.0.0.1 interface outside
sla monitor schedule 123 life forever start-time now
track 1 rtr 123 reachability
Here you can find more details on the SLA monitoring configuration (I have not discussed this in detail here since our requirement is more towards configuring VPN) :
2. After we configure the Redundant or Backup links, we can build the crypto config to leverage this ISP redundancy to achieve VPN redundancy over primary and backup interface. Here are the required configurations:
access-list nonat extended permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0
access-list nonat extended permit ip 192.168.101.0 255.255.255.0 192.168.103.0 255.255.255.0
nat (inside) 0 access-list nonat
(nat exemption for VPN traffic)
nat (inside) 1 192.168.101.0 255.255.255.0
global (primary) 1 interface
global (backup) 1 interface
(We need to apply the global commands for both primary and secondary interfaces so that the active interface can be used for port translations, for inside users to go to internet.)
crypto map VPN-map 10 match address crypto-acl
crypto map VPN-map 10 set peer 10.10.10.1
crypto map VPN-map 10 set transform-set ESP-AES-SHA
crypto map VPN-map interface Primary
crypto map VPN-map interface Backup
(You would usually apply the crypto map to “Primary” interface, now we need to apply it to the “Backup” interface as well. With this, when the “Primary” interface is down <i.e if primary ISP link is down>, the crypto tunnels are formed through the Backup interface).
3. The third part of the setup is the configuration of crypto map on the other end of the tunnel to utilize the vpn redundancy at the headend. Now given that we are using two interfaces “Primary” and “Secondary”, we need to mention these as peer Ip addresses on the remote end, as shown below:
crypto map Outside_map 20 match address crypto-acl
crypto map Outside_map 20 set peer 10.10.10.1 18.104.22.168
(Which means, the primary set peer value is 10.10.10.1, and if is down, device will try for 22.214.171.124 ip address for tunnel)
crypto map Outside_map 20 set transform-set ESP-3DES-MD5
crypto map Outside_map 65535 ipsec-isakmp dynamic Outside_dyn_map
After this, we need to setup pre-shared keys for ip addresses of both primary and secondary ISP interfaces on the Headend ASA, since when a connection is needed to either primary or secondary interface ip address, we should have a tunnel-group with matching pre-shared key to complete the ISAKMP negotiation:
tunnel-group 172.16.10.1 type ipsec-l2l
tunnel-group 172.16.10.1 ipsec-attributes
tunnel-group 172.16.20.1 type ipsec-l2l
tunnel-group 172.16.20.1 ipsec-attributes
If we have more than one tunnel for the headend ASA, then we need to follow the same procedure mentioned above to configure crypto maps on the remote ends (ASAs or IOS Routers or any other network devices)
Note: In case you are using Remote Access IPSEC VPN clients also, then to utilize this redundancy, we need to mention primary interface ip address as the “host address” in the vpn profile, and under the “backup servers” section at the VPN client, we need to mention the secondary interface ip address.
So with the above procedure we should be having our VPN Redundancy in place. Now let’s consider some use cases for this setup.
- Primary ISP is up and running, with this the VPN will be formed with the “Primary” interface, because the SLA monitoring refereed under Part 1 above, will put the route, “route Primary 0.0.0.0 0.0.0.0 172.16.10.10 1” into effect for routing packets, and the “crypto map VPN-map interface Primary” will be chosen.
- If the Primary ISP goes down, then the SLA monitoring will detect that the Primary ISP is down and the route “route Backup 0.0.0.0 0.0.0.0 172.16.20.10 254” will be chosen. With this the “crypto map VPN-map interface Backup” entry will take effect because this is the outgoing interface that will be chosen for VPN traffic.
- If the Primary ISP comes back up now, SLA tracking will detect this and the route “route Primary 0.0.0.0 0.0.0.0 172.16.10.10 1” & “crypto map VPN-map interface Primary” will be chosen and Primary ISP will be chosen for VPN tunnel negotiations.
Feel free to share your feedback and any specific questions you have, will be glad to help.