ASA Dual ISP

When it comes to internet redundancy, the Cisco ASA family of firewalls can be very flexible in how they can be configured to provide that highly available connection. You can even host highly available internet-facing services from one with a couple basic, static routed internet connections!

The simplest scenario is where there is a user base that needs a highly available internet connection for simple web surfing, etc.
Here, we could terminate two simple static routed internet pipes to the ASA, create two default routes to the next hops, one being contingent upon an IP SLA (you need to have a host route configured for the remote IP that the IP SLA is polling and pointing at the primary next hop), and the other having a higher metric.
In a normal state, the IP SLA will be successfully polling the remote IP and will keep the primary default route installed in the routing table. In a fail-over scenario, the IP SLA will show down and withdraw the primary default route which will leave the secondary (floating) in place to route traffic over the secondary connection.

In a more complex (and expensive) scenario, you can use BGP to peer with two different ISPs and let it decide which path to take based on the information it is receiving from its peers. This solution has the benefit of being able to keep a block of public IPs highly available, and you can use these public IPs to host internet-facing services. This solution also has the drawback that it is very expensive and difficult to accomplish (registering a BGP AS number, purchasing public IP blocks, obtaining dynamically routed ISP connections, etc) and is not typically a viable solution for small to medium businesses (SMBs).

It is, however, possible to host highly available internet-facing services from a couple of cheap, everyday, static internet connections and an ASA firewall.

Hosting services this way builds on the first scenario described in this article. You will want your primary (contingent upon SLA) and floating routes in place to keep your locally sourced outbound traffic moving in the right direction.

ciscoasa# sho run
: Saved
:
ASA Version 8.4(4)1
!
interface GigabitEthernet0/0
 nameif ISP_A
 security-level 0
 ip address 100.0.0.2 255.255.255.248
!
interface GigabitEthernet0/1
 nameif ISP_B
 security-level 0
 ip address 200.0.0.2 255.255.255.248
!
interface GigabitEthernet0/2
 nameif INSIDE
 security-level 100
 ip address 10.0.0.1 255.255.255.0
!
!
!
!
sla monitor 1
 type echo protocol ipIcmpEcho 4.2.2.2 interface ISP_A
 timeout 5
 frequency 1
sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
!
!
!
!
!
route ISP_A 0.0.0.0 0.0.0.0 100.0.0.1 1 track 1
route ISP_B 0.0.0.0 0.0.0.0 200.0.0.1 2
route ISP_A 4.2.2.2 255.255.255.255 100.0.0.1 1
!
!
!
end
 

Then we will add to this some static NAT entries for the internal servers. We will need to add two NAT statements for each internal IP: one for the primary connection, and one for the secondary. Here we are using a single web server with private address 10.0.0.10, public address on ISP_A of 100.0.0.3, and public address on ISP_B of 200.0.0.3.

ciscoasa# sho run
: Saved
:
ASA Version 8.4(4)1
!
 object network WEBSITE_Primary
 host 10.0.0.10
object network WEBSITE_Secondary
 host 10.0.0.10
 !
 !
 !
 object network WEBSITE_Primary
 nat (INSIDE,ISP_A) static 100.0.0.3
object network WEBSITE_Secondary
 nat (INSIDE,ISP_B) static 200.0.0.3
 !
 !
 !
 end
 

When the server sends unsolicited traffic out to the internet, the firewall will create a new flow and NAT entry and will pass the traffic to ISP_A. Since the initial traffic will be source natted (SNAT) to 100.0.0.3, the return traffic will return through ISP_A to that public address.
In a similar situation, when unsolicited traffic from the internet hits 100.0.0.3, the ASA will NAT the destination address to 10.0.0.10 and pass it to the server.

Unsolicited traffic from the internet to one of the two public IP’s will create flows specific to their ingress and egress interfaces and will be processed by the appropriate NAT rules.

*Here’s the cool part:
Traffic returning from the server to the internet for the unsolicited, internet-sourced flows will follow the path of the originating traffic (even though the default route says to take the route of ISP_A!!!)

Here’s why:

A packet in an ASA follows a complex decision tree when determining its egress interface (check out these blog posts from TunnelsUp and Ethan Banks for more info on this process). In this order of operations, NATing of the IP header happens before the routing table is consulted. When a NAT rule is written with both interfaces defined (as opposed to an “INSIDE,ANY” rule), the packet is NATted and then “virtually” passed to the egress interface. Once at the egress interface, the destination IP is looked up in the routing table to determine the next hop for the packet. If the routing table doesn’t have a next hop for that destination that also points out of the egress interface, it will log an error and drop the packet.

Once the initial traffic from the internet creates a flow in the ASA, all traffic belonging to that flow will enter and exit

What happens to the traffic returning from the internal server:

When it hits the INSIDE interface, the ASA determines if this packet matches an already existing flow (which it does). The ASA then NATs the traffic based on the NAT rule used to initiate the flow and virtually passes the traffic to the egress interface where the original traffic was received. The ASA then does a route lookup for the next hop for this packet and will only accept a route that is valid for that egress interface (if it doesn’t have a valid route, it will log an error and drop the packet.

What does all this mean?

This means that a host on the internet can hit either 100.0.0.3 or 200.0.0.3 and will be able to successfully reach the web service hosted from the same internal web server. The firewall will NAT and route the traffic back to the internet based on how it got there in the first place (from ISP_A or ISP_B).

How can this be used for high availability?

In order to achieve high availability with this system, you can go one of two ways:

(1) [less preferred] Point your DNS record at your primary IP (100.0.0.3) and change the DNS record over to 200.0.0.3 in the event of a failure of ISP_A. This will require a manual changing of DNS (unless you can write up a fancy script to do it) and will result in an outage of however long it takes for you to realize the service broke + DNS propagation time.

(2) [more preferred] Use a cloud-based load balancer service (here’s one from Rackspace) and point it at both of your public IPs for its server pool. Then point your DNS records at the VIP of your cloud load balancer and have it SNAT all client traffic before sending it to one of the public IPs of your server. The load balancer should be able to poll both public IPs and detect when one dies off. You can even have the it share the load of the traffic across both public IPs and get extra throughput by using both ISPs at the same time 😉

With a cloud load balancer and a couple of basic business internet connections, you can host a pretty reliable internet service on the cheap!