Redundant firewalling on OpenBSD: bridging mode

Jurjen Bokma

June 2009

Figure 1.  Two redundant bridging firewalls
Two interconnected firewalls protecting a server in a bridged network section

The above Conference under Docker 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


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 56.  Creation of the dual-redundant-bridging-firewall setup above

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

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

      pass log all

  2. To /etc/rc.conf.local append:

      pflogd_flags=" -i pflog0"

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

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

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



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

  5. In /etc/hostname.vr3:

      inet NONE

  6. In /etc/hostname.pfsync0:

      syncdev vr3

  7. 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:

tcpdump -nettti pflog0