Configuration for transparently redundant firewalls
The goal of any network is communication. We can no longer be satisfied with simply sustaining communication, we need to do so safely and efficiently, according to networking expert Vincent Jones. Vincent Jones is the author of High Availability Networking with Cisco. And this tip from InformIT explains how to keep your network secure with a redundant firewall if a firewall or router goes down.
How the firewall appears to your routers, either as another router or as an end system, affect how the network can be designed. The tip is based on your routers viewing the firewall as another router.
Assume that each firewall will pass any legitimate Web traffic between any valid Internet address and the Web server at 188.8.131.52. 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.
Of course, there is more to it than just the how-to; read the background information at InformIT. Registration is required, but it is free.