AI-narrated version of this post using a synthetic voice. Great for accessibility or listening while busy.
Most home labs start the same way: one router, one switch, everything on the same flat network. It works fine until it doesn’t. The moment you’re running a NAS with personal photos, a few Docker containers pulling from the internet, and maybe a guest Wi-Fi access point, you’ve got devices with wildly different trust levels sharing the same broadcast domain. A misconfigured container or a compromised IoT device can reach your NAS directly – no barriers, no logging, no segmentation. VLANs fix this, and you don’t need enterprise gear to implement them. One managed switch and an afternoon is enough. This guide walks through the core concepts and a practical single-switch setup, using real config examples so you can adapt them to whatever switch is sitting on your shelf.
What a VLAN Actually Does
A VLAN – Virtual Local Area Network – is a way to partition a single physical switch into multiple logical networks. Devices on VLAN 10 cannot talk directly to devices on VLAN 20, even if both are plugged into the same 8-port box. Traffic between VLANs has to pass through a router (or a layer-3 switch acting as one), which means you can apply firewall rules at that boundary.
The practical effect: you’ve created network segments without buying additional hardware. Your lab traffic, your IoT stuff, and your trusted home devices all travel over the same cables and the same switch, but the switch treats each VLAN as a separate broadcast domain.
A few things VLANs are not: they’re not a substitute for encryption, they’re not foolproof against misconfiguration, and they don’t protect you from vulnerabilities in your router firmware. They’re one layer of a sensible defence-in-depth approach. That said, for a home lab, even a basic three-VLAN setup meaningfully reduces your attack surface.
The 802.1Q Standard
Consumer and prosumer managed switches implement VLANs using the IEEE 802.1Q standard. When a frame travels between switches (or between a switch and a router), 802.1Q inserts a 4-byte tag into the Ethernet frame header. That tag carries the VLAN ID – a number between 1 and 4094. The receiving device reads the tag and knows which VLAN the frame belongs to.
This is the mechanic behind “tagged” ports. When you configure a port as tagged for VLAN 20, the switch adds (or expects) that 4-byte tag on frames going in and out of that port. Devices that understand 802.1Q – other managed switches, your router running sub-interfaces, a hypervisor like Proxmox – can handle tagged frames natively.
Tagged vs Untagged Ports: The Part That Trips Everyone Up
This is where most first-timers get confused, so it’s worth being precise.
An untagged port (also called an “access port” in Cisco terminology) carries traffic for exactly one VLAN. Frames leave the port with the VLAN tag stripped off. The device plugged in – a laptop, a NAS, a Raspberry Pi – has no idea VLANs exist. It just sends and receives normal Ethernet frames. This is what you want for end devices.
A tagged port (a “trunk port” in Cisco terminology) carries traffic for multiple VLANs simultaneously. Frames are tagged so the receiving device knows which VLAN each frame belongs to. This is what you want for uplinks: the port connecting your switch to your router, or the port connecting to a secondary switch, or the port going to a hypervisor host that has VMs on different VLANs.
One port can be untagged for one VLAN and tagged for others. On most prosumer switches (TP-Link TL-SG108E, Netgear GS308E, MikroTik CSS326, etc.), you configure this per-port, per-VLAN in a matrix view.
A Simple Mental Model
Think of it this way: untagged means the device speaks plain Ethernet, the switch handles the VLAN membership silently. Tagged means the device and the switch both understand VLAN IDs and pass them back and forth explicitly. End devices get untagged. Network infrastructure (routers, other switches, hypervisors) gets tagged.
Planning Your VLAN Layout
Before touching a single config screen, sketch out what you’re segmenting and why. Here’s a reasonable starting point for a home lab:
- VLAN 1 – Default / Management. Keep this for your switch management interface and your main trusted devices (desktop, laptop). Some admins move management off VLAN 1 entirely for extra isolation; for a home lab, leaving it here is fine as long as you set a strong switch password.
- VLAN 10 – Trusted home network. Your phones, TVs, daily-use devices.
- VLAN 20 – Lab / servers. Your NAS, Proxmox host, Docker servers, self-hosted services. This is where you want to restrict outbound internet access and tightly control what can initiate connections inbound from other VLANs.
- VLAN 30 – IoT / untrusted. Smart plugs, IP cameras, anything running firmware you don’t control. Ideally this VLAN gets internet access but cannot initiate connections to any other VLAN.
- VLAN 40 – Guest Wi-Fi. Internet-only, full isolation from everything else.
Five VLANs on one switch is not overcomplicated. It maps cleanly to a home environment and gives you a firewall boundary at each segment boundary.
Physical Wiring and Switch Port Assignment
Let’s make this concrete. Assume an 8-port managed switch. Here’s a sample port assignment:
Port 1 - Uplink to router (tagged: VLAN 1, 10, 20, 30, 40)
Port 2 - Desktop PC (untagged: VLAN 10)
Port 3 - NAS (untagged: VLAN 20)
Port 4 - Proxmox host (tagged: VLAN 20; also tagged VLAN 1 for mgmt)
Port 5 - IoT hub / smart switch (untagged: VLAN 30)
Port 6 - Wi-Fi access point (tagged: VLAN 10, 30, 40)
Port 7 - Spare
Port 8 - Spare
A few things to notice here. Port 1 is a trunk carrying all VLANs to the router – the router is where inter-VLAN routing and firewall policy lives. Port 4 going to the Proxmox host is tagged for VLAN 20, because Proxmox will create virtual bridges (vmbr) for each VLAN and tag them itself. Port 6 going to the access point is tagged for three VLANs, because a capable AP (UniFi, OpenWrt-flashed devices, etc.) can present separate SSIDs mapped to separate VLANs – guest SSID on VLAN 40, home SSID on VLAN 10, and so on.
The Router Side: Sub-Interfaces
Your router needs to understand 802.1Q to terminate those VLANs. On a router running OpenWrt, pfSense, or OPNsense, you create VLAN sub-interfaces on the LAN port. In pfSense/OPNsense, navigate to Interfaces → Assignments → VLANs and add each VLAN ID against your LAN NIC. Each sub-interface gets its own IP address, becoming the default gateway for that VLAN segment.
A typical addressing scheme:
VLAN 1 (Management) - 192.168.1.1/24
VLAN 10 (Trusted) - 192.168.10.1/24
VLAN 20 (Lab) - 192.168.20.1/24
VLAN 30 (IoT) - 192.168.30.1/24
VLAN 40 (Guest) - 192.168.40.1/24
Each segment runs its own DHCP scope from the router. Devices on VLAN 30 get addresses in the 192.168.30.0/24 range and use 192.168.30.1 as their gateway. Traffic destined for another VLAN hits the gateway, and the router’s firewall rules decide what to allow.
Configuring the Switch: A Real Example
The exact interface varies by vendor, but the underlying config is the same. Here’s how it looks on a TP-Link TL-SG108E (one of the most common budget managed switches in Canadian home labs, available for around $35-$45 CAD) using its web interface under VLAN → 802.1Q VLAN.
First, enable 802.1Q VLAN mode. Then create each VLAN and assign ports:
VLAN ID: 1
Port 1: Tagged
Port 2: Untagged
Port 3: Not Member
Port 4: Tagged
Port 5: Not Member
Port 6: Not Member
VLAN ID: 10
Port 1: Tagged
Port 2: Not Member (desktop doesn't need VLAN 10 if it's on VLAN 1)
Port 3: Not Member
Port 4: Not Member
Port 5: Not Member
Port 6: Tagged
VLAN ID: 20
Port 1: Tagged
Port 2: Not Member
Port 3: Untagged
Port 4: Tagged
Port 5: Not Member
Port 6: Not Member
VLAN ID: 30
Port 1: Tagged
Port 2: Not Member
Port 3: Not Member
Port 4: Not Member
Port 5: Untagged
Port 6: Tagged
VLAN ID: 40
Port 1: Tagged
Port 2: Not Member
Port 3: Not Member
Port 4: Not Member
Port 5: Not Member
Port 6: Tagged
After creating VLANs, set the PVID (Port VLAN ID) for each port. The PVID tells the switch which VLAN to assign to untagged frames arriving on that port. Port 3 (NAS) should have PVID 20. Port 5 (IoT hub) should have PVID 30. Port 1 and Port 4 and Port 6 – your tagged/trunk ports – typically keep PVID 1 or whatever management VLAN you want untagged frames to fall into if something sends them without a tag.
What we found surprising when first setting this up: forgetting to set the PVID is the most common reason a device on an “untagged” port can’t get a DHCP address. The VLAN membership matrix and the PVID are two separate settings on most switches, and both have to match.
Firewall Rules: Where the Segmentation Actually Happens
VLANs alone don’t block traffic – the router’s firewall does. Without rules, inter-VLAN routing will pass everything freely. You need explicit policy at the router.
A sensible default ruleset in OPNsense or pfSense:
- IoT VLAN (30): Allow outbound to WAN (internet). Block all traffic to RFC1918 addresses (your other VLANs and management). Allow DNS to the router’s IP on VLAN 30 only.
- Guest VLAN (40): Allow outbound to WAN. Block all RFC1918. DNS allowed to router only.
- Lab VLAN (20): Allow outbound to WAN (or restrict by destination if you want tight egress). Block inbound from IoT and Guest VLANs. Allow from Trusted VLAN 10 so you can reach your self-hosted services from your desktop.
- Trusted VLAN (10): Allow outbound to WAN. Allow to Lab VLAN 20 (so you can use your self-hosted services). Block from IoT and Guest VLANs initiating connections here.
In OPNsense, these rules live under Firewall → Rules → [interface name]. Rules are evaluated top-down on the source interface. The block-RFC1918 rule on VLAN 30 is a single rule matching destination alias RFC1918_NETWORKS (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12). OPNsense has this alias built in.
From our experience, the one rule people forget is allowing DHCP and DNS before the RFC1918 block. If your block rule comes before your “allow DNS to gateway” rule, devices won’t resolve anything. Rule order matters. Put specific allows above broad blocks.
Testing Your Segmentation
Don’t assume the config is correct – verify it. A few quick checks:
- From a device on VLAN 30 (IoT), try to ping a device on VLAN 20 (lab). It should fail.
- From a device on VLAN 30, try to ping 8.8.8.8. It should succeed (internet access is allowed).
- From a device on VLAN 10 (trusted), try to reach a service on VLAN 20. It should succeed if you created that allow rule.
- From a device on VLAN 40 (guest), try to ping anything on VLAN 10. It should fail.
Use nmap from a device on the IoT VLAN to scan the lab subnet: nmap -sn 192.168.20.0/24. If you see hosts responding, your firewall rules have a gap. If you get nothing back, you’re in good shape.
For Canadian home lab operators storing personal data – photos, documents, health records – on a local NAS, this kind of segmentation is worth doing not just as a technical exercise but as a reasonable data-handling practice. PIPEDA doesn’t apply to personal household use, but the principle of limiting unnecessary access to personal information is sound regardless of legal obligation.
Getting VLANs right the first time takes longer than expected, mostly because of PVID gotchas and rule ordering – but once it’s working, the mental model becomes intuitive quickly.
– Auburn AI editorial, Calgary AB
Related Auburn AI Products
Building a homelab or self-hosting content site? Auburn AI has practical kits:
- 500 Homelab and Self-Hosting Blog Titles ($27)
- Auburn AI Monitoring Stack ($37) – 6 production PowerShell scripts
- Podcast Automation Kit ($37)
- Browse all Auburn AI products
The practical limits I hit with single-switch VLAN setups
I’ve been running a single managed switch for my lab for about three years now, and I want to be direct: VLANs solve a real problem, but they don’t solve the problem you think they will. What I mean is—segmentation on one switch handles isolation beautifully until you actually need inter-VLAN routing or you add a second access point. Then you’re debugging why your phone can’t reach the printer, or why your Synology can’t back up to the NAS on a different segment.
The actual trade-off isn’t complexity versus simplicity. It’s upfront config work versus ongoing headaches. I spent maybe four hours setting up VLANs properly—trunking, tagging, VLAN interfaces on my router. But every time I add a new device, I have to remember the VLAN rules. And if your switch doesn’t handle IGMP snooping correctly (mine doesn’t, completely), multicast breaks across segments. That’s not academic—it affects mDNS, Plex discovery, some IoT stuff.
What I’d tell someone: do VLAN segmentation if you’re genuinely running untrusted services or you need to ring-fence your critical infrastructure from experiments. Don’t do it because a guide said so or because ‘security best practice.’ The overhead is real, and a flat network with good firewall rules on your router actually works fine for most home labs.
- IGMP snooping issues silently break device discovery across VLANs
- Adding a second switch or AP requires rethinking your trunk strategy
- Guest network isolation is often better handled at the AP level than at the switch