pfSense VLAN Configuration Explained: Tags, Rules, DHCP

pfSense VLAN configuration explained in short: create an 802.1Q VLAN on a parent NIC under Interfaces > Assignments > VLANs, assign it as an interface, give it a static gateway address, enable DHCP, then write pass rules, because a new VLAN blocks everything until you do. The switch port facing pfSense must tag every VLAN.

Each VLAN becomes a routed interface, so IoT traffic bound for your laptop climbs the trunk, meets the rule set and comes back down only if a rule allows it. That is the point, and why a broken VLAN build is usually a rule problem disguised as a switch problem.

How does a VLAN work inside pfSense?

A pfSense VLAN is a virtual interface stacked on a physical parent NIC. Frames leaving it get a 4-byte 802.1Q tag carrying a VLAN ID from 1 to 4094; tagged frames arriving on the parent land on the matching VLAN. Once assigned, it behaves like LAN or OPT1, with its own address, DHCP scope and firewall tab.

A working configuration is a chain of six links; breaking any one kills the segment:

1. VLAN definition: parent interface plus tag.
2. Interface assignment: the VLAN becomes OPTx.
3. Interface settings: enabled, static IPv4, no upstream gateway.
4. Services: a DHCP scope and reachable DNS.
5. Firewall rules on the VLAN’s own tab.
6. A switch trunk tagging the VLAN toward pfSense.

Two fields on the VLAN configuration page are best left alone. VLAN Tag Type defaults to C-Tag (0x8100); S-Tag (0x88a8) is for the outer tag of 802.1ad QinQ. VLAN Priority stamps an 802.1p PCP value from 0 to 7 on every frame; leave it blank unless your switch queues on PCP. The Wireshark wiki shows the tag: priority bits, a CFI/DEI bit and a 12-bit VLAN ID.

Netgate’s terminology page says the parent interface should ideally be “the parent for the defined VLANs and not used directly,” since direct use puts the default VLAN on the trunk. VLANs and Security explains why: untagged trunk traffic is assumed to be the native VLAN, and frames double-tagged with the native VLAN can hop into another one. Tag everything.

What do you need before configuring VLANs?

You need an 802.1Q-capable managed switch and a VLAN-capable network adapter. Netgate’s VLAN overview states VLANs cannot be used with an unmanaged switch. Any managed switch with 802.1Q trunk and access ports qualifies, from a MikroTik CRS328 to a UniFi USW-Pro-24-PoE.

The tag pushes a full-size frame to 1522 bytes. Hardware VLAN tagging helps but is not required; Netgate lists em(4), igb(4) and ix(4) among drivers that do it, and calls Realtek rl(4) NICs “the biggest offenders” for long-frame trouble. If small pings cross a VLAN but large transfers stall, suspect the NIC before the rules.

A four-VLAN plan for a home network

VLAN IDs match the third octet, VLAN 1 is unused, and every subnet sits inside 10.0.0.0/8 from RFC 1918. Netgate says VLAN 1 “should not be used when deploying VLAN trunking” and switch management should stay off it too, hence MGMT on 10. The parent here is igb1; yours may be igc1 or ix1.

How do you create a VLAN in the pfSense GUI?

Define the tag, assign it, then enable and address it. The steps below build VLAN 30 (IOT); repeat for 10, 20 and 40. Work from an existing LAN host, since the anti-lockout rule only protects the LAN address.

1. Interfaces > Assignments > VLANs > Add. Parent Interface igb1, VLAN Tag 30, Tag Type C-Tag, Priority blank, Description IOT. Save.
2. Interface Assignments tab. Pick the VLAN from Available network ports and click Add. It becomes the next OPT interface.
3. Interfaces > OPTx. Enable it, rename it IOT, set Static IPv4 10.0.30.1/24, and leave the IPv4 upstream gateway at None. Netgate’s additional LAN guide notes an unset gateway makes the firewall treat the interface as a LAN.
4. Services > DHCP Server > IOT. Enable it, set the range 10.0.30.100 to 10.0.30.199, and leave the rest at defaults.
5. Firewall > Rules > IOT. Add the rules below.

The console path (option 1, Assign Interfaces) only sets parent and tag, and warns “all existing VLANs will be cleared if you proceed.” Keep it for fresh installs.

What firewall rules does a pfSense VLAN need?

A pfSense VLAN needs explicit pass rules on its own tab; a new interface has none, so default deny blocks all its traffic. Rules are read top to bottom, first match wins. pfSense is stateful, so traffic “need only be permitted on the interface where it enters the firewall.”

Create a Network alias RFC1918 under Firewall > Aliases holding 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16, then build the IOT tab in this order:

GUEST gets the same four rules. TRUSTED gets DNS to the firewall, a pass to IOT subnets, a block to RFC1918, then a pass to any. MGMT gets one pass to any. IoT replies to TRUSTED need nothing on the IOT tab; state tracking carries them.

