VLANs at Home: A Practical Plan for Trusted, IoT, Guest and Lab Networks

A flat home network puts every device on one segment: your laptop, the work PC, the kids’ tablets, the smart TV, a dozen smart plugs and whatever you’re testing in the lab. Any one of them can talk to all of the others. When the cheapest device on the network gets compromised, nothing stands between it and your NAS.

VLANs (virtual LANs) split one physical network into several logical ones. Traffic between VLANs has to go through the router, which means through firewall rules you control. Traffic within a VLAN usually doesn’t (more on that below). This guide gives a starting plan for most homes, the rules to go with it, and the problems you’ll hit.

Why bother

• Containment: a hacked camera or smart plug can’t reach your PCs or backups.
• Privacy: smart TVs and IoT devices scan the local network. On a separate VLAN, their access to other networks can be restricted. Devices sharing that VLAN may still discover and talk to each other.
• A safe lab: test machines, old OS images and experiments stay off the family network.
• Clarity: when something misbehaves, you know which group it belongs to.

A four-VLAN starting plan

Two habits make this easy to live with:

• Match the VLAN ID to the third octet (VLAN 20 is 192.168.20.x), so you can read an address and know where it lives.
• Keep management interfaces on Trusted or a dedicated management network. That covers the router, switches, access points and hypervisors. Experimental VMs and containers go on Lab.

A physical Proxmox host doesn’t have to belong to only one network: its management interface can sit on Trusted while its guests use Lab.

Trusted holds both personal devices and the NAS in this simple plan. The VLAN boundaries won’t protect the NAS from a compromised laptop on the same segment. That’s an acceptable simplification for a starting point, as long as you know it’s there.

The firewall rules

Default-deny new connections between VLANs, then add the exceptions you need. Allow established/related return traffic, so replies to connections you did allow come back. How rules are placed and evaluated (first match, ordered lists, zones) depends on your firewall, so follow its documentation.

1. Default: deny new connections between all VLANs. Allow established/related.
2. Trusted → other VLANs: for a simple starting configuration, allow Trusted devices to start connections. This is a convenience trade-off, not least privilege. A tighter policy allows only designated admin devices, and only the services your household actually uses.
3. Lab, IoT, Guest → other VLANs: no exceptions by default. An experiment gone wrong can’t reach the family PCs or IoT devices.
4. Internet access: define it per VLAN, separately from the local rules. For example, consider blocking cameras’ internet access entirely and recording to a local NVR or NAS.
5. The router’s own services: these are separate from traffic through it. Devices on every VLAN may need DHCP, DNS or time (NTP) from the router without getting its admin interface. Allow those services explicitly and block the admin pages from IoT, Guest and Lab.

“Local” means all your internal networks and management addresses, not just the example 192.168.x.x subnets above.

Apply the same policy to IPv6. Use your firewall’s IPv6 rules, including the control traffic IPv6 needs to work. An IPv4-only policy isn’t a complete isolation policy on a dual-stack network.

Isolation inside a VLAN

Firewall rules between VLANs don’t control traffic within one. Devices on the same VLAN normally talk directly through the switch or access point, without passing through the router’s firewall.

• IoT: sharing a VLAN normally lets devices reach each other directly. Preventing that needs AP client isolation, switch port isolation, separate VLANs, or another device-isolation feature your hardware supports.
• Guest: blocking Guest from other VLANs doesn’t stop guests reaching each other. Turn on client isolation for the guest SSID.
• Check the scope: wireless client isolation may not isolate wired devices, or clients on a different access point.

Wiring it up

• Router/firewall: create the VLAN interfaces, each with its own subnet and DHCP range, then the rules above.
• Switch: uplinks to the router and access points are trunks (tagged). Configure each one to carry the VLANs needed downstream, not necessarily every VLAN, with matching tagging and native/untagged settings at both ends. Ports to single wired devices are access ports (untagged) in that device’s VLAN.
• Access points: one SSID per VLAN, for example Home (10), Home-IoT (20) and Home-Guest (30).

The mistakes everyone makes

• Casting and AirPlay stop working. Discovery often relies on mDNS, which normally stays within its local network segment. A selectively configured mDNS reflector (for example Avahi’s enable-reflector) can make supported services discoverable between Trusted and IoT. Discovery isn’t permission to connect, though: the casting connection itself still needs matching firewall rules, and some devices use other discovery methods or extra connections.
• Printers disappear. Discovery may fail across VLANs even when printing would work. Add the printer by IP address first, and allow the printing traffic it needs (for example IPP on TCP 631). Moving the printer to Trusted is a last resort, because it walks back the segmentation.
• Locking yourself out. Change one switch port at a time, and keep one port untagged in your management VLAN as a way back in.
• Forgetting DNS. If you run Pi-hole or AdGuard Home on Trusted, every VLAN needs a rule allowing DNS (port 53) to it, or point the other VLANs at the router’s DNS instead.
• Too many VLANs. These four networks are a starting point, not a requirement. Add another only when it represents a boundary you need and can maintain.

Don’t want to build it by hand?

Some platforms make segmentation easier to configure and maintain. Our article Zero Trust for Everyone: Firewalla Pro, AP7 and the Firewalla Switch looks at Firewalla’s approach to device grouping and isolation. The planning problem stays the same: decide which devices may communicate, identify the exceptions, and verify that the resulting policy behaves as intended.

Checklist

1. List your devices and assign each to Trusted, IoT, Guest or Lab. Put management interfaces (including hypervisors) on Trusted or a management network.
2. Create the VLANs, subnets and DHCP ranges on the router.
3. Add the rules: default deny between VLANs, established/related allowed, then the exceptions. Add the router-services rules and the matching IPv6 rules.
4. Turn on client or port isolation where devices on the same VLAN shouldn’t talk to each other (Guest at least).
5. Set up switch trunks with only the VLANs needed downstream, set access ports, and map SSIDs to VLANs.
6. Move devices over one group at a time, starting with Guest (it’s the easiest to test).
7. Fix discovery only between the networks that need it, filtering advertised services where your setup supports it. Then allow the actual connections.
8. Test it: from a device on each VLAN, confirm that what should be blocked is blocked (including the router’s admin page) and what should work does.

Sources

• VLAN configuration guides: OpenWrt switch/VLAN configuration, pfSense VLANs (Netgate)
• Why discovery breaks across VLANs: Multicast DNS, RFC 6762 (mDNS is link-local), and Avahi’s reflector option
• Printing by IP: IPP encoding and transport, RFC 8010 (IPP’s default port is 631)
• The VLAN IDs, subnets and rules here are an example plan, not a standard.

Checked 2026-10-17.

Written by an AI persona. Check it before you run it. See Terms.