How to Set Up VLANs in a Homelab

Every homelab starts as a flat network. Your router hands out addresses from a single range, your switch forwards everything to everyone, and any device can talk to any other device without asking for permission. That setup works beautifully when your lab is a laptop, a Raspberry Pi, and a printer. It starts feeling wrong the moment you add the usual suspects: a smart TV that phones home to three different cloud services, a handful of IoT bulbs and cameras whose vendors have a questionable track record with security, a NAS holding your entire digital life, and a server running services you expose to the internet. Suddenly the phrase “my network is my castle” sounds less like a boast and more like a liability.

VLANs are the standard answer to that problem, but most beginner guides treat them as an enterprise concept with enterprise complexity. They bury you in trunk ports, tagging modes, and spanning tree before you have even decided which devices belong together. The reality is that the core idea is simple, the hardware needed is cheap, and a sensible two or three VLAN layout can be up and running in an evening. The hard part is not the configuration, it is deciding what your segments should be and keeping track of them once they exist. This guide walks through both, starting from the assumption that you have never configured a VLAN before.

Why Segmentation Matters in a Homelab

The argument for VLANs in a homelab is rarely about performance, since home traffic volumes almost never saturate a gigabit switch. It is about isolation. When every device shares one broadcast domain, every device can also reach every other device directly, which means a compromised smart bulb has the same network access as your workstation. Segmentation changes that equation by splitting your physical switch into logically separate networks, so the bulb and your NAS stop sharing a direct path.

Isolation also makes experimentation safer. A container or VM running a deliberately vulnerable service for training is far less dangerous when it lives in its own segment with no route back to your main devices. And when things do break, smaller broadcast domains make troubleshooting dramatically easier. A misbehaving device that floods the network with traffic can only disrupt its own segment instead of taking down your whole lab.

Segmentation is also the most transferable skill in home networking. The zone based thinking you adopt for your lab, decide what belongs together, isolate what you do not trust, and route only what you need, is exactly how office, campus, and data center networks are designed. Learning it on a budget switch in your closet means you arrive at your first production networking task already fluent in the concepts, and it turns your homelab into a genuine practice environment rather than a place where services happen to run.

What a VLAN Actually Does

A VLAN, which stands for virtual local area network, lets one physical switch behave like several independent switches. Each VLAN is its own broadcast domain, so devices in VLAN 10 never see broadcast or multicast traffic from VLAN 20, and more importantly, they cannot reach VLAN 20 devices at all unless a router routes between the two. That router is the choke point where you enforce policy, which is why segmentation without firewall rules only gets you halfway.

The mechanics matter less than the mental model, but two terms will come up constantly, so they are worth understanding. An access port belongs to a single VLAN and typically carries untagged traffic, this is how you connect an ordinary device like a server or an access point to a segment. A trunk port carries multiple VLANs by adding a tag to each frame, which is how you run several segments over one cable between your switch and your router, or between two switches. If you remember that access ports connect devices and trunk ports connect network infrastructure, most configuration mistakes become obvious.

When your lab grows past a single switch, the same VLAN needs to span both. Connect them with a trunk carrying the VLANs you want shared, and devices in VLAN 20 on one switch reach devices in VLAN 20 on the other as if they were plugged into the same box. That is how segmentation survives a multi switch setup without a redesign, but it is also where beginners get tripped up, because a trunk with the wrong allowed VLAN list silently drops traffic for whatever segment nobody remembered to test.

A Simple VLAN Plan to Start With

You do not need a twelve VLAN enterprise scheme. A layout with four segments covers the vast majority of homelabs and gives you room to grow. A management VLAN for your router, switches, and other infrastructure, a trusted VLAN for your computers, NAS, and servers, an IoT VLAN for smart home devices that you want to reach but not fully trust, and a guest VLAN for visitors who should have internet access and nothing else.

Keep the numbering memorable and aligned with your subnets. A common pattern is VLAN 10 for management on 10.0.10.0/24, VLAN 20 for trusted devices on 10.0.20.0/24, VLAN 30 for IoT on 10.0.30.0/24, and VLAN 40 for guests on 10.0.40.0/24. Matching the third octet to the VLAN ID means you can read a device’s IP address and instantly know which segment it belongs to, a small convention that pays off during every future troubleshooting session.

Write the convention down before you configure anything, even if it is only a note pinned to your desk. The mapping between VLAN IDs, names, and subnets needs to survive the memory of the evening you set it up, because that memory fades fast. Use names that describe purpose and keep the ID and subnet pattern consistent so the layout stays readable as it grows.

Resist the urge to split things further on day one. Every VLAN you add multiplies the number of firewall rules, DHCP scopes, and documentation entries you must maintain. Start with the four segments above, run them for a few weeks, and only split further when a concrete need appears, such as a lab environment that should be isolated even from your trusted devices.

Each VLAN also needs its own DHCP scope and its own gateway address on the router. Create VLAN 30 for IoT but skip the DHCP pool for 10.0.30.0/24, and every device you plug in fails to get an address, with symptoms confusing enough that most people suspect the switch. Set up the scope and the gateway at the same moment you create the VLAN, and give critical devices like your NAS a static assignment or DHCP reservation so their addresses never silently change.

Once the core four are stable, reserve a few ID ranges for future segments so growth stays orderly. A lab network for VMs and containers, a media segment for streaming boxes, and a separate segment for anything you expose to the internet are all plausible additions, and agreeing on those ranges now means you never renumber anything later.

Hardware You Need

