IPSEC VPN Redundancy / Failover, over Redundant ISP Links

Blog

Apr 21, 2011 9:50 PM
Apr 21st, 2011

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)

https://supportforums.cisco.com/servlet/JiveServlet/download/38-85250/VPN%20redundancy%20network%20diagram.png

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.

interface Ethernet0/0
  nameif primary
  security-level 0
  ip address 172.16.10.1 255.255.255.0
!
interface Ethernet0/1
  nameif backup
  security-level 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
num-packets 3
frequency 10

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) :

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806e880b.shtml

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   20.20.20.1                    
          (Which means, the primary set peer value is 10.10.10.1, and if is down, device will try for 20.20.20.1 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

  pre-shared-key *

tunnel-group 172.16.20.1 type ipsec-l2l

tunnel-group 172.16.20.1 ipsec-attributes

  pre-shared-key *

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.

Use-Cases:

===========================================

  1. 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.

  2. 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.

  3. 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.

Average Rating: 4.3 (3 ratings)

Comments

Arber_123 Fri, 05/06/2011 - 16:08

How does ASA detect if the SLA is down? I think you have to track the primary default route with the object that you created. I think that the command is: route primary 0.0.0.0 0.0.0.0 172.16.10.10 track 1.

without the track keyword the primary route sits there even if the SLA has an unreachable status. The backup route in this case will take over when the ethernet 0/0 interface goes down.

Please correct me if I am wrong.

regards,

Arber.

rudv Wed, 05/18/2011 - 04:13 (reply to Arber_123)

Hi Arber,

Yes you are correct, i missed the track keyword in the config mentioned. The redundancy for routing (which will trigger the redundancy for VPN) will take effect for routes only by tracking the routes with interface SLA.

Thanks very much for pointing that. Also i have mentioned the link above for more details on the SLA part .

Regards,

Rudresh

hill-m Wed, 05/18/2011 - 17:06

crypto map Outside_map 20 set peer 10.10.10.1   20.20.20.1        

should this be:

crypto map Outside_map 20 set peer 172.16.10.1   172.16.20.1    

I also had to add this line to make it work:

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

crypto isakmp enable Backup

thanks 

great article

mahbub.haque Tue, 07/26/2011 - 04:34

Thanks for sharing nice articale. I have IPSEC GRE tunnel site to site VPN on CISCO router. Now i want to vpn redandency with two isp. Please guide me how can i setup redandent vpn on 1841 router which IOS version is 12.4(15)T7.

devnullsecurity Fri, 08/19/2011 - 18:11

I have a few questions:

1.  What is the second nonat ACL for?  It is for 192.168.103.0 and I don't see that in the diagram.

2. Do you know if Checkpoint supports having multiple peer IPs in one tunnel config?  Will a Checkpoint firewall work as the remote site in this scenario?

rjberetto Thu, 09/08/2011 - 06:06

Great post - and it worked great when I configured it.  Here's a question though - my remote site also has 2 WAN connections and that ASA is also configured for WAN failover using tracking, how can I utilize that second WAN connection in the VPN redundancy?

cfinley Thu, 10/06/2011 - 10:16

I have the same question as Robert. We whant to use the SLA functionalty on both the head end and the remote end. Can this be done?

Dual_VPN_ISP.jpg

joshking1 Fri, 03/09/2012 - 03:15

Hi,

Thanks for this post. I actually implemented a similar setup but I noticed that when the primary link fails and vpn falls over to backup, the vpn continues to work on backup link even when the primary link comes back. The ip sla kicks in and installs the primary link route but the vpn just continues to stay up on backup and no traffic is going through the vpn because the installed route is now pointing back to primary gateway.

Please any idea on how to solve this problem?

Thanks

AdmShatan Mon, 07/23/2012 - 08:43 (reply to joshking1)

joshking1,

     You may be able to get the traffic to pass by using the SLA's to control the behaviour.  Try assiging routes that also track the LAN IP's across the apporpriate interface, and force traffice to pass along that interface.  I will be attempting this shortly as well.

ruffj@us.ibm.com Sat, 04/21/2012 - 05:02

Thanks for the write up.  Did I miss the isakmp (or ikev1/2) policy update for the secondary ISP interface link?  It still must be enabled, yes?

rammany19 Thu, 07/12/2012 - 15:02

hello

just stumbled upon this post, i have ASA 5520 and IOS is 8.3 and i have setup the vpn on both ISPs leg, how do i achieve this on 8.3 IOS. i already have SLA configured on the ASA, how do i have reduncy for vpn users?

mehmoodch Wed, 02/20/2013 - 03:05 (reply to ftakeda.cisco)

I have configured that setup and there is a very serious issue.

1.If both primary and backup links are up the remote office firewall will setup VPN with both links and VPN with primary and backup links will be up.

2. From main office as configured above the traffic can be routed either main of primary link via sla monitor.

3. Problem will be at remote office. Because at remote office remote firewall will have tow VPN sessions up.

one session with primary and other with backup links. the LAN settings for both links are same. If any person from main site access remote site that communication will be successful because of SLA. But if any person or application from remote site access any server to primary site the remote firewall can send traffic to any link either primary or backup

and that communication will be failed.

4. Is there any solution for this problem.

Thanks

Mahmood

rudv Thu, 04/18/2013 - 08:07 (reply to mehmoodch)

Hi Mahmood,

Even when both primary and backup links are active at same time (which would be usual scenario), remote office firewall will not setup VPN to both links because as per the configuration described above, the set peer has two entries (

crypto map Outside_map 20 set peer 10.10.10.1   20.20.20.1), the remote office will always try first 10.10.10.1 and only if fails to extablish tunnel to this one, it will fallback to 20.20.20.1.. So at any point, the remote office should not establish tunnels to both links.. If in case you saw the issue mentioned on a deployed setup, and have logs/debugs/stats from in your setup that shows both tunnels up at remote office firewall, please share here..

Regards,

Rudresh

mehmoodch Tue, 04/23/2013 - 03:49 (reply to rudv)

Hi Rudresh

I could not taken the logs because after realizing the problem that on remote office they are unable to use email and file server, I immediately removed the configurations of 2nd VPN from remote firewall.

However I have found one solution to run IP SLA on backup ASA as well.

the backup ASA ping the outside interface of primary ASA and when the ping is successfull IP SLA put the dummy and invalid route in the routing table of backup ASA and in this way the VPN between remote ASA and backup ASA must go down when the primary ASA comes back.

and VPN between primary ASA and remote ASA works fine

ciscotaufeeq Thu, 06/13/2013 - 05:04

Dear Rudresh,

The configuration provided by u works perfectly. I wanna ask you if there any way by which I can make one of the link dedicatelty for internet traffic without effecting vpn redundancy. In other words is load balacing possible while having vpn redundancy. Because we have 2 lease line with 1Mb each but only one is being used now that we are in need of more BW can I utilize the backup link for vpn also for internet jus to utilise the backup link also. Please advice.

Thanks in Advance.

Regards,

Taufeeeq

garza.javi Wed, 06/26/2013 - 11:07

Hi, I was having problems with the sla also, works great when links goes down and the backup route come in place, but after primary link goes up the sla keeps down, so primary route doesnt reestablish.

I resolved this by issue the command:

no ip verify reverse-path interface primary

By the way I was also having problems to get the backup iskmp phase1 established the state just hang up in

MM_WAIT_MSG2

I resolve this just by enabling isakmp in the backup interface:

crypto isakmp enable backup

Hope his comment helps.

Regards.

alexMDalex Mon, 08/19/2013 - 03:53

Hi. A little remark. I hav ASA version 8.3(1), and from cli reference read interesting command description ( for crypto map set peer):

This command is required for all static crypto maps. If you are defining a dynamic crypto map (with the

crypto dynamic-map command), this command is not required, and in most cases is not used because,

in general, the peer is unknown.

Configuring multiple peers is equivalent to providing a fallback list. For each tunnel, the security

appliance attempts to negotiate with the first peer in the list. If that peer does not respond, the security

appliance works its way down the list until either a peer responds or there are no more peers in the list.

You can set up multiple peers only when using the backup LAN-to-LAN feature (that is, when the crypto

map connection type is originate-only). For more information, see the crypto map set connection-type

command.

  So you need to add   crypto map set connection-type originated-only in you configuration and this scheme work only between cisco device ( and use proprietary protocol ).

Actions

Login or Register to take actions

This Blog

Posted April 21, 2011 at 9:50 PM
By rudv
Stats:
Comments:21 Avg. Rating:4.3
Views:51314   
Shares:0
Categories: ASA
+

Related Content

Blogs Leaderboard