VLANs for a home lab
A flat network works until it does not. A home lab that starts as one subnet with a few machines tends to grow: IoT devices arrive, test virtual machines get created, guests need a network of their own, and services that have no business talking to each other end up on the same wire. VLANs let you separate that traffic without pulling a new cable for every group.
What a VLAN actually is
A VLAN is a label, not a physical separation. IEEE 802.1Q adds a small tag to an Ethernet frame that says which virtual LAN the frame belongs to, and switches use the tag to keep traffic in the right group. Two devices on different VLANs, plugged into the same switch, cannot exchange frames with each other at layer two. Something has to route between them at layer three.
Each VLAN is a separate broadcast domain, so a broadcast sent on one does not flood the others. That containment is what VLANs give you by themselves.
The tag sits in the frame header, so every device along the path has to understand it. End devices such as laptops and phones normally ignore tags and send untagged frames. The switch assigns those frames to the VLAN configured on the port the device is plugged into.
Access ports and trunk ports
An access port belongs to a single VLAN. Frames arrive untagged and the switch maps them to that VLAN, which is what end devices need.
A trunk port carries several VLANs at once, with each frame tagged to show which VLAN it belongs to. Trunks connect switches to each other, and connect a switch to the router or firewall that routes between VLANs. They also connect a switch to a hypervisor that runs machines on more than one VLAN. Mismatched trunk configuration can be difficult to spot, because the link comes up and part of the traffic still works.
A practical VLAN set for a home lab
Most home labs settle on a small set that mirrors real separation needs:
- Management, for the network gear itself.
- Servers, for the workloads you care about.
- Lab, for test machines that can be less restricted.
- IoT, for devices you cannot audit and would rather keep apart from everything else.
- Guest, for visitors.
Give each one its own subnet and its own policy. Names and numbers matter less than the separation itself: a compromised IoT device should not reach the switch management interface, and a test VM should not be able to affect production workloads.
Inter-VLAN routing
VLANs separate traffic at layer two. Passing traffic between them needs a layer-three device: a router on a stick, a firewall with sub-interfaces, or a layer-three switch.
The decision that matters is the policy applied between VLANs, and this is where tagging alone stops being enough. A VLAN keeps hosts off each other's segment and contains broadcasts, but a permissive any-to-any rule on the router or firewall lets traffic cross anyway. Default deny between VLANs is the better starting point. A server VLAN might need outbound internet access for updates. A lab VLAN might need the server VLAN for shared storage. An IoT VLAN probably needs the internet and little else. Write the rules down, test them, and record what each one allows and why.
A trunk accepts traffic for its allowed VLANs. An untrusted host connected to a trunk can attempt to join those VLANs directly, bypassing the intended inter-VLAN route. Limit allowed VLANs, use access ports for untrusted endpoints, and apply filtering between routed segments.
Hardware considerations
Not every switch supports VLANs, so a managed switch with 802.1Q support is the minimum requirement. One small managed switch is usually enough for a home lab. Ports that trunk to a hypervisor must be allowed to carry every VLAN the host needs.
If you virtualise, the virtual switch on the host has to understand VLANs as well. In Hyper-V, a VM network adapter can be given a VLAN ID, and the virtual switch tags the frames as they leave the host, which means the physical switch port it connects to must be a trunk carrying that VLAN (Microsoft, Set-VMNetworkAdapterVlan). The host's own traffic is configured separately with Set-VMNetworkAdapterVlan -ManagementOS, and the same cmdlet can put an adapter into trunk mode with an allowed VLAN list (Microsoft, Create and configure a virtual switch with Hyper-V).
An 802.1Q tag adds four bytes to the Ethernet frame. Check the maximum frame size and how each device defines MTU, especially when enabling jumbo frames. VLAN tagging does not inherently require a smaller IP payload if every device supports the resulting frame size (Cisco, IEEE 802.1Q frame format).
Troubleshooting the usual suspects
When VLANs misbehave, the cause is usually one of a handful of things. A trunk port missing a VLAN. An access port in the wrong VLAN. A router or firewall sub-interface with the wrong VLAN ID. A hypervisor virtual switch that is not passing the tag. Work through them in order and most problems resolve quickly.
One more catches people out: many trunks assign untagged frames to a native VLAN. Some platforms can tag the native VLAN or reject untagged traffic, so check the settings at both ends rather than assuming all trunks behave identically. A device configured for one VLAN will look like it sits on the wrong network if the port it is plugged into treats untagged traffic as a different VLAN.
Checklist
- List the groups of devices that should be separated and map each to a VLAN.
- Use access ports for end devices, and trunk ports on links that must carry more than one VLAN.
- Give each VLAN its own subnet, with no overlap.
- Default to deny between VLANs. Allow only what is needed, and document why.
- Confirm trunk ports carry every VLAN that needs to cross them.
- Match the hypervisor virtual switch to the physical switch trunk.
- Check that the layer-three policy between VLANs is what you intended.
- Test isolation: confirm a device on one VLAN cannot reach another without an explicit allow rule.