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.
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.
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).
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.
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.
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.
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.
The command above specifies "intense_school" as the name of the failover interface and specifies the IP address.
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!
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).
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.