We’re excited to launch our first HomelabAddiction printable 🎉 Become an early supporter and get 20% off withEARLY20GET NOW
Plan VLANs in a homelab by separating management, trusted clients, servers, and IoT or guest devices, then verifying trunks, access ports, DHCP scopes, and firewall policy one boundary at a time.
FTC Disclosure: This article contains affiliate links. If you purchase through these links, we may earn a commission at no additional cost to you.
VLANs matter because they let a homelab stop treating every device as equally trusted. Management devices, servers, personal clients, and IoT or guest gear can each live on separate Layer 2 segments with distinct firewall policy between them.
The practical rollout is smaller than most networking guides make it sound: define a few clear trust zones, assign ports and DHCP scopes carefully, and verify one boundary at a time before adding more complexity.
This page helps a homelab operator start with a four-segment design they can still troubleshoot later instead of jumping straight into an overbuilt network map.
A flat network feels fine right up until it does not.
On a flat network, your phone, work laptop, NAS, Proxmox host, random camera, cheap smart plug, smart TV, test containers, and guest devices all live in one trust zone. That is convenient. It is also lazy. One bad device or one bad rule can expose far more than you intended.
VLAN segmentation matters because it gives the firewall or router real boundaries to enforce between device groups that should not all trust each other equally.
The managed switch handles tagging and port membership. The firewall or router handles the gateway, DHCP relay or scope logic, and the access policy between those segments.
If you want the broader planning view first, read our Homelab Network Architecture Guide: VLANs and Firewalls. If you already know you want segmentation, keep going.
A VLAN, or Virtual Local Area Network, is a way to split one physical network into multiple isolated Layer 2 networks.
That sentence is technically correct and emotionally useless, so here is the practical version.
Normally, if devices plug into the same simple switch, they are on the same local network. They can discover each other, broadcast to each other, and generally behave like roommates who have no concept of privacy.
A VLAN lets that same switch pretend to be several different switches.
So instead of this:
all sharing one big local space, you get this:
Now those groups do not talk freely unless your router or firewall allows it.
This is where most frustration starts, so let us untangle it.
A VLAN is the local broadcast domain on the switch side.
A subnet is the IP network you assign to that VLAN, like 192.168.20.0/24.
In practice, homelabs usually map one VLAN to one subnet.
Example:
192.168.10.0/24192.168.20.0/24192.168.30.0/24That one-to-one mapping keeps your brain from filing a complaint against you later.
A VLAN tag is a label on an Ethernet frame that says, "This belongs to VLAN 20."
Think of tagged traffic like envelopes with colored stickers. The switch reads the sticker and knows which VLAN the traffic belongs to.
article_topic // VLANs for Homelabs Explained
Don't leave without the setup notes.
Get practical homelab guides, failure logs, and beginner-friendly build notes in your inbox.
Enter your email address to receive the Homelab Addiction newsletter.
An access port carries one VLAN for a normal end device like a desktop, printer, or camera.
A trunk port carries multiple VLANs between network devices, like:
If you plug a normal PC into a trunk port without meaning to, you are probably about to have a confusing afternoon.
Many switches use a PVID or default VLAN ID for untagged traffic arriving on a port.
That matters because if a port is supposed to place an IoT device into VLAN 30, the port's untagged or default VLAN has to match that design.
This is one of the most common causes of "why did this camera get the wrong IP range?"
You do not need enterprise gear. You do need the right features.
An unmanaged switch cannot do this job.
You need a switch that supports 802.1Q VLANs. That could be:
Your router or firewall handles:
That could be:
If you are still picking a platform, our pfSense vs OPNsense vs OpenWrt comparison will help you choose the least annoying path.
If you want separate SSIDs for trusted, IoT, or guest Wi-Fi, your AP has to support mapping SSIDs to VLANs.
You do not need to buy all of this at once, but these are sensible categories for a VLAN-ready homelab:
You do not need ten VLANs on day one. That is how people end up writing sad notes to themselves about mDNS at midnight.
Start with four.
| VLAN ID | Name | Subnet | What goes here |
|---|---|---|---|
| 10 | Management | 192.168.10.0/24 | switch UI, AP management, hypervisor management, firewall admin |
| 20 | Trusted | 192.168.20.0/24 | laptops, desktops, phones you trust |
| 30 | Servers | 192.168.30.0/24 | NAS, Proxmox services, containers, internal apps |
| 40 | IoT / Guest | 192.168.40.0/24 | smart plugs, TVs, cameras, guest Wi-Fi |
Why this matters:
If you later outgrow this, split VLAN 40 into separate IoT and Guest networks.
Do this in order. The order matters more than people admit.
Write them down before you click anything.
A bad VLAN design is like labeling moving boxes after you already threw everything into the truck.
Use a simple table like the one above. Keep IDs memorable. Keep subnets aligned with VLAN IDs if possible.
That means:
192.168.10.0/24192.168.20.0/24192.168.30.0/24192.168.40.0/24That pattern is not required, but it saves you from avoidable confusion.
This is the actual gateway side.
On pfSense or OPNsense, you will typically:
igb0 or em0192.168.10.1/24192.168.20.1/24192.168.30.1/24192.168.40.1/24Official references if you want vendor documentation while you build:
Why this matters before the next step:
If DHCP is missing, devices may connect physically but never get useful addresses. That often makes people blame the switch when the real problem is the gateway.
For each VLAN, define a DHCP range such as:
192.168.10.100-199192.168.20.100-199192.168.30.100-199192.168.40.100-199If you need a refresher on DHCP behavior, read DHCP Explained for Homelabs. It is much easier to troubleshoot VLANs when you can immediately recognize whether a device landed in the wrong scope.
The cable between your firewall and switch usually needs to carry multiple VLANs.
That means the uplink should be a trunk port.
A vendor-neutral idea of that config looks like this:
port 1 = trunk
allowed VLANs: 10,20,30,40
native/untagged VLAN: management or none, depending on platform design
If you are working on a Cisco-like CLI, it often looks like this:
interface GigabitEthernet0/1
switchport mode trunk
switchport trunk allowed vlan 10,20,30,40
Do not overcomplicate this. The goal is simple: the router-to-switch link must carry every VLAN you intend to use.
Now give normal endpoint ports one VLAN each.
Examples:
Cisco-like example:
interface GigabitEthernet0/2
switchport mode access
switchport access vlan 30
If a device should live in exactly one VLAN and is not itself VLAN-aware, use an access port.
If you use one Wi-Fi AP for several SSIDs, the AP uplink usually needs to be a trunk too.
Example:
This is another place people accidentally flatten their network without noticing.
This is the part that actually gives your design teeth.
VLANs separate local broadcast domains. Firewall rules decide what crosses between them.
A sensible starter policy is:
For a deeper walkthrough, read Homelab Firewall Rules: How to Isolate VLANs Without Breaking DNS, Backups, or Your Sanity.
From the lab
This is the part many guides skip, and it is why so many people end up guessing.
If you have a Linux host connected to a trunk and want to verify tagged traffic manually:
sudo ip link add link eno1 name eno1.30 type vlan id 30
sudo ip addr add 192.168.30.10/24 dev eno1.30
sudo ip link set eno1.30 up
ip addr show eno1.30
ip route
Why this matters:
This gives you a direct way to test whether VLAN 30 is really reachable from that trunk.
bridge vlan show
That command is useful on Linux-based hosts, hypervisors, or lab routers because it shows which VLANs are present on which interfaces.
ping -c 3 192.168.30.1
If the device is on VLAN 30, it should be able to reach the VLAN 30 gateway.
traceroute 192.168.20.1
If inter-VLAN routing is allowed, this helps show whether the firewall is actually routing the path you expect.
sudo tcpdump -eni eno1 vlan 30
If you see VLAN-tagged frames, the trunk is doing its job. If you do not, your switch port or upstream interface is probably misconfigured.
This creates isolated islands with no gateway.
Symptoms:
Normal endpoints should usually be on access ports, not trunks.
Symptoms:
This one hurts because it looks random.
Your DNS resolver, mDNS reflector, Chromecast discovery, AirPlay, and Home Assistant discovery can all behave differently across VLANs.
That does not mean VLANs are broken. It means discovery traffic is no longer floating freely across the whole house, which is the point.
If DNS has been one of your recurring pain points, our older Homelab DNS guide is worth revisiting after segmentation.
You do not need a dedicated VLAN for every emotional state.
Beginners often create:
Then they spend days writing exceptions for traffic they barely understand.
Start with four. Add more only when a clear need appears.
Log deny rules when you first roll this out.
That gives you a map of what devices are trying to do. A blocked log is not just noise. It is a clue about dependencies you forgot to account for.
If you want the short version, do this:
That gets you most of the benefit without turning your homelab into a puzzle box.
These are the most common failure points when a first VLAN rollout stops passing traffic:
If you avoid those, you are already ahead of a surprising number of "advanced" setups.
Yes. An unmanaged switch cannot properly handle 802.1Q VLAN tagging, which is what most real homelab VLAN setups depend on.
Not directly at Layer 2. They need routing through a router or firewall, and that traffic can then be allowed or blocked by firewall rules.
Usually yes. That is one of the highest-value VLAN moves you can make because IoT devices are often the least trustworthy things on the network.
A trunk carries multiple VLANs between network devices. An access port carries one VLAN for a normal endpoint like a laptop, NAS, or camera.
It is better not to rely on VLAN 1 for important segmentation. Many devices treat it as the default VLAN, and avoiding it for key networks reduces confusion.
Once your VLANs work, the next topics that matter most are:
If you remember nothing else from this guide, remember this: VLANs are not about making your network look impressive. They are about making your network easier to trust, easier to reason about, and easier to recover when something weird happens.
That is why they matter.
article_topic // VLANs for Homelabs Explained
Start building a smarter homelab.
Join readers learning Proxmox, networking, storage, backups, and self-hosting without breaking everything.
Enter your email address to receive the Homelab Addiction newsletter.
Beginner-friendly
No gatekeeping. Just clear, actionable guides.
1 useful email / week
Practical tips, real-world setups, and lessons learned.
Zero hype, practical only
What works, what breaks, and how to fix it.
Reply to any email with what you're building.
I read and reply to as many as I can.
— The Homelab Addiction Operator
support // the lab
Found this guide useful?
If it saved you time or a rebuild, you can support more practical homelab guides.