Redundant firewalls with OpenBSD, CARP and pfsync
2. Network layout
First, let's take a look at the environment in which our firewall clusters will operate. It's a very simple and "classic" network, made up of:
- a DMZ (172.16.240.0/24), containing the publicly accessible machines (e.g. web and mail servers) and the intrusion detection sensors;
- a LAN (172.16.0.0/24), containing clients and servers not accessible from the public Internet (file server, DHCP server, internal DNS server...);
- a router, in a small subnet (172.16.250.0/24), to connect the network to the Internet.
This environment requires that we setup two firewall clusters: the first separating the DMZ from the Internet (we won't take into account any router filtering); the second between the LAN and the DMZ. The network looks roughly like this:
The great advantage of this topology is that it needs two firewall clusters, thus allowing us to look over two slightly different cluster configurations. Jokes apart, these are some of its major benefits:
- in case of a firewall compromise, the LAN is protected by an additional layer of filtering (though it would be better to use different firewall platforms, to prevent attackers from compromising the internal firewalls with the same technique);
- a single (though clustered) firewall, filtering both LAN and DMZ traffic, is a single point of failure;
- on each firewall, rules apply only to LAN or DMZ traffic, thus making PF rulesets cleaner and easier to maintain;
but there are also a few drawbacks:
- besides its own traffic, the DMZ must support the traffic load from the internal network to the Internet;
- double-filtering LAN traffic increases security but (slightly) affects performances;
- the cost of additional hardware may not be irrelevant.
Redundant firewalls with OpenBSD, CARP and pfsync