- Background
- Static Versus Dynamic Filtering
- Router Mode Versus End-System Mode Firewalls
- Router-Controlled Failover Using Mirrored Router-Mode Firewalls
- Wrap-up
Router-Controlled Failover Using Mirrored Router-Mode Firewalls
The most common use of router-mode firewalls, where the address of the firewall and the address of the destination on the other side of the firewall are independent, is to support provisioning of services to the Internet, as in Figure 1. While the figure shows only a single web server being accessed from a single user on the Internet, the solution is easily scaled to support access in both directions and as many systems as the firewalls can handle. You just need to keep in mind that while in normal operations you may be able to share the load across both firewalls, you must size the firewalls to be able to continue operations with adequate performance when just one of the two is functional.
){kind=link}
Figure 1 Redundant routers with redundant firewalls.
The firewalls in this example are assumed to be configured identically in terms of the user services provided. That means that all addresses used for network address translation or proxy access are independent of the addresses used to identify the physical ports on the firewall. From the viewpoint of network operations, the security policy implemented on the firewalls and the mechanisms used to enforce security are irrelevant.
For this example, assume that each firewall will pass any legitimate web traffic between any valid Internet address and the web server at 100.0.0.99. On this network, you route to the public address of the web server and establish a default route that takes you back out to the outside world via a firewall. This mode of operation for the "inside'' network is typical for a DMZ network.
Note that you need to configure the routing so that any specific user's requests and the responses to those requests will always be delivered to the same firewall. Otherwise, any state information associated with existing connections will be unavailable and browsing may be disrupted. While this service disruption is considered acceptable if the alternative is no service (as when switching firewalls to recover from a firewall or access LAN failure), it's not something you want as part of normal operation.
The key to recovering from firewall failure is the use of Border Gateway Protocol (BGP) to detect when a path through a firewall is available. By advertising a unique target address for each available path, you can trigger the appropriate floating static route to direct your production traffic. To provide protection against as many double faults as possible, define the four paths in Table 1. Keep in mind that failure of any access LAN is equivalent to failure of the firewall served by that LAN.
Table 1 Path Selection for Maximum Double Fault Tolerance Using Four Paths
|
Path |
Inside Router |
Firewall and LANs |
Outside Router |
|
1 |
Router R-1 |
LAN_1 __Firewall F_1A __LAN_A |
Router R-A |
|
2 |
Router R-1 |
LAN_2 __Firewall F_2B __LAN_B |
Router R-B |
|
3 |
Router R-2 |
LAN_1 __Firewall F_1A __LAN_A |
Router R-B |
|
4 |
Router R-3 |
LAN_2 __Firewall F_2B __LAN_B |
Router R-A |
The critical concept behind this design is that, rather than using static routes pointing to a specific firewall service address to direct incoming and outgoing traffic to the appropriate firewall (and nowhere else), you instead use floating static routes that point to loopback interface addresses on the other side of the firewalls that you learn via BGP. When a path fails, the target address associated with that path becomes unreachable and a backup route using a different path floats into action. By careful selection of the route weights and sharing of local route information between routers, you minimize the potential for unnecessary changing of firewalls for any traffic flow.
The firewalls need to be configured to allow the exchange of BGP routing information. Network address translation can be used as desired without regard for explicit support by the firewalls for BGP traffic, because the addresses included inside BGP routing packets to provide next-hop information are ignored. Note also that you only need to provide a path for the BGP speaker on the inside to connect with the BGP speaker on the outside. If the BGP speakers on the outside routers don't support a passive (listen-only) option, this will cause false alarms during connection setup as the outside BGP speakers attempt to connect to their neighbors on the inside. The connection attempts will stop as soon as the inside speaker establishes a connection to the outside speaker, but could be annoying if an inside speaker fails.
You define target addresses on each of the four routers, one for each path to that router. Use address filters on your BGP advertisements to allow only the correct targets to be learned over each peering associated with any path. You then define floating static routes so that traffic to and from the DMZ web server will always use path 1 or 3 if available and only use path 2 or 4 if there is no other choice. Note that for failure recovery to work, it's essential that the only way that the routers can learn a route to any of the target addresses on the other side of the firewall be through BGP.
Since BGP includes the address of the next hop to take as part of the route advertisement, you'll also need to configure your BGP speakers to override that address with the correct address for the firewall. The specific technique used will depend on the BGP implementation. The critical requirement is that you don't believe the next hop specified by the router on the other side of the firewall, as to do so would severely degrade the security protection provided by the firewalls.