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.
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 184.108.40.206 (Which means, the primary set peer value is 10.10.10.1, and if is down, device will try for 220.127.116.11 ip address for tunnel)
crypto map Outside_map 20 set transform-set ESP-3DES-MD5
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.
The background is the end devices PC would like to use EAP-TLS for 802.1x wired auth. by the cert. signed by window CA. When the cert. signed by window standalone CA, it is working fine.However, when the cert. signed by window enterprise CA. it ...
Hi, I want to create IPS Reporting on FMC but cant see any data under any available templates. I wana to create standard Intrusion Report for all kind of Intrusion events. Plus I can see IPS events in Dashboard Summary but None of them refl...
I'm trying to deploy ASAv in Azure and as the docs suggest, the management-only setting should be removed from the Management interface since "...the Management interface is the only interface that can have an Azure public IP address associated with it. B...
Hello Community, I need good advice to update two FTDs on ASA 5525X in HA from FMC1) do you need to break the HA to update them one at a time? so there is no effect on the service?Or is this process handled by the FMC without breaking the HA?I await...