Smart-home segmentation, and why it isn't optional

You do the right thing. The smart plugs, the TV, the cameras and the thermostat go onto their own VLAN, walled off from the laptops and the accounting machine. Then somebody picks up a phone to cast something and the TV isn't in the list. The printer has vanished. The kitchen speakers stopped showing up.

So it gets undone, because the household is complaining, and the network goes back to flat. That's how most segmentation projects die — not at the firewall, at the discovery layer.

I've covered trust zones and forward-chain rules before, so assume you have a router that can do VLANs and filter between them. This is about what makes smart-home gear a different problem from everything else you own.

Why this equipment is the worst thing on your network

Three properties, and it's the combination that hurts:

It doesn't get patched. A thirty-dollar sensor has no real update mechanism, and the vendor's incentive to patch a discontinued product is zero. Your laptop fixes itself every month. That sensor runs whatever shipped on it, and will in eight years.

It phones home constantly, by design. For the app to work from anywhere, the device holds an outbound connection open to a vendor cloud. That tunnel is opened from the inside, so your firewall's default deny-inbound does nothing about it.

There's a lot of it. Twenty devices, six vendors, three you'd have to look up. Nobody audits twenty devices.

Be precise about the threat, though. It isn't a stranger taking over your bulb for entertainment. It's that the bulb shares a broadcast domain with the machine that has your books on it, and that a camera, a microphone, or a log of when the house sits empty is handled by a company you cannot evaluate.

The rule set is short

Five statements cover it. Smart-home devices get internet where they genuinely need it. They can never open a connection into the trusted network. Trusted can open connections into them, so your phone reaches the camera. Neither touches the management VLAN. DNS is forced to your own resolver, so you can see what's being asked for.

The common mistake is going further and giving them no internet at all. Some of it legitimately needs the outside — time sync, weather, push notifications — and blanket blocking creates a support burden that outlasts your patience for it. Let it out, watch what it does, and stop it reaching inward.

The part nobody warns you about

Casting, printing, AirPlay and most "find my device on the network" features run on mDNS — multicast DNS, the thing behind .local names. Announcements go to 224.0.0.251 (or ff02::fb on IPv6) on UDP 5353, and that address is link-local scope: routers are required not to forward it. It was designed to stay inside one broadcast domain.

So the moment the TV is in one VLAN and the phone is in another, discovery stops. Nothing is misconfigured. Your firewall rules are irrelevant here, because the packet never reaches the router as something to be forwarded. People lose evenings adding accept rules to fix a problem that was never a filtering problem.

What you need is a repeater — a reflector, a Bonjour gateway, same idea — something that listens for mDNS on one interface and re-emits it on another. On recent RouterOS (7.16 onward) it's built in and it's one line:

/ip dns set mdns-repeat-ifaces=vlan-trusted,vlan-iot

UniFi and pfSense have their own versions. Then comes the step people skip: you still need the ordinary unicast firewall rule letting the phone connect to the TV once it has found it. Discovery and connection are separate problems, and the repeater only solves the first.

Two caveats. SSDP is a different protocol on a different address (239.255.255.250, UDP 1900), and most mDNS repeaters don't touch it — older casting devices and some DLNA gear discover that way and still won't appear, so check what your device uses before deciding the repeater is broken. And a repeater is a hole you punched on purpose: repeat only between the two VLANs that need each other, never onto guest or management, and keep the forward rules underneath it tight.

The way to sidestep it

The devices that never have this problem aren't on IP at all. Z-Wave and Zigbee talk to a radio inside your hub — no multicast, no VLAN, nothing to discover. Put the hub in the trusted zone with a controlled path into the smart-home VLAN, and the household only ever talks to the hub. Your one cross-zone rule becomes phone to hub.

What to do

1. Inventory what you have, sorted by whether it needs the internet, the LAN, or neither.
2. Build the zones and the five rules.
3. Turn on the mDNS repeater between exactly the two VLANs that need to see each other.
4. Test the household's real use cases before you walk away — cast, print, ring the doorbell, open the camera.
5. Point that VLAN's DNS at your own resolver and read the query log once a month.

Done properly, nobody in the building notices anything changed, which is the point. Done halfway, somebody turns it off inside a week and you're flat again.

Segmentation is layer one of every automation build I quote, before a single device gets ordered — here's the rest of the stack.