Hello everyone and welcome back to this series on Network Reliability. In the last article, we explored unequal cost load balancing. We considered how individual routing protocols share traffic across links with unequal bandwidth and how the EIGRP variance helps to support unequal cost load balancing. You can read the article here.

In this article, we will consider another important aspect of the network – firewalls. We will explore the considerations for firewall redundancy and introduce various ways to improve reliability by designing networks for firewall redundancy. We will spending some time on the command line so I encourage you to turn on your device lab (and emulators), grab a cup of your favorite beverage and strap in for a ride. Now, let’s get started.

Firewalls are an important part of networks today because they usually serve as border agents of the networks. Typically, firewalls separate networks into zones and as such, they play an important role in the security of the network. As such, network engineers have to ensure that firewalls do not reduce the reliability of the network. And as we have seen in previous articles, an easy way to increase the reliability of a component is to increase its redundancy. So what features do we need to consider as we design our firewalls for redundancy?

Firewalls perform different functions on a network. The most important function of a firewall is stateful packet filtering. Basically, this means that a firewall tracks the states of the connections that pass through it and allows these connections based on rules that have been defined on the firewalls. So we need to consider what happens to all the rules that have been defined on the firewalls (and the active connections too), in the case of a failure event. And this is what makes failover in Cisco firewalls a bit more complex to implement.

Cisco ASA Redundancy

In Cisco firewalls (first the PIX and then the ASA), there is a failover feature that allows two firewalls to act in a failover group (one as active and the other as backup). This licensed feature (yes, you need to have a real failover license!) allows real time syncing of the status of both firewalls to ensure consistency in the event of a failure. However, for this feature to work, some requirements have to be met:

  1. The two firewalls must have the same hardware: This means same model, same number of interfaces, same modules installed, and same amount of RAM. If possible you should ensure they have the same flash memory too. This is not compulsory, but its regular best practice.
  2. They should be running the same software version. This means that the major number and the first minor number must match. So both ASAs must be running 8.4 code, for example. Also the firewalls must be running in the same operating modes (routed/transparent) and should have the same context mode (single/multiple context).

Types of ASA failover:

  1. Stateless failover: With stateless failover, the firewall is not concerned with preserving the state of the connections that are passing through the active firewall in the event of a failure. However, the policies and rules on the firewall still need to be preserved. In this case, the configuration of the firewalls in a failover are kept in sync so that connections that the policies remain consistent across the firewalls.
  2. Stateful failover: In stateful failover, the connections and translations that are existing on the active firewall is preserved in the event of a failure. In this case, the configuration, translation table and connection tables are kept in sync between the firewalls in the failover group.

Active/Standby Redundancy in ASA Firewalls

The default kind of redundancy that is provided with the ASA failover license is the active/standby redundancy. Basically, this means that one ASA (the standby) would not be used until the other ASA fails. Considering that the ASA can be very expensive, this is not very cost effective but on the other hand, since firewalls play an incredibly significant role on the network, having two of them just for redundancy does not sound so terrible.

Let us consider the topology below:

The inside of FW1 and FW2 are connected to the same network. Similarly their outside interfaces are connected to the same network. Then we have another direct connection from FW1 to FW2 for failover. This connection can serve two purposes:

  1. The (stateless) failover link: This is used to transfer failover control information and replicate configuration from the primary device to the secondary device. The interface used for failover is identified using the “failover lan interface
    <interface_name>
    <physical_interface>” command.
  2. The stateful failover link: This is used to replicate the state of the connections (usually the connections and translations table) from the primary to the secondary device. You can choose to use the failover interface, a data interface or an entirely different interface for the stateful failover link. The stateful failover link is identified using the “failover link
    <interface_name>
    <physical_interface>” command.

Configuring Active/Standby Failover

When configuring failover, the active ASA is configured fully and the configuration is then replicated to the standby ASA. Only the failover commands are required on the standby ASAs. In this case, the configuration on for the outside interface on FW1 would be:

