Since bridged interfaces act somewhat differently than nonbridged interfaces, you may find that there are some things you cannot do with bridges, or you may have to make some modifications to your usual configuration to get a feature to work with a bridge. We already saw an example of this with DHCP when we discussed how to configure a bridge. In this section, we will enumerate some other such cases.

If you are implementing a captive portal, you may be aware that it requires an IP on each interface on which it is active. This IP address is used to serve the portal contents. Bridged interfaces do not have an IP address; therefore, captive portal setups do not work with bridges.

Bridged interfaces can raise issues with mutli-WAN configurations. Nodes on the bridged interfaces often have a different gateway than pfSense. Further, the router that is the default gateway for these nodes is the only device that can route traffic from these notes. Nevertheless, you can configure a multi-WAN setup to work with bridged interfaces if either nodes on the bridged interfaces have pfSense as their default firewall, or if multi-WAN is only used on nonbridged interfaces.

We have not covered Common Address Redundancy Protocol (CARP) except in passing, other than to note that it is a method of having a completely redundant firewall or firewalls that can become active when the master firewall goes down, thus eliminating a significant single point of failure on the network and minimizing downtime. That having been said, CARP does not work well with bridging. Take the case of a standard CARP setup with two firewalls, one master and one backup. Both firewalls will be connected to the switch for each internal interface. This is an acceptable setup; each node has one path to each of the switches. The two network segments that are bridged are merged into a larger network and everything works. If interfaces are bridged on a network, then there will be two paths to a node on a bridged interface, namely, the bridge on the master firewall and the bridge on the backup firewall.

If we are using managed switches on the bridged interface, then we can handle this by implementing STP or RSTP on the managed switch.

If we have only unmanaged switches on the bridged interface, we might have issues getting the setup to work, but there is a method:

1. First, configure master and backup firewalls on your CARP setup, and make sure the interface assignments are identical on all firewalls (including bridged interfaces).
2. If you are using managed switches, use STP/RSTP to ensure the port connecting to the switch has priority over the port connecting the switch to the backup firewall. When you have completed the port setup, confirm that the master firewall's port is forwarding traffic and that the same port on the backup firewall is blocking traffic.
3. You may also be able to use a script to ensure the bridge on the firewall is only up if the firewall is designated as the master. You can do this by running the ifconfig command on the carp0 interface. Use the grep command to check the command's output. Once the script is installed, you can run the script automatically using the cron daemon.
4. Another way to ensure sending and receiving data is solid is to use devd. This will tell you when the CARP state transition occurs. You can edit devd.conf to ensure any bridges are brought up and down whenever there is a CARP state transition.

It is not the intention of this book to describe procedures for using bridges with a CARP setup. You can, however, find these issues discussed at the official pfSense documentation site here: https://www.netgate.com/docs/pfsense/highavailability/carp-cluster-with-bridge-troubleshooting.html.