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 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]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 50.  Creation of the dual-redundant-bridging-firewall setup above
[Note]Note

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:

      pf=YES
      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
    up
    	

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

      up
    	

    [Note]Note

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

  5. In /etc/hostname.vr3:

      inet 192.168.14.4 255.255.255.0 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:

brconfig
tcpdump -nettti pflog0
ifconfig