Bridged interfaces behave somewhat differently than non-bridged interfaces, and for that reason, you may find there are some things that cannot be done with bridges. In other cases, you may have to make modifications in order to get a pfSense feature to work with bridging.

Captive portal requires an IP on each interface on which it is active; this IP address is used to serve the portal contents. But bridged interfaces do not have an IP address. Therefore, captive portal does not work with bridging.

Another situation where bridged interfaces can be problematic is with multi-WAN setups. This is because the nodes on the bridged interfaces often have a different gateway than pfSense, and the router that is the default gateway for these nodes is the only device that can direct traffic from these nodes. However, multi-WAN can still work on a pfSense firewall in the following situations:

• Nodes on the bridged interfaces have pfSense as their default firewall
• Multi-WAN is being used only on non-bridged interfaces

CARP also does not work well with bridging. A standard CARP setup with two firewalls, one master and one backup will have both firewalls connected to the switch for each internal interface (for example, LAN and OPT1). This is acceptable, as there is still only one path to each of the switches for a node. The two network segments are essentially merged into a single larger network when they are bridged. A loop is formed when two paths are created between the switches for each interface. For example, in a CARP setup without looping, a node on LAN has one path to a node on OPT1—through the master firewall. If the interfaces are bridged, however, there will be two paths to OPT1—the bridge on the master firewall and the bridge on the backup firewall.

If the interface switch is a managed switch, we can handle it better by implementing STP or RSTP on the managed switch. Unmanaged switches, however, have no way of preventing looping, and looping can essentially crash a network.

There is another way of using bridged interfaces with CARP, although it is somewhat inelegant. It entails the following steps:

1. Configure your master and backup firewalls as you would with any CARP deployment, taking care to ensure the interface assignments are identical on all firewalls. This should carry over to the bridged interfaces; the bridges should be copied so they are also identical.
2. If you are using managed switches, use STP/RSTP to ensure the port connecting the switch to the master firewall has priority over the port connecting the switch to the backup firewall. When you have finished configuring the ports, confirm that the master firewall's port is forwarding traffic and the backup firewall's port is blocking traffic.
3. Another possible method is to use a script to ensure that a bridge on the firewall is up only if the firewall is designated as MASTER. This can be done by running the ifconfig command on the carp0 interface, and checking the content of the command's output using a command such as grep. Once you have installed the script, you can run the script automatically using the cron daemon. You likely want to run the script fairly often—for example, every 60 seconds—to ensure that when there is a failover, it is as smooth as possible.
4. Yet another possible method is to use devd to catch when the actual CARP state transition happens. You can edit /etc/devd.conf on the master and backup firewalls so that the bridge (or bridges) is brought up and down whenever a CARP state transition is detected.

It is beyond the scope of this chapter to describe these procedures in detail. If you require implementing this solution on your network, you can find these methods described in a post at the official pfSense forum at http://forum.pfsense.org/ index.php/topic,4984.0.html.