Got a situation where LocationA got TWO ISP and LocationB got One ISP.Using ISP 1 link LocationA establishes IPSEC Tunnel with LocationB.How do I establish redundancy from LocationA point of view, if ISP1 is down then ISP2 should establish IPSEC tunnel with LocationB.At LocationA both ISP links terminates on the cisco PIX-525 and all. ASA failover & ISP failover are NOT the same. The failover feature on ASAs let's you have device redundancy, meaning that if for some reason your active ASA is not at full capacity, the other unit will take over and brag about how it saved your network's ass. The SLA MONITORING feature is what you need when dealing with ISP failover. Got a situation where LocationA got TWO ISP and LocationB got One ISP.Using ISP 1 link LocationA establishes IPSEC Tunnel with LocationB.How do I establish redundancy from LocationA point of view, if ISP1 is down then ISP2 should establish IPSEC tunnel with LocationB.At LocationA both ISP links terminates on the cisco PIX-525 and all. The Cisco ASA has been around for quite some time and is a popular SMB and Enterprise device. This appliance-based firewall supports redundant or backup ISP links in an active/standby configuration. Older editions like the ASA 5510 to the newer 5500-X Series running software Version 9.x or later easily support this feature.

Policy based IPSEC tunneling is probably the most widely used technique to get two offices to communicate securely (at least in the SMB Market).

Today I’m going to discuss how you can configure two ASA’s to failover to their secondary WAN, and then have their tunnels fail over as well.

One should always aim for having two ISPs if the business needs to rely on the tunnel. The question to ask ones self is “If this tunnel goes down, can I continue working?”

If the answer is no, then you need a secondary ISP at a minimum.

I’m going to begin the config for ASAv-1 (left network)…

First let’s get some basic “optimizations” out of the way:

The below allows the asa to keep track of ICMP and let it pass through (does it by IP and expected code reply)

The first command prevents TCP fragmentation in the future tunnels by clamping the MSS.

The second command preserves session tables if the VPN bounces (quicker recovery).

Now let’s configure the LAN and WAN and their security levels.

Configure an IP SLA monitor to ping google via the first outside interface.

Connect a track object to the IP SLA so we can reference in the route later.

Tell the ASA to use Outside as the primary WAN and failover to Outside2 when the track object fails.

Configure basic dynamic PAT for both WAN interfaces.

Now let’s configure the VPN:

Enable ikev1 listening on both WAN interfaces.

Set our preferred IKE policy for all VPNs.

Create the tunnel groups for both WAN links on the other side, with the same shared secret.

Configure the ACL for matching the traffic to be protected.

Configure the IPSEC encryption parameters.

Configure the crypto map for the tunnel, with two peers, then add it to both WAN interfaces.

Finally configure the identity NAT so that the traffic traverses properly.

Now let’s configure the right network’s ASA. I will put that whole config down here since it’s basically a mirror.

Use the “show vpn-sessiondb l2l” command to view the status of the tunnel, like below.

A healthy tunnel will have both TX and RX Bytes showing.

An unhealthy tunnel will either show “There are presently no active sessions” or it might show some TX or RX, but not both.

It also helps of course to just ping across the tunnel, here I am pinging from 2.10 to 1.10.

Ok now let’s initiate some failover and test:

Shut down the primary WAN on ASA 2 (right network). Let’s confirm which interface that is:

Perfect, looks to be G0/0 as we expected.

Run this debug command to confirm IPSEC failover.

Ok now shut off int g0/0.

Ok let’s confirm the track object did its job and failed over to our static default route with an AD of 2.

Yup, looks like we are good there.

Now If I ping again from 2.10 to 1.10 the tunnel should renegotiate.

We also would see these decrypt messages from the ASA.

Perfect the failover worked. Now do an “undebug all” in global config mode to return the ASA back to normal.

This article describes how to configure Dual WAN connection on Cisco ASA. If you need to configure the same on any Cisco router like Cisco 881 then read the article “IP SLA on Cisco router”

Sooner or later, every network administrator encounters a channel going down, whether it is an ISP uplink to the Internet or a WAN circuit to some other resources. Most of the time this serves as that “a-ha” moment that forces us to think about creating some kind of a backup mechanism (too bad that we didn’t think about such things in advance!). Yet, if there are two ISPs available, you have the opportunity to configure a redundant connection scheme that will help you avoid downtime.

Ideally, you would place a router, connect two ISPs to it, reserve an autonomous system with public IP addresses and configure a fully redundant connection scheme with BGP protocol (Cisco ASA series support BGP only on 5500X models and with the latest versions of IOS). However, this approach suits only large companies with enough resources, capacity, and trained personnel.

In most cases configuring a backup ISP to be used in case of main channel failure is the most adequate solution. Cisco ASA devices have the capability to monitor the availability of the primary ISP channel and switching over to the configured backup in case of its failure (when the gateway fails to respond to ICMP requests over several seconds).

Let’s see how we can configure this.

Let us look at the following example: we have a Cisco ASA 5505, which connects our office to the Internet through ISP 1 via the Ethernet 0/1 interface. You can read the detailed setup in the “Cisco ASA Basics. Connecting to the Internet” article. We have connected an additional service provider, ISP 2, to the interface Ethernet 0/2 (see the diagram).

