VLANs for a homelab: what to segment, and what breaks

Segmenting a home network is one of those projects that sounds like a weekend and turns into a fortnight, mostly because the hard part is not creating the VLANs. It is discovering, one household complaint at a time, everything that quietly depended on all your devices sharing a single flat network.

Segmentation is still worth doing. A smart plug running firmware from 2021 should not be able to reach your NAS. But go in knowing what breaks, because that list is longer than the setup guide suggests.

What segmentation actually buys you

Be precise about the threat, because it changes what you build.

The realistic risk in a home is not a targeted attacker. It is a device you own, running software you cannot update, that gets compromised and then has unrestricted access to everything else. Cameras, plugs, bulbs, televisions and appliances routinely ship with old components and stop receiving updates a year or two after release. On a flat network, each one of them is a full peer of your laptop and your NAS.

Segmentation does not stop a device being compromised. It limits what a compromised one can reach, and for a home network that is the whole point. A camera that can only talk to the internet and nothing local is a much smaller problem than one that can browse your file shares.

The secondary benefit is one homelabbers feel immediately: a lab segment where you can run a second DHCP server, break routing, or test a firewall rule without taking the household offline mid film.

How many segments, realistically

The common mistake is too many. Every additional segment multiplies the firewall rules you maintain and the discovery problems you work around. Four is plenty for most homes.

Segment	What goes on it	Should reach
Trusted	Laptops, phones, tablets, the NAS	Everything, including out to the other segments
IoT	Plugs, bulbs, cameras, TVs, appliances	The internet only, plus a hub if one is needed
Guest	Visitors	The internet only, with client isolation on
Lab	Anything you are experimenting with	The internet, and whatever you deliberately allow

A separate management segment for switches, access points and hypervisor interfaces is a sensible fifth if you have the equipment for it. Add it carefully: a management VLAN is the classic way to lock yourself out of the device you are configuring, and recovering usually means a physical console cable and an awkward hour.

Give each segment a subnet you will recognise at a glance. Putting the VLAN number into the third octet, so VLAN 20 is 192.168.20.0/24, costs nothing and makes every future diagnostic easier to read. A subnet calculator confirms the ranges and gives you the broadcast address for each, which you will want later.

What breaks, and what to do about it

This is the section the setup guides skim, and it is where the fortnight goes.

Device discovery stops, completely

AirPlay, Chromecast, printers, HomeKit, Spotify Connect and most smart speakers find each other with multicast, and multicast does not cross a router. Put your phone on Trusted and your speaker on IoT and they become invisible to each other even though a direct connection would work fine.

The fix is an mDNS reflector or repeater, which most prosumer firewalls and some consumer mesh systems offer. Configure it to forward announcements between the specific pair of segments that need it, not between everything, because reflecting all traffic everywhere undoes the segmentation you just built. There is more detail on how this fails in the post on AirPlay and Chromecast not showing up.

Wake-on-LAN stops

A magic packet is a broadcast, and broadcasts stay inside their segment. If you wake a machine from your phone, the phone now has to be on the same segment, or you need a device on the target's segment to send the packet for you. See Wake-on-LAN not working for why the broadcast address matters so much here.

Some hubs demand the same layer 2

Several popular lighting and speaker systems discover their own hardware with link local protocols and simply do not work across segments, regardless of firewall rules. Check before you move them. The pragmatic answer is often to keep one vendor's ecosystem together on IoT and put the controlling app's access through a specific allow rule.

Casting from a phone becomes a decision

You want your phone on Trusted and your television on IoT, and you want casting to work. That needs an mDNS reflector between exactly those two, plus a rule allowing Trusted to initiate connections to the television. It works, it just is not automatic.

Printers

Printers are among the least trustworthy devices in most homes and among the most annoying to segment, because printing depends on discovery. Same answer: reflector plus a targeted allow rule, and a static address so the rule stays valid.

Firewall rules that make sense

The principle that makes this manageable: rules are about who initiates, and a stateful firewall handles the replies.

Allowing Trusted to reach IoT does not allow IoT to reach Trusted. When your phone opens a connection to a camera, the return traffic is part of that established connection and comes back automatically. The camera still cannot start a conversation with your laptop. That asymmetry is most of the security benefit and it costs one rule.

A sane starting set:

• Trusted to anywhere: allow.
• IoT to the internet: allow. IoT to any local segment: block.
• Guest to the internet: allow. Guest to anything local: block, with client isolation on as well.
• Lab to the internet: allow. Lab to local: block by default, open specific things as needed.
• Anything to the management segment: block, except from one specific trusted address.

Two exceptions you will probably need. DNS, if your internal resolver lives on Trusted, because every segment needs to reach it on port 53. And NTP, for the same reason, if you run a local time source. Allow those specific ports to that specific host rather than opening the segments to each other.

Log the block rules for a week. What you learn from the logs is the actual list of things that need exceptions, which is far more reliable than predicting it.

Doing it without a household revolt

Segment in the order of least disruption, and finish each step before starting the next.

1. Guest first

   It is isolated by design, nothing you own depends on it, and it is the safest place to learn how your equipment handles VLANs.

2. Lab second

   Move your experiments off the main network. Immediate benefit, no household impact, and you now have somewhere safe to test the next steps.

3. IoT third, in batches

   Move the devices nobody interacts with directly first: plugs, sensors, bulbs. Then cameras. Leave the television and the speakers until last, because those are the ones people notice.

4. Sort out discovery before the visible devices move

   Get the mDNS reflector working with one test device and confirm casting still works before you move the family television.

5. Management last, and carefully

   Have console access available before you change the interface you are managing the device through.

One practical note on Wi-Fi: each segment usually needs its own SSID mapped to its VLAN. Devices do not choose a VLAN, they choose a network name, so the SSID is the boundary as far as anyone in the house is concerned. Name them so it is obvious which is which.

Verifying the rules actually work

Firewall configuration and firewall behaviour are different things, and only one of them matters. Test from the segment, not from the admin interface.

Join a phone to each VLAN in turn and run the same three checks:

A LAN scan of the local subnet shows which devices are on that segment, and confirms things landed where you intended. Devices that show up on the wrong segment are usually a switch port left on the wrong VLAN or a device that ignored the new SSID.

A TCP connect toward a host on another segment is the real test of a block rule. From IoT, try to reach the NAS on port 445 or 5000. It should fail. If it succeeds, your rule is not doing what the configuration screen suggests, and better to learn that now.

A Bonjour browse from each segment shows exactly what the reflector is forwarding. This is the one that catches over permissive reflector configuration: if a phone on Guest can see every service in the house, the reflector is forwarding more than it should.

Save those three as one automation per segment. Re-running them after a firmware update is worth the thirty seconds, because firewall and reflector behaviour does change across versions, and Run History gives you the previous result to compare against.

The short version

Four segments is enough for most homes, and more than four is a maintenance decision rather than a security one. Expect discovery, Wake-on-LAN and some vendor ecosystems to break, and plan the mDNS reflector before you move anything anyone watches television on. Write rules in terms of who initiates and let the stateful firewall handle replies. Then test from a device actually sitting on each segment, because a rule that reads correctly and behaves differently is the normal outcome, not the unusual one.