FW1(config)# interface Ethernet0/0
FW1(config-if)# nameif outside
FW1(config-if)# ip address 1.1.1.1 255.255.255.0 standby 1.1.1.2
FW1(config-if)# no shutdown
FW1(config-if)# exit
FW1(config)#

Unlike HSRP and other first hop redundancy protocols, the standby address is also configured on the ptimary device. Similarly, the inside interface configuration of FW1 would be:

FW1(config)# interface Ethernet0/1
FW1(config-if)# nameif inside
FW1(config-if)# ip address 10.0.0.1 255.255.255.0 standby 10.0.0.2
FW1(config-if)# no shutdown
FW1(config-if)# exit
FW1(config)#

Now we can go ahead and configure other policies on the ASA like NAT, class-maps, access-lists etc. But that is not the goal of this article so we will just go ahead and configure failover on the primary device.

FW1(config)# failover lan unit primary

This command makes FW1 the primary failover unit:

FW1(config)# failover lan interface failoverlink Ethernet0/2

This command makes interface Ethernet 0/2 the LAN based (stateless) failover link:

FW1(config)# failover interface ip intense_school 192.168.0.1 255.255.255.0 standby 192.168.0.2

The command above specifies “intense_school” as the name of the failover interface and specifies the IP address.

Next thing is to enable the failover interface:

FW1(config)# interface Ethernet0/2
FW1(config-if)# no shutdown 
FW1(config-if)# exit
FW1(config)#

For stateful failover, we can use the same link:

FW1(config)# failover link intense_school Ethernet0/2

Once this has been done, the next step would be to actually enable failover. If failover is not enabled, all the failover commands would have no effect. This is done using the “failover” command:

FW1(config)# failover

On the standby/secondary ASA, we only need to configure the failover related commands. In this case, the configuration on FW2 would be:

FW2(config)# failover lan interface failoverlink Ethernet0/2
FW2(config)# failover interface ip intense_school 192.168.0.1 255.255.255.0 standby 192.168.0.2
FW2(config)# interface Ethernet0/2
FW2(config-if)# no shutdown 
FW2(config-if)# exit
FW2(config)# failover lan unit secondary

At this point, we should be ready to replicate the running configuration from the primary device to the secondary device. We can activate that using the “failover” command:

FW2(config)# failover

I usually save both devices after doing this. You should note that any config changes at this point should be made on the primary/active device and it would be replicated on the secondary. Configuration made on the secondary is NOT replicated to the primary. This would take the configuration out of sync and you should avoid doing this!

Interface Monitoring

By default, all the physical interfaces in service on a firewall are monitored and when one of the interfaces fails, the failover kicks in. You can change this behavior with these commands:

FW(config)#  no monitor-interface outside

The config above disables monitoring for the outside interface:

FW(config)#  failover interface-policy 50%

The command above increases the threshold, such that at least 50 percent of the interfaces being monitored would fail before failover kicks in. Unless you have a good reason to change the default, I would let failover kick in once an interface goes down (default behavior).

HTTP Replication

With stateful failover, the connections are replicated from the active device to the standby. However, HTTP replications are not enabled by default. This is because “HTTP connections are typically short-lived, and because THTTP clients typically retry failed connection attempts.” To enable HTTP replications, we can use the command:

FW(config)# failover replication http

Conclusion

In this article, we considered the firewall and dove deep into configuring Active/Standby redundancy on ASA firewalls. We looked at the ASA failover license and the command set for configuring failover on Cisco ASAs. The next step in this series is to explore Active/Active failover scenarios in ASA firewalls.

I hope you enjoyed reading this article as much as I enjoyed writing it. As usual, if you have any questions, opinions or suggestions, please use the comment box to express your views. Thank you so much for reading and I look forward to writing the next article in the series.

Further Reading

  1. Configuring Failover:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa80/configuration/guide/conf_gd/failover.html