Choose whether pfSense bridge members or the bridge interface own filtering

Rules on an unnumbered member cannot rely on that member’s address macros.

Source facts

Netgate documents separate pfil_member and pfil_bridge tunables controlling filtering on bridge members and the bridge itself; at least one must be enabled. Only one bridge interface or member holds the IP address. Address and network macros for an unnumbered member are undefined, so rules must use explicit subnets or the macros belonging to the numbered interface.

Source: Netgate — Bridging and Firewall Rules.

Applicability

This concerns pfSense bridged Layer 3 filtering.

DSE recommendation

DSE recommends selecting one clearly documented policy location before building the rule set. Record the tunable values and which interface actually owns the subnet. Replace ambiguous unnumbered-member macros with deliberate address objects. During a migration, review both the old and new filter locations so a rule is not accidentally stranded on a tab that no longer controls traffic. Keep management access within the same policy review. Document the policy owner beside the numbered interface in the bridge diagram. Include a denied management attempt in the rehearsal, and compare both filtering locations after any migration. Require the final rule inventory to identify which tabs remain operationally relevant.

Verification

On an approved test bridge, generate new allowed and denied flows from each member. Confirm which rule counters change and whether source and destination macros expand as expected. Record the active filtering location with the final configuration rather than relying on the GUI tab names alone.

Official reference

Netgate — Bridging and Firewall Rules. Reviewed October 20, 2026.