Virtual pfSense TAP Bridge: Three Places a Frame Can Die

You disable a rule on the LAN interface, the frame still disappears, and the conclusion is that pfSense is ignoring its own firewall. What usually happened is that a different owner made the decision: the bridge itself, the member interface, or the virtual switch outside the guest. Each has its own control and its own log.

The three boundaries below are worth separating before you change a setting, because disabling one cannot compensate for another.

One frame, three policy owners

A frame from a TAP client enters through the tunnel device, crosses the pfSense bridge, leaves through a LAN member, and then passes a virtual switch before it reaches anything. Inside the guest, filtering can happen on the bridge or on the member interfaces, and which one is active is a configuration choice rather than a fixed property. Outside the guest, the hypervisor decides whether that virtual adapter may transmit frames with a source MAC it does not own. A drop at any of those points looks identical from the client.

Write the intended path down before investigating: tunnel member, bridge, LAN member, virtual switch, destination. Then ask which owner on that path would have seen the frame.

Which pfSense control is filtering

pfSense documents two sysctls for this, one for filtering on the bridge members and one for filtering on the bridge itself, and at least one of them has to stay enabled. Bridge-level filtering applies to traffic arriving through the bridge members, so it is inbound in orientation rather than symmetric. Read the rules on the interface that is actually filtering, because a rule set on a member with no filtering role does nothing at all. The bridge filtering documentation spells out the ownership.

A member interface without an IP address has no address or subnet macro of its own, so a rule written against that macro can describe something other than the LAN you meant. Use deliberately assigned network objects instead of convenience macros.

A fragment is not a frame

Ethernet frames carry IP packets, and an IP packet can be a fragment of a larger datagram, so the two words are not interchangeable. There is also an inner packet inside the tunnel and an outer transport packet outside it, and a failure can belong to either. A small ping exercises one path through that stack and proves nothing about a large transfer. Compare the failing exchange at two adjacent boundaries and read the drop reason before blaming a rule.

If fragments vanish, the answer is a scoped correction or a packet-size investigation, not a decision to disable filtering wholesale.

The hypervisor has its own admission decision

A guest bridging traffic for other machines emits frames whose source MAC addresses are not its own adapter's, and many virtual switches treat that as spoofing unless the port group allows it. Permitting that transmission and permitting the adapter to receive every frame are separate controls, and enabling both everywhere is a much larger change than the problem requires. Work out which frames the bridge has to receive and has to emit, then grant only that behaviour at the boundary that owns it. Keep console access before changing a remotely managed bridge.

Restoring connectivity is half the test; the other half is confirming that a flow which should stay blocked still is.

Record which owner filtered, which control changed and which two flows you verified. That record stops the next incident from starting with the same guess about pfSense ignoring itself.