How should I split a homelab or home network into VLANs?

Split your network by trust level: put untrusted or noisy devices (smart-home gadgets, guests) on their own VLANs, keep servers on another, and reserve a small VLAN for managing the gear itself. A plan with five VLANs covers many homes and homelabs. Give each VLAN its own subnet, let it reach the internet, and allow traffic between VLANs only where you have a reason. This is general educational information, not a guarantee of security.

Why segment at all

A flat network lets every device talk to every other device. That is convenient until one cheap camera, a visitor’s infected laptop, or a forgotten test server becomes a way into everything else.

VLANs split one physical network into separate logical ones. Each usually gets its own subnet, and traffic between them must pass through a router or firewall, where you can write rules. The main reasons:

• IoT: Cameras, TVs, plugs and thermostats often get few updates and deserve limited trust. Keep them away from your computers and data.
• Guest: Visitors need internet, not access to your printer or file server.
• Servers: Things you host should be reachable on purpose, not by every device.
• Management: Switches, access points and the router’s admin pages should not be reachable from a phone on the IoT network.

Segmentation also keeps broadcast traffic contained and can make troubleshooting easier.

A simple five-VLAN plan

Pick a numbering scheme where the VLAN ID matches the third octet of the subnet. VLAN 20 becomes 192.168.20.0/24. You can then read an address and know its VLAN without looking anything up. This is a convention, not a requirement.

Where your gear allows it, avoid using the default VLAN 1 for real devices. Tag VLANs on trunk ports between switches, routers and access points, and assign access ports to a single VLAN. Devices powered over Ethernet (PoE), such as access points and cameras, work on any VLAN. PoE is about power, not traffic.

A /24 holds 254 usable host addresses, far more than most homes need, but it is simple and leaves room to grow.

Inter-VLAN firewall rules in principle

Defaults vary. Some firewalls block traffic between VLANs until you allow it, and others allow it until you block it. Whatever your equipment’s default, aim for “deny between VLANs, allow by exception.” Rules are generally evaluated top to bottom, and the first match wins, so write them in this order:

1. Allow established and related replies, so allowed conversations can come back.
2. Allow the services every VLAN needs from the router itself, such as DHCP and DNS.
3. Allow Trusted to reach Servers, IoT and Management as needed.
4. Allow IoT and Guest to reach the internet only. Block them from every private address range (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16).
5. Allow Servers to reach only what they need, such as the internet for updates.
6. Block everything else, and log the drops while you are learning.

Rules usually apply to new connections in the direction they start. So Trusted can open a connection to a camera, but the camera cannot open one back to Trusted.

Worked example

These are sample numbers only. You have a NAS on VLAN 20 at 192.168.20.10, a laptop on VLAN 10 at 192.168.10.50, and a smart TV on VLAN 30 at 192.168.30.25.

• The laptop opens the NAS file share. The Trusted-to-Servers rule allows it, so it works.
• The TV tries to reach the NAS directly. The rule blocking IoT from private ranges stops it, so it fails. If the TV needs to play media from the NAS, add one narrow rule above that block: allow 192.168.30.25 to 192.168.20.10 on only the port that service uses.
• A guest phone on VLAN 40 gets internet but cannot reach any of the devices above.

Common mistakes

• Making rules too broad (“allow IoT to Servers, any port”) and defeating the point.
• Putting an allow rule below the block rule that should be overridden, so it never matches.
• Forgetting that discovery protocols, which rely on broadcast or multicast, often do not cross VLANs. Casting from a phone to a TV may need an mDNS reflector (relay) or a specific rule.
• Leaving the management VLAN reachable from IoT or Guest.
• Setting a trunk port’s VLANs wrong, so a device lands on the wrong network. Check which VLANs each port carries tagged and which one it carries untagged.
• Letting guests join the same Wi-Fi network (SSID) as trusted devices instead of a separate SSID mapped to the guest VLAN.
• Locking yourself out while changing management settings. Keep a wired fallback and test one change at a time.
• Using VLAN IDs that do not match subnets, which makes future changes harder to read.

Check your own router or firewall’s documentation for the exact steps, since each platform words these settings differently.