VLAN Segmentation at Home: Keeping Your Smart Toaster Away from Your NAS
Why one flat network is the riskiest thing in your house
Contents
Here is an uncomfortable fact about most home networks: every device on them can talk to every other device. Your laptop, your phone, your NAS full of irreplaceable photos, and that £25 smart plug running firmware last updated when it left the factory in Shenzhen — they’re all sitting on the same flat subnet, able to reach each other freely. The smart plug has a hardcoded telnet password and a cloud connection you can’t see into. The NAS has everything you care about. On a flat network, the first is one hop from the second, and nothing in between is checking whether that hop should be allowed.
I spent years running exactly that setup. It worked fine, right up until I started thinking about how many of the black plastic boxes in my house were essentially unpatched Linux machines with a network stack and a mystery cloud backend. The count was alarming. That was the afternoon I decided to segment.
VLANs fix this. A VLAN — virtual LAN — lets a single physical switch and router behave as if they were several separate networks that don’t trust each other. You put the toaster, the doorbell and the dodgy IoT gadgets in one segment, your trusted computers in another, guests in a third, and then you write rules about who is allowed to talk to whom. It is the single highest-leverage thing you can do for home network security, and it is more approachable than the acronyms suggest.
What a VLAN actually is
Ethernet frames can carry a tag — an 802.1Q tag — that stamps them with a VLAN ID, a number from 1 to 4094. A VLAN-aware switch reads that tag and keeps tagged traffic logically separate even though it is all flowing down the same copper. A “trunk” port carries multiple tagged VLANs between switches and your router; an “access” port belongs to exactly one VLAN and hands untagged frames to a single device. The device plugged into an access port has no idea VLANs exist — it just sees a normal network. All the tagging happens upstream, on the switch.
The practical upshot: VLAN 10 is your trusted LAN, VLAN 20 is IoT, VLAN 30 is guests. Devices on 20 get an IP from the 20 subnet, devices on 10 from the 10 subnet, and by default they cannot see each other unless your router routes between them and a firewall rule permits it. This is the mental model that trips people up at first: a VLAN is not itself a firewall. It is a way of drawing a border. The firewall is what decides whether traffic crosses that border, and that decision is the whole point.
Why segment at all — the threat you’re actually defending against
Segmentation is not paranoia theatre. The threat model is concrete. Cheap IoT hardware ships with security that ranges from “afterthought” to “actively hostile” — default credentials, open debug ports, firmware that never receives an update, and a permanent tunnel to a vendor’s cloud. When one of those devices is compromised — and given the state of the market, “when” is the right word — the attacker’s first move is to look around the local network for something worth having. On a flat network, they find your NAS, your router’s admin page, your printer, your work laptop. All reachable, all fair game.
Put the IoT gear on its own segment with a default-deny policy outbound to the rest of the house, and that same compromised device wakes up in an empty room. It can still phone its cloud — you rarely want to break the actual product — but it cannot pivot. It cannot scan for your NAS because the packets never leave the segment. You have converted a potential breach into a contained nuisance.
Drawing the segments
A sensible starting layout for a house:
| |
Each VLAN gets its own SSID if it is wireless, or its own access ports if it is wired. Keep the numbering boring and the subnets non-overlapping — future you, debugging a routing problem at midnight, will be grateful you didn’t get clever. The interesting part is not the addressing. It is what you forbid between the segments.
Resist the urge to invent fifteen VLANs on day one. The overhead of managing a heavily-segmented network is real, and it is easy to build something so complicated you stop maintaining it — the same trap I wrote about in the home-lab upgrade trap. Four segments cover almost everyone. Start there.
The firewall rules that earn their keep
Segmentation without firewall rules is just tidy addressing — the security comes from inter-VLAN policy. The rules I’d start with, expressed in plain pf/nftables terms:
| |
The principle is default-deny between segments, then poke holes only where you actually need them. Your phone needs to reach the NAS, so allow VLAN 10 to VLAN 40. The IoT segment never needs to reach anything internal, so it doesn’t get to. A compromised camera can now phone its cloud, but it cannot scan your NAS, because the router simply drops the packets.
Pay attention to the direction of trust. Notice that trusted devices can open connections to servers, but servers cannot open connections back to trusted devices. This matters: if the NAS itself is ever compromised — through a dodgy container image, a vulnerable web app you self-host — you do not want it able to reach your laptops. Modern stateful firewalls track established connections, so return traffic for a session your phone started still flows; what is blocked is the server initiating something new. That asymmetry is the difference between a good ruleset and a permissive one.
A worked example: letting Home Assistant reach the toaster
The classic real-world need: your smart-home controller lives on the trusted or server segment, but the devices it controls live on IoT. That is a deliberate, narrow hole. If you run MQTT as the message bus — and if you are doing home automation seriously, you probably should, for reasons I got into in MQTT essentials — then the rule is precise: allow the controller’s IP to reach the IoT devices on exactly the ports they speak, and nothing else.
| |
One host, specific ports, one direction. That is the shape every cross-segment exception should take. If you find yourself writing “allow VLAN 20 to VLAN 40 any any” you have thrown away the entire benefit — you might as well not have segmented.
The annoying bits, because there are some
This isn’t free of friction, and anyone who tells you otherwise hasn’t lived with it.
The big one is mDNS and service discovery. Chromecasts, AirPlay, smart-home hubs and printers all rely on multicast that does not cross VLANs by default. The moment you put your TV on IoT and your phone on Trusted, casting stops working — the phone broadcasts “who can play video?” and the broadcast never reaches the other segment. The fix is an mDNS reflector (Avahi, or your firewall’s mDNS repeater feature) that relays discovery between the two segments you actually want talking. This is a deliberate, narrow hole rather than leaving the whole network open, and most decent firewalls make it a checkbox.
You also need hardware that supports it: a managed switch and a router that does VLANs and inter-VLAN firewalling. A flat ISP router won’t cut it — it has no concept of tags. A cheap managed switch and a small router running a proper firewall OS get you there for less than the cost of a decent NAS drive.
Troubleshooting: when it inevitably breaks
Everything on a segment is offline. Ninety per cent of the time this is DHCP. Each VLAN needs its own DHCP scope, or a relay pointing at a central server. A device with no address, or a 169.254.x.x self-assigned one, means DHCP isn’t reaching it. Check the scope is bound to the right interface.
A device gets an IP but can’t reach the internet. This is routing or the outbound firewall rule. Confirm the segment has a gateway (the router’s IP in that subnet) and that your default-deny didn’t accidentally block the path to the WAN. Ping the gateway first, then a public resolver like 1.1.1.1, then a hostname — whichever step fails tells you the layer.
You locked yourself out of the switch. This is a rite of passage. Misconfigure a trunk or move the management VLAN, and the web UI vanishes. This is why you keep console access — a serial cable or a dedicated untagged management port — and why you change one thing at a time. Reverting a single change is easy; unpicking five is a lost evening.
Casting or AirPlay half-works. Discovery reaches the device but streaming fails, or vice versa. mDNS reflection handles the discovery, but the actual media stream still needs a firewall rule allowing the two hosts to talk on the streaming ports. Reflection is not a substitute for the pass rule.
A container behind the NAS can’t reach an IoT device. Remember the server segment is default-deny outbound to IoT. If you add a service that legitimately needs to reach a device, it needs its own narrow rule — same shape as the Home Assistant example above.
The verdict
If you have a NAS, a homelab, or any data you’d be upset to lose, and you also own cheap IoT gear — which is to say, if you are a normal person with a router bought in the last few years — VLAN segmentation is worth the weekend it takes to set up. It is the difference between a compromised gadget being an annoyance and being a breach. You don’t need to segment everything on day one; even just splitting “my real computers” from “internet-connected junk I don’t trust” buys you most of the protection for a fraction of the fuss.
Who is this not for? If your entire network is a laptop and a phone and you own nothing you’d call IoT, the complexity outweighs the benefit — you have nothing to segment away from. But that describes almost nobody any more. The moment you add a smart bulb, a doorbell camera, or a NAS worth protecting, the maths tips.
The smart toaster is going to get compromised eventually. The whole point of segmentation is to make sure that when it does, it finds itself alone in a room with a locked door, staring at your NAS through glass it can’t break.
Related Content