Rule 2 matters because This Firewall (self) matches every IP address on every firewall interface, including the public WAN address the RFC1918 alias misses. Without it, rule 4 lets an IoT device reach the GUI through the WAN IP.

Rule-shadowing risks

• Rule 4 above rule 3: first match wins, so IoT reaches every VLAN.
• Rule 2 above rule 1: clients get leases but cannot resolve names.
• Interface groups: pfSense evaluates floating, then interface group, then interface rules, per rule methodology. A block in a group shared by IOT and GUEST cannot be overridden on the IOT tab.
• Subnet macros: “IOT subnets” matches only 10.0.30.0/24, never networks reachable through the interface.

When something breaks, read Status > System Logs > Firewall. Out of the box pfSense logs every default-deny drop and no passed traffic, per Netgate’s rule best practices. An IPS runs per interface, so each VLAN you add it to adds load; Snort vs Suricata on pfSense compares each engine’s resource cost.

How should the switch and access points be configured?

The port facing pfSense is a trunk tagging VLANs 10, 20, 30 and 40; every device port is an untagged access port on one VLAN with a matching PVID. Netgate’s switch VLAN recipe gives the order: define VLANs on the switch, configure the trunk and access ports, then set PVIDs where required.

ONT          -> pfSense igb0        WAN, no shared switch
pfSense igb1 -> USW-Pro-24-PoE p1   trunk, tagged 10,20,30,40
p2           -> U6-Enterprise       native 10, tagged 20,30,40
p3-p12       -> desktops, NAS       access, untagged 20, PVID 20
p13-p20      -> IoT hubs, TVs       access, untagged 30, PVID 30

The AP port is the deliberate exception to tagging everything: many controller-managed APs expect adoption over untagged traffic, so MGMT rides native there while each SSID maps to a tagged VLAN. Netgate’s security page adds: physically secure trunk ports, disable dynamic trunk negotiation, and keep switch firmware current.

How do you get mDNS discovery working across VLANs?

Install the Avahi package and reflect mDNS between TRUSTED and IOT only. mDNS is link-local by design: RFC 6762, Multicast DNS, sends .local queries to 224.0.0.251 on UDP 5353, and those names are “meaningful only on the link where they originate.” Segmentation therefore breaks Bonjour and Chromecast discovery.

Netgate’s bridging notes describe Avahi listening on two broadcast domains and rebroadcasting between them, which lets you keep routed subnets instead of bridging. Leave GUEST out of the reflector.

The UDP Broadcast Relay package can relay 224.0.0.251:5353 too, but fails to start if Avahi holds port 5353, so pick one. It creates no firewall rules, and either way discovery only makes the speaker visible: the session still needs TRUSTED’s pass to IOT. DNS is simpler. The DNS Resolver listens on every interface by default, so rule 1 is all it needs.

What should you test before calling it done?

Test every policy line from a client on each VLAN, not the firewall itself: one expected pass and one expected block per rule, plus a capture proving tags arrive. A wrong result points at a specific rule or the trunk. From an IoT client:

nslookup pfsense.org 10.0.30.1   # answer expected (rule 1)
ping -c 4 10.0.20.1              # timeout expected (rule 2)
ping -c 4 10.0.20.50             # timeout expected (rule 3)
mtr -rwc 20 9.9.9.9              # first hop 10.0.30.1, clean path out

A ping to 10.0.30.1 also times out; that is rule 2 working. From TRUSTED, with iperf3 -s running on an IoT host at 10.0.30.50:

ping -c 4 10.0.30.50             # replies expected (TRUSTED to IOT)
iperf3 -c 10.0.30.50 -t 30       # routed inter-VLAN throughput
iperf3 -c 10.0.30.50 -t 30 -R    # reverse direction

Inter-VLAN traffic is routed and filtered, so size for it like WAN traffic using pfSense workload sizing, and work through finding the pfSense bottleneck if iperf3 comes in short. Last, confirm tags reach the firewall from the pfSense shell:

tcpdump -nei igb1 -c 20 vlan 30

The -e flag prints the link-level header, VLAN ID included. If nothing tagged 30 appears while an IoT client requests a lease, fix the switch trunk, not pfSense.

FAQ

why does my pfsense vlan have no internet

Usually because the new VLAN interface has no firewall rules, so pfSense’s default deny drops every packet. Add a pass rule with the VLAN’s subnet as source on its own tab. If clients get no DHCP lease, the switch trunk is not tagging that VLAN or the DHCP server is not enabled.

what is the difference between tagged and untagged vlan ports

A tagged port sends frames with the 802.1Q header intact, so the far-end device must understand VLANs; that is the trunk to pfSense or an AP. An untagged access port strips the tag on egress and applies its PVID on ingress, so ordinary clients never see a tag.

do vlans slow down pfsense

Not by themselves. The 802.1Q tag adds 4 bytes per frame, and Netgate notes NICs without hardware VLAN tagging still work, just less efficiently. The real cost is inter-VLAN routing: every packet between VLANs is filtered by the firewall and crosses the trunk twice, competing with internet traffic for the same port.