Asa Isp Redundancy Meaning

Our task: configure a fault-tolerant Internet connection scheme (dual WAN)

Step 1. Check the routes

First, let us check the current configured routes on the device. The easiest way to do so will be the “sh run | inc route” command, which will output the running configuration lines that contain the word “route”:
FW-DELTACONFIG-1# sh run | inc route
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
If we translate this into normal language, we will get the following:
“Redirect all packets, which I don’t know, into the “outside” interface through the gateway 1.1.1.1”
Cisco ASA “knows” only those networks that are directly connected to its interfaces or that are entered as routes in its running configuration.

Step 2. Configure interfaces for the use of secondary ISP

Our firewall already has an interface name “outside” (Ethernet 0/1, VLAN 2) that connects to the primary ISP. The running configuration (available through the “sh run” command) has the following lines:
FW-DELTACONFIG-1# sh run
/...cut.../
interface Vlan2
nameif outside
security-level 0
ip address 1.1.1.2 255.255.255.252
/...cut.../
interface Ethernet0/1
switchport access vlan 2
/...cut.../
Let’s add the configuration for the backup ISP that is connected to interface Ethernet 0/2, VLAN 3:
FW-DELTACONFIG-1 (config)#
interface Vlan 3
nameif outside_backup
security-level 0
ip address 2.2.2.2 255.255.255.252
interface Ethernet0/2
switchport access vlan 3
no shut
If all cables are properly connected and the configuration is correct, then you shall be able to reach the gateway of the backup ISP:
FW-DELTACONFIG-1 # ping 2.2.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/18/20 ms

Step 3. Configure monitoring of the ISP’s availability

In order for the firewall Cisco ASA to monitor the availability of the primary channel, we need to configure the “ip sla monitor” function. It allows to send a ping request (an ICMP echo request) to the ISP 1’s gateway address at configured time intervals. Receiving a response (ICMP echo reply) will mean that the channel is available.
FW-DELTACONFIG-1 (config)#
sla monitor 1
type echo protocol ipIcmpEcho 1.1.1.1 interface outside
timeout 3000
threshold 10000
frequency 5
sla monitor schedule 1 life forever start-time now
track 1 rtr 1 reachability

Additional information:
timeout 3000 – is the timeframe within which Cisco ASA will await for an ICMP response. 3000 => 3 seconds
frequency 5 – how often to send the requests. Here is every 5 seconds
threshold 10000 – a delay for the operation of 10 seconds, during which no actions are taken

Step 4. Configure the default gateway for the backup ISP

Just like with the primary ISP, the backup ISP needs to have its default gateway configured on the Cisco ASA, so that the firewall will send all the unknown packets in its direction. The only difference is that this gateway should only be used in case the primary ISP is unavailable and not clog the routing table in all other cases. To achieve this, we need to change the administrative distance of the route – make it bigger, thus lowering the priority of this route. By default, all static routes have an administrative distance of 1. We will configure an administrative distance of 250 for our backup channel, bringing it closer to the highest possible value.
FW-DELTACONFIG-1 (config)#
route outside_backup 0.0.0.0 0.0.0.0 2.2.2.1 250
After we add this configuration, our default routes should look like this:
FW-DELTACONFIG-1# sh run | inc route
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
route outside_backup 0.0.0.0 0.0.0.0 2.2.2.1 250
Step 5. Activate the backup mechanism
The final step for configuring a backup channel on a Cisco ASA is to turn on the monitoring function (ip sla) for the primary ISP.
To achieve this, we add a new line of configuration for the default route, using the track 1 remark and remove the old configuration:
FW-DELTACONFIG-1 (config)#
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1 track 1
no route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
Now we have the following configuration for the default routes:
FW-DELTACONFIG-1# sh run | inc route
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1 track 1
route outside_backup 0.0.0.0 0.0.0.0 2.2.2.1 250

Important!
You should take into consideration any other configured static routes on your device.

Important!
You also have to configure the access lists and NAT rules to use the backup ISP. Add identical rules and apply them to the outside_backup interface.

Checking the IP SLA monitoring function state

In order to see the state of the IP SLA working on your device, use the show sla monitor operational-state command:
FW-DELTACONFIG-1# show sla monitor operational-state
Entry number: 1
Modification time: 12:02:29.993 MSK Mon Aug 17 2015
Number of Octets Used by this Entry: 1480
Number of operations attempted: 39
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: FALSE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): 10
Latest operation start time: 12:05:39.997 MSK Mon Aug 17 2015
Latest operation return code: OK
RTT Values:
RTTAvg: 10 RTTMin: 10 RTTMax: 10
NumOfRTT: 1 RTTSum: 10 RTTSum2: 100
The output of this command gives all information and statistics of the IP SLA function. This will be very useful if you need to troubleshoot the setup and operation.

Asa Isp Redundancy Definition

Important!

Don’t forget to save the changes you made to the configuration with the write or copy run start commands. Otherwise you will lose all changes after the next reload.
This article was written by Alexey Yurchenko

Asa Isp Redundancy Rules

Back to Table of contents