Keep native VLAN behavior out of pfSense trust-boundary assumptions

A tagged-network design still needs an explicit policy for untagged traffic on trunks.

Source facts

Netgate warns that native VLAN handling can strip a matching outer tag and that double-tagged traffic can reach another VLAN under vulnerable trunk arrangements. Untagged traffic is assigned to the native VLAN. The guide recommends restricting access to trunk ports and avoiding careless mixing of outside-firewall and trusted inside networks on one switching design.

Source: Netgate — VLANs and Security.

Applicability

This is Netgate’s VLAN security guidance, not proof that a particular switch or firmware is exploitable.

DSE recommendation

DSE recommends documenting the allowed tagged VLANs, native VLAN, and handling of untagged frames on both ends of each trunk. Remove unused trunk access and place externally reachable equipment into a switching design appropriate to its trust level. Treat physical access to an enabled trunk as privileged network access. Keep the switch management network and ordinary endpoint networks deliberately assigned rather than inheriting a default VLAN accidentally. Include unused ports and the switch’s trunk-negotiation policy in the review, not only the active uplink. Have the switching owner explain where an untagged test frame should land, then compare that prediction with a controlled observation before accepting the trust boundary.

Verification

In a controlled network test, compare each permitted tagged VLAN with untagged and unauthorized-tag traffic. Confirm the observed interface and subnet on the firewall. Check both trunk endpoints and retain their configuration together; a correct VLAN interface on pfSense alone does not verify the switch path.

Official reference

Netgate — VLANs and Security. Reviewed October 20, 2026.