cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

BLOG (No Title)

116772
Views
13
Helpful
30
Comments
Cisco Employee

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.

30 Comments
Beginner

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.

Cisco Employee

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

Beginner

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:

crypto isakmp enable Backup

thanks 

great article

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.

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?

Beginner

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?

Beginner

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

Beginner

@cfinley

I ended up getting a response to this when I put the question in it's own thread.  Check it out - https://supportforums.cisco.com/message/3447990#3447990

-Bobby

Beginner

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

Beginner

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?

Beginner

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?

Beginner

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.

Tks

Beginner

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