Isolate IoT and smart home devices on a dedicated VLAN

What you need

• A router or firewall that can define VLANs and write rules between them. An ISP-supplied box may well not, and replacing it is the real cost of this project.
• A managed switch. An unmanaged one just moves traffic and has no idea which port belongs to which segment, so everything plugged into it lands in the same lane.
• Access points that can tag an SSID onto a VLAN. The gear you most want penned in is on Wi-Fi, so without this the segmentation covers nothing you actually care about.

Zigbee and Z-Wave devices never touch your IP network, so none of this reaches them. What lands on a VLAN is the hub they speak through, whether that is Home Assistant or a vendor bridge.

Carving up the network

Start with three segments, not ten. Trusted, for the computers and phones you control. Smart home, for everything that arrived with an app. Infrastructure, for servers, the NAS and the hub itself. Give each one its own subnet and its own DHCP scope, which is what makes everything below checkable. Add a guest segment if visitors keep asking for the Wi-Fi password.

If you are wondering why not just use the guest network the router already has, that is this pattern with the rules pre-written: internet, no LAN. It holds up until you want the hub to reach your devices, because the isolation that makes a guest network safe is the same isolation that locks your hub out of it.

Move a handful of devices across and write the rules before you move the rest. The default set is short. The smart home segment gets the internet and nothing else. The hub is allowed to reach into it. Trusted devices go almost anywhere, and guests get the internet with no LAN access at all. The useful habit is making each device earn its way onto the LAN rather than granting it by default.

Then check that the thing you built is doing anything at all.

Wi-Fi is where segmentation quietly fails to happen. If the access point or the SSID is not tagged onto the VLAN, every Wi-Fi device keeps landing on the flat network while the switch configuration looks perfect. That is the entire project undone, with nothing on screen to tell you.

The check is dull and worth doing. Join a phone to the smart home SSID and look at the address it gets. Wrong subnet, wrong lane, and the rules you just wrote are guarding an empty room.

What breaks the day after

Discovery. Casting, printer setup and a hub scanning for new devices all lean on multicast, and multicast does not cross a segment boundary. That is not a fault. It is the same property that quiets the network down.

So you put back the crossings you want, and the tool matters. Discovery has to be carried by an mDNS reflector across each pair of segments that needs to see the other. Your phone to the smart home segment, and the hub to it as well if the hub sits with the servers. A firewall rule cannot stand in. Control traffic is the easy half. Once a device is known, the hub talking to it is ordinary one-to-one traffic, and a rule is all it takes. Get the reflector right and the cast button reappears while everything you did not name stays sealed.

The other thing that breaks the day after is you, still in the switch interface. Spanning Tree Protocol is not part of this job, and getting it wrong can cost you the network for a day.

Day to day, cloud-routed platforms shrug at all of this, since their commands go out to the internet and back regardless of which lane the device sits in. Pairing is where it bites. Where an app onboards a device by finding it on the local network, your phone is on the other segment now. Local-first setups need the holes punched all the time, which is a fair price for local control.

What the segments actually buy you

Most people do this for security, and then the reliability wins show up first.

Smart TVs, streaming boxes and sensors announce themselves constantly, and on a flat network every client has to process all of that chatter. It costs bandwidth and CPU time on machines that had no interest in the conversation. The tipping point sneaks up on you, because the client count climbs toward a hundred without anyone deciding to. Give each segment its own broadcast domain and the noise stays where it was made.

Sorting devices by class also makes traffic shaping obvious. Camera traffic can sit at priority one on its own segment without that decision spilling onto everything else in the house.

And when something does misbehave, it misbehaves in one lane. You are looking at one segment instead of the whole house, and the rest of the house stays up while you poke at the problem.

Does a VLAN stop your TV from spying on you?

No, and it is worth being clear about that before you spend a weekend on it.

Automatic content recognition takes snapshots of what is on screen and sends them out over exactly the internet connection you deliberately left open. It does the same to your HDMI inputs, so the cable box and the games console are in the sample too. Segmentation never touches that traffic.

Nor does it stop the gadget getting owned in the first place. One camera-and-microphone robot vacuum was taken over from up to 450 feet away over Bluetooth, rooted, and then reconnected to the internet so the attacker could keep the access from anywhere. Your network was never on the path in.

What the segment contains is the blast radius. That vacuum sits in a lane where it can see the internet and nothing else, so it cannot go looking for your NAS, your file shares, or the laptop with your tax returns on it. Treat this as containment rather than privacy. If you want the telemetry to stop, that is a separate outbound rule per device, and you will find out quickly which of them refuse to work without their cloud.