pfSense Bridge Setup - Step-by-Step Configuration Guide

A bridge combines multiple pfSense network interfaces into a single broadcast domain, enabling firewall filtering of traffic passing between them. This guide covers bridge creation, Spanning Tree Protocol configuration, applying firewall rules to bridged traffic, transparent firewall deployment, and resolving common issues. Before creating a bridge, ensure the participating interfaces are assigned in the system via Interfaces > Assignments, though they do not necessarily require IP addresses.

Creating a Bridge

Basic Configuration

To create a bridge, navigate to Interfaces > Assignments, select the Bridges tab, and click Add.

1. In the Member Interfaces field, select the interfaces to combine into the bridge. Use Ctrl+Click to select multiple interfaces
2. Enter a bridge description in the Description field
3. Click Save

After saving, the system creates a virtual interface named bridgeX (where X is a sequential number starting at 0). This interface must be assigned through Interfaces > Assignments for further IP address and firewall rule configuration.

IP Address Assignment

The IP address is assigned to the bridge interface, not to its member interfaces. Navigate to Interfaces > [assigned bridge interface], enable it, and configure the IP address. Member interfaces generally should not have their own IP addresses unless required for specific scenarios.

Spanning Tree Protocol

When multiple bridge member interfaces connect to the same switch or to interconnected switches, Layer 2 loops can form. A loop causes frames to circulate endlessly, bringing the network to a complete halt. Spanning Tree Protocol (STP) prevents loops by blocking redundant paths.

Protocol Selection

pfSense supports two options:

RSTP is backward compatible with STP and provides significantly faster convergence when the topology changes.

STP Parameters

Advanced STP parameters are available in the bridge settings:

• Valid Time - BPDU message lifetime (default 20 seconds, range 6-40)
• Forward Time - time for a port to transition from blocking to forwarding state (default 15 seconds, range 4-30)
• Bridge Priority - bridge priority for root bridge election (default 32768, lower value equals higher priority)
• Port Priority - individual port priority within the bridge (affects active path selection)
• Path Cost - cost of the path through the port (affects optimal route selection)

Edge and PTP Ports

• Edge ports - ports connected to end devices (workstations, servers). They transition to forwarding state immediately, bypassing the listening and learning phases
• PTP ports - ports connected to other switches (potential loop risk). They go through the full STP cycle
• Auto detect - automatic port type detection based on received BPDUs

Bridge Traffic Filtering

Firewall Rules

Firewall rules are applied to bridge member interfaces, not to the bridge interface itself. This is a key difference from routed interfaces. To filter traffic between bridge members, create rules on the corresponding interface tabs in Firewall > Rules.

For proper bridge filtering operation, the following parameters must be configured in System > Advanced > System Tunables:

net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_member=1

The pfil_member=1 parameter activates filtering on bridge member interfaces. The pfil_bridge=0 parameter disables filtering on the bridge interface itself (the recommended configuration for most scenarios).

MAC Address Cache

• Cache Size - maximum number of entries in the bridge MAC address table (default 100)
• Cache Expire - entry lifetime in the table in seconds (default 240)

Private and Sticky Ports

• Private ports - prevent traffic exchange between designated bridge ports. Devices on private ports can communicate only with non-private ports
• Sticky ports - permanently lock learned MAC addresses in the cache, preventing their eviction

Span Ports

A span port transmits copies of all frames passing through the bridge to a designated interface. This enables connecting a monitoring system (IDS, traffic analyzer) for passive observation without affecting network traffic.

Use Cases

Transparent Firewall

A transparent firewall filters traffic between the WAN and internal network without altering routing. pfSense is inserted into the existing network as an invisible bridge between segments.

To configure a transparent firewall:

1. Create a bridge containing the WAN interface and an internal interface
2. Assign the bridge an IP address for management (from the same subnet as the existing network)
3. Do not configure NAT - in transparent mode, the firewall is not a gateway
4. Create firewall rules on the bridge member interfaces

Internal devices continue using the existing router as their gateway. NAT does not function on transparent bridges because pfSense is not acting as the gateway.

Combining Physical Ports

A bridge allows multiple pfSense physical ports to function as ports on a single switch. This is useful when the available switch has limited ports or when devices need to connect directly to pfSense ports with traffic filtering.

Wireless Interface Bridging

Combining wired and wireless interfaces into a bridge places devices of both connection types in the same L2 segment. Firewall rules on the wireless member interface provide additional access control for Wi-Fi clients. For guest user authentication on the wireless network, use Captive Portal in conjunction with the bridge.

Limitations

Performance

Bridge processing is handled by the CPU, not by a hardware switch. Throughput is substantially lower than a dedicated switch. Do not use bridges as replacements for switches in high-throughput traffic scenarios.

CARP and Bridges

Using CARP (Common Address Redundancy Protocol) with bridged interfaces has limitations. CARP addresses must be assigned to the bridge interface, not to its members. High-availability configuration with bridges requires thorough testing.

Service Compatibility

Some pfSense services require additional configuration when used with bridged interfaces:

• Captive Portal - the zone must be bound to the bridge interface
• Limiters - require special configuration
• Transparent proxy - limited compatibility on bridged interfaces

NAT

NAT does not function on transparent bridges because the firewall does not act as a gateway. For scenarios requiring NAT, use routed interfaces instead of bridges.

Troubleshooting

Layer 2 Loops

Signs of a loop: complete loss of network connectivity, high CPU utilization, abnormal volume of broadcast traffic in Diagnostics > States.

• Verify STP or RSTP is enabled in the bridge settings
• Check that bridge member interfaces are not connected to the same switch without STP configured on the switch
• Temporarily disable one bridge member to break the loop

Traffic Not Passing Through the Bridge

• Verify member interfaces are enabled and show link up status
• Ensure firewall rules on member interfaces allow the required traffic
• Check the net.link.bridge.pfil_member value in System > Advanced > System Tunables
• Use Diagnostics > Packet Capture on bridge interfaces to analyze traffic

Performance Issues

• Check CPU utilization in Diagnostics > System Activity - high load indicates the bridge is exceeding capacity
• Ensure MTU is identical across all bridge members
• Consider replacing the bridge with a hardware switch using VLANs for segmentation

Bridge Not Appearing in Interface List

After creating a bridge, it must be assigned through Interfaces > Assignments. An unassigned bridge does not appear in interface settings and cannot be used for IP address binding or firewall rules.