Figure 1.  Two redundant bridging firewalls

The above shows two bridging firewalls running OpenBSD. They talk pfsync with one another to keep the firewall states synced, and they talk STP (Spanning Tree Protocol) against broadcast storms. This setup achieves automatic failover when one firewall is taken out, with network downtime on the order of a minute (sometimes less, sometimes a bit more).

I configured this after looking through The Book of PF, OpenBSD docs on CARP and pfsync (in Dutch!), the OpenBSD FAQ, the OpenBSD manpage on brconfig, a work by Dylan Martin on redundant bridges and finally the OpenBSD manpage on hostname.if files

	Warning
	Even though this is working nicely in my limited-traffic controlled-conditions no-production home network, I cannot judge the robustness of the setup. I have heard that STP can play some funny tricks on you in large networks, and I wouldn't put this configuration in a network without thoroughly making sure I've got permission and supervision from a network administrator.

Procedure 57.  Creation of the dual-redundant-bridging-firewall setup above

	Note
	All of the below steps need to be executed on both participating firewalls

1. Create a rudimentary firewall

   Since filtering is not yet our goal here, in /etc/pf.conf create a trivial ruleset:

     pass log all
   	

2. Turn on packet filtering

   To /etc/rc.conf.local append:

     pf=YES
     pflogd_flags=" -i pflog0"
   	

3. Configure the bridge

   In /etc/brconfig.bridge0, bring up the bridge with STP enabled:

   add vr1 add vr2
   blocknonip vr1 blocknonip vr2
   stp vr1
   stp vr2
   up
   	

4. Configure the bridge interfaces

   In /etc/hostname.vr1 as well as /etc/hostname.vr1, simply put:

     up
   	

   	Note
   	It is assumed that another NIC, not listed here, is serving SSH so the admin can log in.

5. Configure the pfsync interface

   In /etc/hostname.vr3:

     inet 192.168.14.4 255.255.255.0 NONE
   	

6. Turn on pfsync

   In /etc/hostname.pfsync0:

     syncdev vr3
   	

7. Reboot into the configured state

   reboot

Now you can test the setup by doing something on the server that needs connectivity, like pinging (not a good example to test statefulness of the firewalls), streaming a movie, or simply ssh to it across the firewalls. When you are satisfied, test the robustness by randomly detaching network cables from one of the firewalls, turning it off, and when it's up again, repeat that procedure with the other one.

In my case, the redundant firewall mostly took about half a minute to a full minute to restore the connection when the active firewall went down. In some cases, the rebooting machine was fast enough to be up again before the other had taken over.

Some interesting commands: