VLANs at home: separating IoT, guests and servers

The reason to split a home network is not paranoia. It is the same reason a house has more than one circuit breaker: when something goes wrong, you want it to go wrong in one room. A smart plug running firmware nobody has updated in years has no business sharing a network with the laptop that holds your tax returns, and the friend who joins your Wi-Fi for an evening does not need to see your NAS.

What follows is a plan, the kind I would pin inside the network cabinet door. It is written for a router that can do VLANs and firewall rules (OPNsense, pfSense and OpenWrt are the examples here), one managed switch and a couple of access points that can map SSIDs to VLANs. Adapt the numbers; keep the shape.

The plan on one page

A few choices in there are deliberate.

The third octet matches the VLAN ID. At 23:00, with a laptop on a stepladder, you will be glad that 10.0.30.17 is obviously on VLAN 30.

Every network is a /24. That is 254 usable addresses, which is more than any house needs, and it keeps the arithmetic out of the way. If you would rather carve a smaller block into tighter networks, run the ranges through the subnet calculator before you type them into the router, not after.

I stay away from 192.168.0.0/24 and 192.168.1.0/24. Plenty of hotels, cafes and relatives' houses use them, and the day you connect home over a VPN from one of those networks, the overlapping range makes your own devices unreachable.

Nothing lives on VLAN 1. On many switches it is the default for every port and the place a factory reset puts you back. A switch that resets itself should land somewhere that reaches nothing, not on the network with your NAS.

Tagged, untagged and the port map

802.1Q works by inserting a 4-byte tag into the Ethernet frame, right after the source MAC address. The tag carries a 12-bit VLAN ID (1 to 4094 usable; 0 and 4095 are reserved) and a 3-bit priority field. A switch port can treat those tags in two ways.

An access port belongs to one VLAN and sends frames untagged. The device on the end has no idea VLANs exist, which is what you want for a TV or a NAS.

A trunk port carries several VLANs, each frame tagged with its VLAN ID, and at most one untagged ("native") VLAN. Routers, access points and hypervisors sit on trunks, because they need to speak to more than one network over one cable.

Cheaper "smart managed" switches rarely say access or trunk. They show a grid where each port is a tagged member, an untagged member or not a member of each VLAN, plus a PVID: the VLAN that untagged frames arriving on that port are put into. The classic mistake is making a port an untagged member of VLAN 30 while leaving its PVID at 1. Traffic leaves the port fine and nothing coming in ever arrives where you expect. Set membership and PVID together, every time.

If the switch you have cannot do VLANs at all, any of these three can. Only the Omada model also answers SNMP, which matters if you want the monitoring Pi on port 11 to graph every port. I chose them from spec sheets and published reviews, not from a test bench of my own.

# Affiliate links: we may earn a commission. As an Amazon Associate I earn from qualifying purchases.

Here is the port map for a 16-port switch:

The access points take management untagged because most of them want their own admin address on the native VLAN. That is fine, as long as the native VLAN is management and nothing else.

Port 16 is my favorite line in the table. It is an untagged management port with a bright patch lead and a label, and it is how you get back in when a VLAN change locks you out. Label both ends of every cable while you are at it. An electrician who leaves an unlabeled panel gets a phone call; a home-lab builder gets a lost evening.

On the wireless side, give each SSID its VLAN: one for the household (20), one for things (30), one for guests (40). Do not make SSIDs for management or servers. Every extra SSID costs airtime in beacons, and the IoT one will probably have to stay on 2.4 GHz with WPA2, because plenty of cheap devices manage nothing newer.

Firewall rules between VLANs

The router is now the only path between networks, so it decides who talks to whom. The rule of thumb is the one the plan table already shows: deny between VLANs by default, allow by exception, and let the firewall's state tracking carry the replies back. When a laptop on Trusted opens a connection to a smart plug on IoT, the answer comes home without any IoT rule; the plug just cannot start a conversation of its own.

On pfSense and OPNsense the rules sit on the interface where the traffic enters, and the first match wins. A new VLAN interface with no rules passes nothing, which is the right starting point. In order, from the top, the IoT interface gets:

1. Allow DNS (TCP and UDP 53) to the router's IoT address.
2. Block anything to the router's own addresses. Both have a built-in destination for "this firewall"; use it, or the IoT network can reach the router's admin page through its own gateway address.
3. Block anything to private address space (an alias for the RFC 1918 ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16).
4. Allow anything else, which by now can only mean the internet.

Guest gets the same four rules. Servers gets an extra allow to the IoT network above the private-range block, so Home Assistant can reach the devices it controls. Trusted gets an allow to everything except management, with one exception for the admin laptop's reserved address. Management allows everything outbound, because that is where the monitoring Pi polls from.

OpenWrt thinks in zones rather than interfaces. Each VLAN network goes into a zone, forwardings say which zone may start connections into which, and rules without a destination apply to traffic aimed at the router itself. The IoT part of /etc/config/firewall looks like this (here lan is the trusted network):

config zone
	option name 'iot'
	list network 'iot'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'

config forwarding
	option src 'iot'
	option dest 'wan'

config forwarding
	option src 'lan'
	option dest 'iot'

config rule
	option name 'IoT DHCP'
	option src 'iot'
	option proto 'udp'
	option dest_port '67-68'
	option target 'ACCEPT'

config rule
	option name 'IoT DNS'
	option src 'iot'
	option dest_port '53'
	option target 'ACCEPT'

Input is rejected, so IoT devices cannot reach the router's admin pages, and the two rules let them get an address and resolve names. The lan to iot forwarding lets Trusted reach the plugs; there is no forwarding in the other direction, so they cannot reach back.

Keeping casting and discovery working

This is where most home VLAN projects get rolled back. The phone on Trusted can no longer find the TV on IoT, and the household votes.

The cause is discovery, not the firewall. Casting, AirPlay and most printers announce themselves with mDNS: multicast to 224.0.0.251 on UDP 5353, which by design never leaves its own subnet. The fix has two halves. First, repeat mDNS between the two VLANs that need it, and only those two: OPNsense has an mDNS repeater plugin, pfSense has an Avahi package, and on a Linux or OpenWrt router Avahi does it with a short config:

[server]
allow-interfaces=br-lan.20,br-lan.30

[reflector]
enable-reflector=yes

Second, the firewall has to allow the connection that follows discovery. With the Trusted to IoT rule already in place, most casting simply starts working. Some devices also open a connection back to the phone or to a media server; if a cast starts and then drops, look in the firewall log for blocks from the TV's address and add one narrow rule for that device and that port, not a blanket IoT to Trusted allow.

Some TVs and media players use SSDP (UDP 1900) for discovery instead, which is a different multicast and needs its own relay. Never reflect anything into Guest.

The cost of routing between VLANs

One honest trade-off. With a single trunk to the router, every byte between two VLANs goes up that cable to the router and back down again. Copying a large folder from a laptop on Trusted to the NAS on Servers now runs at whatever the router can route and filter, sharing the trunk with your internet traffic. A modest router CPU can fall well short of line rate once firewall rules are involved.

If big file copies matter, you have choices: a faster router, a second link, a NAS with a leg in Trusted, or a layer 3 switch that routes between VLANs in hardware (and then uses access lists instead of a proper firewall). For most houses, measuring it first is the right move.

Watching it once it runs

VLANs are worth monitoring because each one has a job, and traffic that does not match the job stands out.

Each VLAN appears on the router as its own interface, so SNMP hands you separate in and out counters for each network with no extra work. Graph them. If your monitor is the Pi from the weekend Raspberry Pi build, it sits on Management and polls the router from there. Use the 64-bit counters; the interface counters article explains why the 32-bit ones wrap too quickly on a busy trunk.

What I look for:

• IoT upload that does not fit the devices. A camera you thought was local-only pushing a steady stream out, or a smart plug moving megabytes, deserves a look.
• Guest traffic when nobody is visiting.
• A Trusted to Servers spike at backup time, and none when the backup should have run.
• Firewall blocks per VLAN. Send the router's firewall log to a syslog server (the syslog article covers a small setup) and count blocks per source network. A jump from IoT usually means a device scanning for something, harmless or otherwise.
• DHCP leases per VLAN. A new name on Trusted means someone shared the household Wi-Fi password.

The order of work

Do it in this order and you will not lock yourself out:

1. Create the VLAN interfaces, DHCP scopes and firewall rules on the router while the old flat network still works.
2. Set the switch port to the router as a trunk, and make the rescue port before anything else moves.
3. Move the access points and add the new SSIDs alongside the old one.
4. Move devices one VLAN at a time: servers, then trusted, then guest, and IoT last, because that is where things need re-pairing.
5. Retire the old SSID once its client list has been empty for a week.

If you remember one thing, make it the rescue port: one labeled, untagged management port that you never repurpose.