If you want to isolate IoT gear, run a guest Wi-Fi, or split work from play on the same physical network, learning how to set up VLANs on a managed switch with pfSense for network segmentation is one of the highest-leverage skills you can pick up.
I built my own segmented home lab on pfSense a few years back and quickly realized how much cleaner traffic becomes once you stop treating every device as a trusted neighbor. In this guide I walk through the same configuration I use day-to-day, from creating VLANs in pfSense all the way through your firewall rules.
You will learn the exact steps to define VLANs, configure trunk and access ports on a managed switch, hand out DHCP leases per segment, and lock down inter-VLAN traffic with sensible firewall rules.
Table of Contents
What Is a VLAN and Why Use It for Network Segmentation?
A VLAN, or virtual local area network, lets you split one physical switch into multiple logical networks. Each VLAN acts like its own broadcast domain, so devices in VLAN 10 cannot see broadcasts from VLAN 20 unless you explicitly route the traffic.
Network segmentation is the practice of placing different device classes, like work computers, guest Wi-Fi, and security cameras, into separate VLANs. I have found three practical benefits in my lab that make the effort worthwhile.
First, segmentation reduces blast radius. When my test smart plug starts misbehaving, it cannot reach the workstation holding my passwords because it lives on a different VLAN with a deny-by-default rule.
Second, performance improves. Broadcast traffic from noisy IoT devices stays confined to its own VLAN, so my editing workstation is not drowning in mDNS chatter from the smart home gadgets.
Third, it gives you clean policy controls. A single firewall rule on pfSense decides whether the guest Wi-Fi can reach the printer, instead of relying on per-device ACLs on every switch port.
Prerequisites: Hardware and Software You Need Before Starting
Before you touch a single setting, confirm that you actually have the building blocks. None of these are exotic in 2026, and most home lab enthusiasts already own them.
pfSense router or firewall with at least one free Ethernet port to connect to your managed switch.
Layer 2 managed switch supporting IEEE 802.1Q VLAN tagging. HPE OfficeConnect, Ubiquiti EdgeSwitch, Zyxel GS series, and TP-Link Easy Smart switches like the TL-SG108E all work.
At least one Cat5e or Cat6 Ethernet cable to link the pfSense box to the switch trunk port.
Devices or access points to assign to each VLAN, plus a way to reach the pfSense web GUI from a safe management network.
Console or direct access fallback in case a config change locks you out of the web interface.
I always recommend having a small console cable or a spare laptop ready. If you accidentally change the VLAN on the port your management computer is connected to, you will want a way back in.
Understanding 802.1Q Tagging, Access Ports, and Trunk Ports
Before configuring anything, you need a short mental model of how VLANs actually travel across a wire. The whole system rests on three concepts that took me a while to internalize when I first set this up.
802.1Q is the IEEE standard that adds a tiny tag to each Ethernet frame, identifying which VLAN it belongs to. The tag is just four bytes inserted into the frame header, and your managed switch uses it to keep traffic sorted.
An access port carries traffic for exactly one VLAN and leaves the tag stripped off when frames leave the port. Plug a desktop into an access port on VLAN 10, and that desktop only sees VLAN 10 traffic, untagged.
A trunk port carries traffic for multiple VLANs, keeping the 802.1Q tag intact so the other side knows which VLAN each frame belongs to. The link between your pfSense box and your managed switch is almost always a trunk port.
PVID, or port VLAN identifier, is the VLAN assigned to untagged frames arriving on a port. The native VLAN on a trunk plays a similar role, holding the untagged traffic for compatibility with older devices that do not understand tagging.
Step-by-Step: Creating VLANs in pfSense
The work begins in the pfSense web interface. I keep a checklist of VLAN IDs, subnets, and friendly names ready because it is easy to lose track after VLAN 30.
Step 1: Decide your VLAN plan. A common layout in 2026 labs looks like this.
VLAN 10 – Management – 10.0.10.0/24
VLAN 20 – Trusted devices – 10.0.20.0/24
VLAN 30 – Guest Wi-Fi – 10.0.30.0/24
VLAN 40 – IoT and smart home – 10.0.40.0/24
Step 2: In pfSense, navigate to Interfaces > Assignments > VLANs and click Add. Enter the parent interface (typically igb0 or em0), the VLAN tag such as 10, and a short description.
Step 3: Repeat for each VLAN tag you planned. pfSense creates a virtual interface for each VLAN, named something like igb0_vlan10, with a one-to-one mapping between VLAN ID and tag.
Step 4: Open Interfaces > Assignments and add each new VLAN interface as OPT1, OPT2, and so on. Click each one, enable it, and give it a friendly description like IOT, GUEST, or MGMT.
Step 5: On each OPT interface, configure a static IPv4 address. For VLAN 10 I use 10.0.10.1/24, for VLAN 30 I use 10.0.30.1/24, and so on. This address becomes the default gateway for clients on that VLAN.
Step 6: Save and apply. At this point pfSense knows about every VLAN, but no traffic is flowing yet because the trunk to the switch is still unconfigured.
Step-by-Step: Configuring VLANs on Your Managed Switch
Now we move to the managed switch. The exact menus differ by vendor, but the concepts apply across HPE, Ubiquiti, Zyxel, and TP-Link.
Step 1: Log into the switch web interface and find the VLAN or 802.1Q section. Create each VLAN ID that matches the pfSense list, and give it a friendly name like MGMT, TRUSTED, GUEST, or IOT.
Step 2: Mark the uplink port to pfSense as a tagged member of every VLAN. On an HPE OfficeConnect this means editing the trunk port, adding each VLAN ID to the tagged list. On a Zyxel GS1200 you check the boxes for tagged membership in the VLAN membership table.
Step 3: For each device port, mark it as an untagged member of exactly one VLAN. Port 5 hosting a workstation becomes untagged on VLAN 20, port 7 hosting a printer becomes untagged on VLAN 10, and so on.
Step 4: Set the PVID for each access port to match the VLAN it belongs to. If a device on port 8 sends an untagged frame, the switch tags it with VLAN 30 because PVID is set to 30.
Step 5: Leave VLAN 1 as the native VLAN on trunks unless your vendor warns otherwise. Most vendors let you reassign the native VLAN, but I keep VLAN 1 as the management default and use my own IDs for everything user-facing.
Step 6: Save and reboot the switch if required. Some switches apply changes immediately, while others batch them until the next reload.
Setting Up Trunk Ports for VLAN Tagging
The trunk port is the single most important link in the whole setup, so it deserves its own section. Get this wrong and every VLAN either silently breaks or floods across ports you did not intend.
On the switch, take the physical port connected to pfSense and set it as a trunk. In practice that means tagging all VLANs you want to cross the link, while leaving the native VLAN (usually VLAN 1) untagged for management reachability.
On pfSense, the parent interface that the trunk cable plugs into stays in its default configuration. The VLAN sub-interfaces created earlier handle the tagging, so the parent interface itself does not need a static IP unless it acts as your WAN.
Hardware-specific notes from my own deployments and community forums:
HPE OfficeConnect uses VLAN Trunk mode with Tagged and Untagged VLAN lists per port.
Ubiquiti EdgeSwitch treats 802.1Q as the default. Switch ports show tag membership under Switching > VLAN.
Zyxel GS1200 uses a VLAN ID and Tag checkbox in the VLAN > VLAN Configuration page.
TP-Link Easy Smart (TL-SG108E) needs the 802.1Q VLAN tag dropdown per port with membership set to Tagged.
Quick sanity check: plug a laptop running Wireshark or tcpdump on the trunk port while you ping from VLAN 20. You should see 802.1Q tags in the captured frames with the correct VLAN ID.
Configuring DHCP Servers for Each VLAN
Once VLANs route through pfSense, handing out IP addresses is straightforward. pfSense runs a per-interface DHCP server, so each VLAN gets its own scope.
Step 1: In pfSense, open Services > DHCP Server and pick the OPT interface that corresponds to your VLAN, for example OPT1 for VLAN 10.
Step 2: Check Enable DHCP server on that interface and fill in the range, such as 10.0.10.100 to 10.0.10.200 for VLAN 10.
Step 3: Enter the gateway (the pfSense OPT interface IP, 10.0.10.1) and DNS servers. I point everything at pfSense itself and let the resolver forward upstream.
Step 4: Repeat for each VLAN. Save and apply, then connect a device to an access port and confirm it pulls a lease from the right scope.
If the lease never comes, the usual suspect is a missing firewall rule blocking DHCP. I cover that next.
Creating Firewall Rules for Inter-VLAN Communication
Here is where segmentation actually pays off. pfSense blocks inter-VLAN traffic by default if you play it smart, but only if you do not accidentally allow any-any rules on the LAN.
Step 1: Open Firewall > Rules, pick the MGMT VLAN interface, and add a rule that allows traffic from MGMT net to any destination on TCP port 22 and 80, so you can reach pfSense and the switch GUI.
Step 2: Move to the GUEST interface and add a rule that allows guests out to the WAN (the internet) but does not allow any traffic into any RFC1918 destination. That keeps guest Wi-Fi isolated.
Step 3: For the IOT interface, add a rule that allows clients to reach the internet but blocks access to MGMT, TRUSTED, and any local subnet. Optionally, allow specific destinations such as a Home Assistant server on TRUSTED if you need cross-VLAN control.
Step 4: For the TRUSTED interface, allow all outbound to the internet and any-to-any to MGMT, but block IOT and GUEST by default. Add explicit allow rules only where you actually need them.
Step 5: Save and apply changes, then test each rule with a ping from one VLAN to another. If traffic leaks where you do not want it, your rules are too permissive and need tightening.
Community wisdom from r/PFSENSE and the Netgate forum favors a strict default-deny posture. Lawrence Systems has long recommended blocking all RFC1918 from guest and IoT networks, then opening holes one by one as required.
Testing and Verifying Your VLAN Setup
After saving firewall rules, run a quick battery of tests before declaring victory. I use four checks that catch about 90 percent of mistakes I have made myself.
First, ping from a device on the new VLAN to its gateway. If the gateway does not respond, the access port or the trunk is misconfigured.
Second, ping a host on a different VLAN. If it fails, your firewall rules are blocking it – which is what you probably want.
Third, request a fresh DHCP lease. If you receive an address from the wrong subnet, double-check the PVID on the access port.
Fourth, browse the web. Many VLAN problems hide behind DNS, so if DNS resolves but web traffic fails, check the firewall rule from the VLAN to WAN.
Troubleshooting Common VLAN Issues
Even clean configurations hit snags. Here are three issues I have hit more than once, with quick fixes drawn from Netgate forum threads and the Lawrence Systems community.
If clients cannot pull DHCP leases, walk the path from device to pfSense: confirm the access port PVID matches the VLAN, confirm the trunk allows that VLAN tagged, and confirm a firewall rule on the VLAN interface permits UDP ports 67 and 68.
If traffic reaches the gateway but not other VLANs, your firewall rules are blocking it. pfSense inter-VLAN routing works out of the box; only rules stop it. Add an explicit allow rule and re-test.
If the switch management GUI becomes unreachable after enabling 802.1Q, your management VLAN probably changed on the trunk. Reassign the switch management VLAN to VLAN 10 (or whichever ID you chose for management), save, and reconnect from a port assigned to that VLAN.
Frequently Asked Questions
Is a managed switch needed for VLANs?
Yes. VLAN tagging uses 802.1Q, which a Layer 2 managed switch enforces. An unmanaged switch treats every port as part of one broadcast domain and cannot separate VLANs. Cloud-managed switches from Ubiquiti, switches from HPE, and TL-SG108E-class devices all qualify.
Do VLANs need their own subnet?
Every VLAN should have its own IP subnet so clients know where to send traffic. A common setup uses 10.0.10.0/24 for VLAN 10, 10.0.20.0/24 for VLAN 20, and so on. Sharing a subnet across two VLANs breaks ARP and routing.
How do I configure VLANs on pfSense?
Go to Interfaces u0026gt; Assignments u0026gt; VLANs, add a VLAN tag against the parent interface, then assign the new VLAN under Interfaces u0026gt; Assignments as OPT1 or OPT2. Enable the interface, give it a static IPv4 address in its own subnet, and enable the DHCP server under Services u0026gt; DHCP Server.
Is pfSense outdated?
pfSense is still actively maintained in 2026 and remains one of the most widely deployed open-source firewalls for home and small business networks. It supports 802.1Q VLAN tagging, has a mature web GUI, and integrates well with managed switches for segmentation work.
What switch ports should be trunk vs access?
The uplink to pfSense should be a trunk port carrying all VLANs you want to route. Every device-facing port should be an access port on a single VLAN, with the correct PVID set. Trunk ports to other switches follow the same rule, tagged for all VLANs that need to cross.
Why can devices on different VLANs not talk to each other?
Because pfSense blocks inter-VLAN traffic unless you add firewall rules. By design, VLANs isolate traffic at Layer 2 and rely on firewall policy to decide what crosses. Add an explicit allow rule on the source VLAN interface to permit the specific traffic you want.
Conclusion
Setting up VLANs on a managed switch with pfSense is one of those projects that pays you back every day. Once you understand the path – VLANs on the switch, OPT interfaces in pfSense, DHCP scopes per VLAN, and firewall rules to gate traffic – the configuration becomes repetitive instead of mysterious.
Start with a plan: pick your VLAN IDs, subnets, and friendly names before you touch the GUI. Then build the trunk, test each VLAN with a single device, and only then add the firewall rules that lock things down.
Take it step by step and your network will be more secure, faster, and easier to reason about than any flat network you have run before.