Skip to main content

Cisco ASA 5510 with Dual ISP Redundancy


Cisco ASA 55XX with Dual ISP Redundancy


This article will cover setting up redundant ISPs for outbound connectivity on an ASA 5510 (although the same should work on the 5520s and up as well).  It’s important to note that this covers outbound connectivity only.  The ASA does not have built in functionality to NAT multiple public IPs to a single internal IP – for that you’d need a router (how-to article soon!).  For an ASA to provide inbound redundancy to your servers you’d need to utilize two separate IPs for each server – one to be NAT’d to each public IP block.
The information you’ll need to complete this task:
·         Primary ISP Subnet / Gateway
·         Secondary ISP Subnet / Gateway
·         A Public host to ping (i.e. 4.2.2.1)

The Public host to ping is a device (read: cluster of devices) that we will use to check if our primary ISP is up or down.  For that reason, I advise against using an IP of a single server.  I usually go with one of the well-known public DNS servers – 4.2.2.1, 4.2.2.2, or 4.2.2.3.
For this article, we’ll use the following information:
·         ISP A
Subnet: 20.20.20.0/24
Gateway: 20.20.20.1
Firewall: 20.20.20.2
·         ISP B
Subnet: 30.30.30.0/24
Gateway: 30.30.30.1
·         Firewall: 30.30.30.2
Private LAN
Network: 10.10.10.0/24
Firewall: 10.10.10.1

I’ll assume that you’ve already been successful in getting your ASA up and running, and that your config looks something like this (NOTE: I’m using the 8.2 firmware):
!
hostname firewall
!
interface Ethernet0/0
 description Primary ISP
 nameif outside
 security-level 0
 ip address 20.20.20.2 255.255.255.0
!
interface Ethernet0/1
 description Backup ISP
 nameif backup
 security-level 0
 ip address 30.30.30.2 255.255.255.0
!
interface Ethernet0/2
 description Private LAN
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0 
!
interface Ethernet0/3
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Management0/0
 nameif management
 security-level 100
 ip address 192.168.1.1 255.255.255.0 
 management-only
!
global (backup) 1 interface
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 20.20.20.1 1
route backup 0.0.0.0 0.0.0.0 30.30.30.1 10
 
--------------------------------------------------------------------------------


hostname firewall
!
interface Ethernet0/0
 description Primary ISP
 nameif outside
 security-level 0
 ip address 20.20.20.2 255.255.255.0
!
interface Ethernet0/1
 description Backup ISP
 nameif backup
 security-level 0
 ip address 30.30.30.2 255.255.255.0
!
interface Ethernet0/2
 description Private LAN
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0
!
interface Ethernet0/3
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Management0/0
 nameif management
 security-level 100
 ip address 192.168.1.1 255.255.255.0
 management-only
!
global (backup) 1 interface
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 20.20.20.1 1
route backup 0.0.0.0 0.0.0.0 30.30.30.1 10
 
 
As it stands, you will fail over to your secondary ISP only if interface Eth0/0 physically goes down – that is, the cable to your upstream router, public switch, or whatever device you firewall is connected to is unplugged or cut.  Realistically, the number of times that an outage is due to something besides a loss of physical link is far greater than an outage caused by a physical outage.  For that reason, Cisco lets us do route tracking, which is where our “public IP to ping” comes into play.  Basically, we tell the ASA that we want to ping IP address 4.2.2.1 over a specific route, and if that host stops responding, then assume the route is down, and install a backup route into the route table.
To get started, get into configuration mode
firewall> enable
firewall# config t
firewall(config)#

First we’ll setup the constant ping to a specific IP:
firewall(config)# sla monitor 1
firewall(config-sla-monitor)# type echo protocol ipIcmpEcho 4.2.2.1 interface outside
firewall(config-sla-monitor)# num-packets 3
firewall(config-sla-monitor)# frequency 10
firewall(config-sla-monitor)# exit
firewall(config)# sla monitor schedule 1 life forever start-time now
Here we’ve said that we want to send 3 ICMP echos to 4.2.2.1 and repeat every 10 seconds.
Next we’ll tie a tracked route with the SLA monitor:
firewall(config)# track 100 rtr 1 reachability

And last we’ll specify the route that we want to track:
firewall(config)# no route outside 0.0.0.0 0.0.0.0 20.20.20.1 1
firewall(config)# route outside 0.0.0.0 0.0.0.0 20.20.20.1 1 track 100

And that should do it.  Keep in mind that for the best test case after completing this setup you should turn off / unplug something that leave the physical interface up.  So if you’re firewall connects to a public switch, and then the switch connects to your ISP’s device, unplug the cable between the switch and the ISP.

END

Comments

Post a Comment

Popular posts from this blog

Lenovo Ideapad V310-15ISK Wi-Fi issue on Ubuntu/fedora/CentOS

Go to terminal and RUN below command You can also copy & paste the below line on command prompt: # sudo tee /etc/modprobe.d/blacklist-ideapad.conf <<< "blacklist ideapad_laptop" # reboot. Link: https://askubuntu.com/questions/893668/qualcomm-atheros-wifi-lenovo-v310-ubuntu-16-04

How to Block Root Password-Guessing Attacks on a Linux Server

How to Block Root Password-Guessing Attacks on a Linux Server The benefit of performing the preceding steps is that it is nearly impossible for an attacker to log on to your server as root by guessing the password.  In order for the attacker to masquerade as root, she or he would have to have your private key and know the pass phrase associated with it. Using Cryptographic Keys for SSH Root Login Take one look at /var/log/secure on an Internet-connected server and you'll immediately understand the need for securing your root account.  The bad guys are constantly attempting root and other usernames to attempt to login to your server using SSH or some other protocol.  If you use a simple password, it's only a matter of time before your server is compromised by a password-guessing attack. Best practice is to disallow SSH logins by root, thus eliminating a big part of the risk.  The problem is that doing so also eliminates a lot of ...