The good news is that proper segmentation no longer requires enterprise gear. The two requirements are a switch that understands 802.1Q VLANs and a router that routes between tagged VLANs. Managed and “smart” switches from TP-Link, Netgear, MikroTik, and UniFi all handle VLANs, and even budget eight port models do, so a dedicated layer 3 router is not required. If your router’s LAN ports support VLAN tagging, you can connect a single trunk cable from the router to your switch and let the router terminate every segment. This setup is called a router on a stick, and it is the most common way small labs run multiple VLANs with one physical connection.

Wireless adds a wrinkle. To put Wi-Fi devices on specific VLANs, your access points must support multiple SSIDs with per SSID VLAN mapping, which rules out most ISP provided gateways. If your access points cannot do this, the pragmatic option is to dedicate one SSID to trusted devices, one to guests, and accept that IoT gadgets on the main SSID will land on the trusted VLAN until you upgrade the wireless hardware. That is an acceptable trade off early on, just document it so you remember which SSIDs map to which segments.

If your ISP gateway cannot run in bridge mode, you will end up with it and your VLAN aware router both performing routing and DHCP, a setup known as double NAT. It works, but the second firewall layer quietly breaks port forwarding and turns remote access to your lab services into a debugging puzzle. For most homelabs the cleaner path is to bridge the ISP device and let one router own all of the segmentation.

Wiring also offers a choice. The common layout is modem to router to a trunk port on the switch, with everything else on an access port in the right VLAN. If your router supports tagging per LAN port, you can skip the trunk entirely and connect each segment on its own port. That layout is easier to reason about and worth using when your hardware allows it.

Set Up the Router and Switch

Configure one VLAN at a time, and keep a path to manage the router and switch while you work. A mistake in the management VLAN can lock you out of the switch, so confirm which port carries management traffic before changing its membership. Device menus differ, but the order of the network configuration is the same.

Start with the router. Create a VLAN interface for each ID, assign its gateway address, and configure a DHCP scope in the matching subnet. For example, VLAN 30 might use 10.0.30.1 as its gateway and hand out client addresses from 10.0.30.50 through 10.0.30.200. Reserve addresses outside the pool for infrastructure and devices that need stable addresses.

Next, create the same VLAN IDs on the switch. Configure the switch port connected to the router as a trunk and allow only the VLANs you intend to carry. Set the native VLAN deliberately if the equipment requires one. Connect ordinary wired devices to access ports assigned to one VLAN each. Avoid leaving active ports on the default VLAN by accident.

For Wi-Fi, map each wireless network to the intended VLAN in the access point settings. A trusted network and an IoT network can use separate wireless names while sharing the same physical access point, provided it supports VLAN mapping. Test with one device before moving the rest of your home network.

Build and test one segment end to end before adding the next. If a client does not get an address, check that the VLAN ID matches on the router, trunk, and access port, and that the DHCP scope is active. A switch VLAN by itself does not provide a gateway or addresses.

Write Firewall Rules Between VLANs

Creating the VLANs is only the first half. Router firewall rules control which traffic can pass between them, and default policies vary by device. Allow only the paths you need, such as access from a trusted administrator device to network equipment’s management interfaces, while blocking IoT devices from initiating connections to trusted and management networks. Guest traffic should be restricted to internet access only.

A useful mental model is to treat each VLAN boundary as a zone in your firewall and to write explicit allow rules for every legitimate crossing. That discipline turns your segmentation from a cosmetic exercise into a real security control, and it is also the behavior that translates directly to larger networks. When your homelab eventually grows into a small office setup or a multi site deployment, the same zone based thinking applies unchanged, only the number of zones grows.

It is also worth deciding where management lives. Keeping the management interfaces of your switch and router on their own segment means an attacker who lands on the IoT VLAN cannot reach the admin pages of your network gear, even if they discover the addresses. The same principle applies to your NAS: if it holds sensitive data, it belongs in the trusted segment with tightly scoped access rules, not on the guest or IoT segments just because it was convenient to plug in there.

Verifying That Your Segments Actually Isolate

Configuration is only half the job, and the other half is proving the boundaries work. Connect a test device to each access port or wireless network and confirm it receives an address from the correct subnet and DHCP scope. Then test an application path you intend to allow and one you intend to block. Do not rely on ping alone, since a firewall may block that traffic independently of the service you are checking.

The firewall decides whether cross VLAN traffic flows, so test the rules you wrote instead of assuming them. From a device on the trusted segment, verify you can reach a specific service you allowed on another segment. Then try to reach that service from the IoT or guest segment and confirm the connection is blocked. Check both directions when your rules are meant to treat them differently.

Keep a record of what you expected versus what you observed, and rerun the checks after every change to the layout. Segmentation drifts as devices move and ports get repurposed, and a small verification ritual keeps the boundaries real instead of theoretical.

Keep the Plan Current

The silent killer of home network segmentation is drift. You add a VLAN for a media server, reassign a port for a new appliance, expand the lab into a second switch, and six months later nobody, including you, can say which segments exist, which devices are tagged on them, and which firewall rules protect them. The switch configuration holds the truth, but reading it back out of a web UI is exactly the kind of chore that never gets done until something breaks.

Record each VLAN’s purpose, ID, subnet, and gateway, then list which ports, wireless networks, and devices use it. Keep a copy of the plan with your network notes and update it whenever you change a port or firewall rule. This makes it easier to find a mismatch when a device appears on the wrong segment or loses connectivity.

A naming convention makes this record easier to scan. A name such as “IoT VLAN 30” tells you more than “guest network” when several segments exist. Choose a consistent pattern when you create the first VLANs, then use it for new segments as your lab grows.

Start small, verify every boundary, and add segments only when they solve a real access or security problem. The next time you add a switch, wireless network, or device, update the VLAN plan before changing the configuration.