Daniel sent us this one — he's been thinking about VLANs and IoT devices, and he noticed something that a lot of people miss. You do the responsible thing, you carve out a separate VLAN for all your smart bulbs and thermostats and cameras, you feel good about it. But then you realize — every device on that VLAN can still talk to every other device on that same VLAN. Your compromised smart plug can still ARP-scan the network, find your NAS, and start poking around. The fence is around the pasture, but inside it, the sheep are eating each other.
That's exactly the gap. And it's not theoretical — CISA put out an advisory last year specifically calling out intra-VLAN lateral movement as an overlooked attack vector in IoT deployments. They're seeing this in the wild, not just in lab exercises.
The question Daniel's really asking is: what's the thing that stops devices on the same VLAN from talking to each other, and why isn't it just turned on by default everywhere?
And the reason it's not on by default is that it breaks things people expect to work — but we'll get into that. The core idea is simple: a VLAN says "this group of devices lives in its own broadcast domain, separate from that other group." Client isolation says "and within this group, no device gets to talk to any other device — only to the gateway.
Which is the networking equivalent of assigned seating at a very paranoid dinner party. You can talk to the host, but not to the person next to you.
Here's why that matters. In twenty twenty-four, there was a CVE — CVE twenty twenty-four two three eight nine seven — that hit certain smart thermostats and allowed remote code execution. If that thermostat is on a VLAN without client isolation, the moment it's compromised, it becomes a beachhead. It can scan the local subnet, find your security camera DVR, your file server, your laptop if you accidentally put it on the wrong network. With client isolation enabled, that thermostat is blind. It can reach the internet, it can reach the gateway, and that's it. It doesn't even know its neighbors exist.
The lateral movement risk isn't some edge case — it's the whole reason an attacker bothers compromising a light bulb in the first place. Nobody's hacking your smart plug because they want to turn off your lamp.
Right, the light bulb is the cheapest ticket into the network. These devices have minimal security, they rarely get firmware updates, and they sit there for years. An attacker compromises one, and then the real prize is whatever else is reachable from that foothold. Without client isolation, the whole VLAN is a playground. With it, the attacker got a light bulb and nothing else.
Which is why enterprise guest networks have been doing this forever. You connect to hotel Wi-Fi, you can get to the internet, but you cannot see the laptop of the person in the room next to you. That's client isolation. Cisco, Aruba, Mist — they all enable it by default on guest SSIDs. The question is why we don't treat IoT devices the same way we treat strangers in a hotel lobby.
Because consumers don't know to ask for it, and a lot of consumer router firmware buries the setting three menus deep under a name that means nothing to a normal person. " "Station-to-station blocking." These are not labels that scream "turn me on to prevent your toaster from attacking your file server.
"Station-to-station blocking" sounds like a train scheduling problem, not a security feature.
That's the marketing failure here. The mechanism itself is straightforward. On Wi-Fi, the access point simply refuses to forward frames between associated stations. When your smart bulb sends a packet destined for your smart lock's MAC address, the AP goes — nope, dropped. On wired networks, you've got Private VLANs per RFC fifty-five seventeen, which define three port types: promiscuous ports that can talk to anything, isolated ports that can only talk to promiscuous ports, and community ports that can talk to each other and to promiscuous ports.
Promiscuous is the uplink to the router, isolated is solitary confinement, and community is a small group of devices that are allowed to gossip among themselves but not with outsiders.
That's exactly the mental model. And the packet-level behavior is worth understanding because it's not a firewall rule — it's happening at layer two, at the switch or the AP, before the frame even gets forwarded. The switch looks at the destination MAC, checks whether the source port and destination port are allowed to communicate per the PVLAN configuration, and if they're not, the frame never leaves the switch. It's not routed, it's not inspected, it's just silently discarded.
Which is both elegant and brutal. There's no negotiation, no error message back to the device. The packet goes into the void.
From a security perspective, that's exactly what you want. The compromised device can't even enumerate what else is on the network. It sends an ARP request saying "who has this IP address," and if client isolation is working correctly, those ARP requests go nowhere. The device is alone in a crowded room with earplugs and a blindfold.
Let me poke at the obvious tension here. A lot of IoT setups actually need devices to talk to each other. Your phone needs to discover the smart speaker to send it audio. Your hub needs to send commands to individual bulbs. If you flip on client isolation, doesn't all of that just stop working?
It absolutely does, and that's the tradeoff. Peer-to-peer discovery breaks. mDNS, which is how your phone finds the Chromecast or the printer — gone. Direct device-to-device communication over the local subnet — dead. Which is why you don't just blindly flip the switch and walk away. You have to think about what actually needs to talk to what.
The smart approach is hub-and-spoke. Everything talks to a central controller, nothing talks to each other directly.
Your Home Assistant server or your Hubitat hub sits on a promiscuous port or gets an ACL exception, and it's the only thing allowed to initiate connections to the isolated devices. The bulbs don't need to talk to each other — they need to talk to the hub, which coordinates them. The phone app talks to the hub, not directly to each device. It's cleaner architecture anyway, and it aligns perfectly with a secure network design.
Which makes me think the real problem is that most consumer IoT isn't designed with this topology in mind. The devices assume they're on a flat, friendly network where everyone can chat.
That assumption is a legacy of how home networking evolved. For twenty years, the home network was a handful of trusted devices — a couple of laptops, a printer, maybe a game console. Everything was implicitly trusted because you bought it, you plugged it in, you knew what it was. The IoT era broke that model entirely, but the default network configuration never caught up.
We're living in a world where the security model is still "trust the devices you plugged in," but the devices you're plugging in now are manufactured by companies you've never heard of, running firmware that hasn't been updated since the factory, phoning home to servers in six different countries.
That's why CISA's advisory was so pointed about this. They're not saying VLANs are bad — VLANs are the first step. But they're explicitly saying that for critical infrastructure and for any deployment where IoT devices are on the network, you need micro-segmentation and client isolation. The VLAN is the broad stroke, and client isolation is the fine detail. You need both.
The hierarchy is: separate your IoT stuff from your trusted stuff with a VLAN, and then within the IoT zone, make sure the devices can't see each other unless you've explicitly permitted it.
That's the zero-trust approach applied to the local network. No implicit trust based on being on the same subnet. Every device is assumed hostile until proven otherwise, and the default posture is isolation.
Which sounds paranoid until you remember that the average smart home has something like thirty connected devices, and any one of them is a potential entry point. The attack surface isn't your router anymore — it's every single thing with a Wi-Fi chip.
The numbers back this up. There was research showing that a typical IoT device is probed by malicious traffic within minutes of being connected to the internet. These things are under constant, automated assault. The question isn't whether one of them will be compromised — it's whether the compromise stops at that one device or spreads to everything else.
Daniel's instinct is right. Putting IoT on a VLAN is necessary but not sufficient. The lateral movement risk is real, client isolation is the fix, and the only reason it's not universal is that it requires a little bit of planning around what needs to talk to what.
The good news is that for a lot of home users, the hardware they already own supports this. Ubiquiti UniFi lets you enable client isolation per SSID with a checkbox. TP-Link Omada has port isolation on their managed switches. MikroTik supports Private VLANs through bridge VLAN filtering. It's not exotic enterprise-only technology — it's just underused.
The checkbox that could have saved your NAS from your thermostat. That's the episode, really.
We haven't even gotten into what happens when you actually deploy this — the broken functionality, the ACL workarounds, the hybrid approaches that keep things working while still locking down lateral movement. There's a whole practical layer to this that's worth walking through.
Let's do that. We've established the problem and the mechanism. Next step is what actually breaks when you flip that switch, and how to fix it without undoing all the security you just gained.
Let's get precise about the mechanism, because the way client isolation actually drops frames is worth understanding. On Wi-Fi, the access point maintains a station association table — every device connected, its MAC address, its capabilities. Normally, when one associated station sends a frame destined for another associated station's MAC, the AP forwards it. Client isolation changes exactly one line of logic: if the destination MAC is also in the station table, drop the frame.
The AP becomes a bouncer who only lets you talk to the internet. You try to hand a note to the guy at table three, the bouncer eats the note.
That's it. And because it's enforced at the AP, it doesn't matter what the devices try — ARP requests, TCP SYN packets, mDNS discovery, all of it hits the AP and dies. The isolated device gets no response, which means from its perspective, the subnet looks empty except for the gateway.
Which brings up an interesting point about ARP. If the device can't ARP, it can't even build a MAC address table of its neighbors. It's not just that it can't communicate — it can't even map the local network.
Right, and that's the reconnaissance kill. When an attacker compromises a device and runs something like arp-scan or nmap on the local subnet, those tools work by sending ARP requests and seeing who answers. With client isolation, no answers ever come back. The attacker's scan returns nothing — not because the scan failed, but because the switch or AP intercepted every probe and dropped it.
You're not just blocking the lateral movement itself, you're blocking the step before lateral movement. You can't attack what you can't discover.
And that's why this is more powerful than a firewall rule that just blocks certain ports. A firewall rule says "you can see the device but you can't talk to it on port twenty-two." Client isolation says "there is no device to see." The attack surface isn't reduced — it's made invisible.
Now, on the wired side, you mentioned RFC fifty-five seventeen and those three port types. Walk me through how that maps to a real switch configuration.
Picture a twenty-four port managed switch. You designate port one as promiscuous — that's your uplink to the router. Ports two through twenty are isolated — each one can only talk to port one. Ports twenty-one through twenty-four are community — they can talk to each other and to port one, but not to the isolated ports. So if you plug your NAS into an isolated port, and your smart thermostat into another isolated port, those two devices are on the same VLAN, same subnet, but the switch will never forward a frame between them.
The broadcast domain is shared, but the forwarding behavior is surgically restricted. Same neighborhood, but every house has a wall around it that only opens toward the main road.
That's the image. And here's the subtlety — broadcast traffic still reaches everyone on a PVLAN. ARP requests sent to the broadcast address will hit all ports, because broadcasts by definition go everywhere in the broadcast domain. But the critical part is that unicast responses to those broadcasts get dropped if the responding device is on an isolated port trying to reply directly to another isolated port.
The device hears the ARP request, tries to answer, and the switch eats the answer.
Which means from a reconnaissance standpoint, it's the same result — the scanning device gets silence. The broadcast went out, but no unicast reply ever came back.
This is all happening at layer two, before any routing decision, before any firewall inspection. The switch's forwarding ASIC just checks a table and drops the frame in hardware. No CPU overhead, no latency penalty.
Which is why it scales. You can have hundreds of isolated ports and the switching performance is identical. It's not inspecting packets, it's not doing deep packet inspection — it's comparing two port indices against a policy bitmask and making a sub-microsecond decision.
The performance argument against it is basically nonexistent. The only real objection is the functionality one — things stop discovering each other, and you have to design around that.
That's where we should go next — what actually breaks, what the workarounds look like, and how to think about the exceptions you need to carve out.
Take the Sonos problem. You've got a speaker on your IoT VLAN, you enable client isolation, and suddenly the phone app can't see it anymore. The app sends a discovery broadcast, the speaker hears it and tries to respond directly to the phone, and the AP drops the response. From the user's perspective, the speaker just vanished.
Which is the moment most people undo the setting and declare client isolation broken and useless.
Right, and the fix isn't to abandon isolation — it's to change the architecture. Sonos actually supports a workaround for this. You can designate one speaker as the wired root, connect it to a port that has an ACL exception, and let that speaker act as a bridge. But the cleaner solution is what you said earlier — hub-and-spoke. Home Assistant sits on a community port or gets a firewall rule that lets it initiate connections to all the isolated devices, and your phone talks to Home Assistant, not directly to the bulbs or speakers.
The phone app becomes a remote control for the hub, not a direct peer on the network. Which is already how most of these systems work under the hood anyway — the app isn't sending commands straight to the bulb, it's hitting a cloud API or a local controller.
And that's why the broken functionality argument is often weaker than people think. A lot of consumer IoT already routes through a cloud service or a hub. The device-to-device communication that breaks is usually convenience features — AirPlay discovery, printer auto-detection, that kind of thing. The core functionality of turning on a light or checking a camera feed doesn't require peer-to-peer at all.
Which makes me think the real barrier isn't technical, it's that nobody explains this during setup. The onboarding app for your smart plug doesn't say "hey, for maximum security, put me on an isolated network where I can only talk to the internet." It just assumes a flat network and moves on.
That's the industry gap CISA was pointing at. The device manufacturers aren't incentivized to make security the default, and the network equipment makers bury the setting. So the user who actually cares about this is left doing their own research and hoping they don't break something.
If I'm that user, standing in front of my router's admin panel, what am I actually looking for? What are the magic words?
Depends on the ecosystem. On Ubiquiti UniFi, you go to the Wi-Fi network settings, find the IoT SSID, and there's a toggle labeled "Client Device Isolation" — that's the one. On TP-Link Omada, it's under the SSID advanced settings as "AP Isolation." On MikroTik, you're setting up bridge filter rules or using the wireless isolation option in the access list. For wired networks, if you've got a managed switch that supports Private VLANs, you're looking for "port isolation" or "PVLAN" in the VLAN configuration.
If you're on a consumer all-in-one router from your ISP, you're probably out of luck.
Some consumer routers expose it on the guest network only — they'll have a checkbox for "allow guests to see each other" that's unchecked by default. But for a custom IoT VLAN, you usually need at least prosumer gear. Which is frustrating, because the capability exists in the chipsets — it's just not exposed in the firmware.
There's a hardware capability sitting dormant in millions of routers because the software doesn't surface it. That's a security vulnerability by omission.
It absolutely is. And it's one of those things where regulation might eventually force the issue — the same way car manufacturers were eventually required to make airbags standard. Default-on client isolation for any SSID tagged as a guest or IoT network would eliminate a huge class of lateral movement attacks overnight.
In the meantime, the people who know about it get a quiet security advantage that most attackers are counting on not being there.
Which is a pretty good summary of network security in general, honestly.
If the capability is sitting dormant and the industry isn't surfacing it, the people who do turn it on are mostly in enterprise environments where it's already standard practice. What does that actually look like outside the guest Wi-Fi example?
Hospitals are the case study I keep coming back to. Picture a floor with fifty infusion pumps, all on the same VLAN, all reporting to a central monitoring server. Those pumps have no business talking to each other — they're not sharing data, they're not coordinating doses. But if one of them gets compromised, and there's no client isolation, it can scan the subnet and find every other pump, plus the nurse call system, plus anything else on that segment.
Which in a hospital context isn't just a data breach — it's a patient safety issue.
So the standard deployment pattern is a Private VLAN where every infusion pump sits on an isolated port, and the monitoring server sits on a promiscuous port. The pumps can only talk to the server. If one pump gets popped, the attacker owns a pump and nothing else. They can't even see the other forty-nine pumps.
That's the same pattern hotels use, right? Every room gets an isolated port or an isolated Wi-Fi session, and the only thing reachable is the gateway.
Industrial IoT follows the same logic. A factory floor with hundreds of sensors reporting to a central SCADA system — those sensors don't need to talk to each other, they need to talk to the collector. Client isolation means a compromised vibration sensor on conveyor belt three doesn't become a launching pad for attacking the PLC that controls the entire line.
The pattern across all these environments is the same: identify the one or two things that legitimately need to initiate connections to everything else, put those on promiscuous or community ports, and isolate everything else. It's not that nothing can talk — it's that the direction of communication is tightly controlled.
That's where this connects to zero-trust architecture. The core zero-trust principle is that network location doesn't confer trust. Being on the same subnet doesn't mean you're friendly. Client isolation operationalizes that at layer two — it's the networking equivalent of "I don't care that you're in the building, you still need an escort.
Which makes the CISA advisory less of a surprise and more of a "why did this take so long" moment. They're not inventing a new practice, they're telling critical infrastructure operators to apply a pattern that hotels and hospitals have been using for a decade.
Right, and the advisory specifically calls out micro-segmentation alongside client isolation. The idea is that you don't just have one big IoT VLAN — you break things into smaller groups based on function and risk profile, then apply isolation within each group. Cameras on one segment, environmental sensors on another, building controls on a third. VLANs do the macro-segmentation, client isolation handles the micro.
The hybrid approach Daniel's really asking about is: VLANs for the broad categories, client isolation for the fine-grained blocking within each category, and ACL exceptions for the specific devices that need to talk across those boundaries.
That's the blueprint. And the ACL piece is where you get your functionality back without sacrificing security. On a Ubiquiti setup, for example, you'd have an IoT VLAN with client isolation enabled, but you'd add a firewall rule that allows traffic from the Home Assistant server's IP to the IoT subnet on the specific ports those devices need. The bulbs can't initiate anything, but the hub can reach them.
The beauty of that is the exceptions are explicit and auditable. You're not relying on a vague sense that "these devices should be able to talk" — you've written down exactly which IP can talk to which subnet on which ports. If something breaks, you know where to look.
If something starts behaving strangely, you know exactly what shouldn't be happening. A connection attempt from a bulb to another bulb is a red flag, not just background noise.
If someone's listening and wants to act on this, where do they actually start? Not the theory — the button to click.
First thing: log into your router or access point and find the IoT VLAN you already set up. Dig into the Wi-Fi settings for that SSID. You're looking for "AP Isolation," "Client Isolation," or "Station Separation" — different vendors, different labels, same function. On a managed switch, it's under VLAN configuration as "Port Isolation" or "Private VLAN." If you see it and it's off, that's your project for this weekend.
Before you flip it, make a list. What devices are on that VLAN, and which ones actually need to talk to each other? Write it down. If the answer is "nothing needs to talk to anything else except the internet," you're done — flip the switch and walk away.
If the answer is "my phone needs to discover the speaker" or "the hub needs to reach the bulbs," then you've got a second step. Find the ACL or firewall section in your router, and create a rule that allows the hub's IP — or the phone's IP — to initiate connections to the IoT subnet. The key word is initiate. You're not opening a two-way conversation, you're granting one device permission to knock on doors.
The cleanest version of this, if you're building from scratch or willing to reorganize, is the central controller model. Pick one device — Home Assistant, Hubitat, whatever you use — and make it the only thing allowed to talk to the isolated devices. Everything else talks to the controller. The controller talks to the devices.
For enterprise folks, the third piece is 802.You're already doing dynamic VLAN assignment based on device identity, which means you can automatically shunt IoT devices, BYOD phones, and contractor laptops into isolated segments the moment they authenticate. No manual VLAN tagging, no hoping someone remembers to put the infusion pump on the right port. The network sees the device, assigns the policy, and isolation is enforced before the first packet leaves the switch.
The three steps are: check if isolation is available and turn it on, carve out explicit exceptions for the things that actually need to talk, and if you're in an enterprise environment, automate the whole thing with 802.1X so the policy follows the device. That's the checklist.
If your current router doesn't support it at all, now you know what to look for the next time you upgrade. Client isolation should be a checkbox, not a research project.
If we've got the checklist, and we know how to do this today, the thing I keep coming back to is where this is all heading. Because the devices themselves are getting more sophisticated — Thread, Matter, mesh networking. These protocols assume devices need to talk to each other directly. A Matter light bulb acting as a border router is supposed to forward messages for the sensor three hops away. Client isolation says no forwarding. Those two things are on a collision course.
That's the tension, and it's not going away. Thread and Matter are built on IPv6, they assume peer-to-peer connectivity is available, and a lot of their efficiency comes from devices relaying for each other rather than everything going through a central hub. If you turn on client isolation, you break the mesh. If you turn it off, you're back to trusting every device on the segment.
The security model and the functionality model are pulling in opposite directions, and right now the answer is "pick one.
For now, yes. But I think we're going to see Matter and Thread incorporate access control at the application layer that makes network-level isolation less necessary. The Matter specification already includes something called Access Control Lists — not network ACLs, but application-layer permissions that govern which devices can send commands to which other devices. A sensor can forward packets at the network layer, but it can't tell the lock to unlock unless it's been explicitly granted that permission.
The trust boundary moves up the stack. Instead of the switch dropping frames, the device itself says "I don't know you, I'm not processing that command.
That's the direction zero-trust always goes — enforce policy as close to the resource as possible. The network provides a coarse filter, the application provides the fine filter. Client isolation is the coarse filter. Matter's ACLs are the fine filter. You want both, but if you have to choose one, the application-layer control gives you more granularity.
Which means the next generation of network gear probably bakes client isolation into the default IoT profile, and the next generation of IoT devices stops assuming a friendly local network. Both sides converge toward "trust nothing until proven otherwise.
That's a better world. The smart home that's secure by default, where the light bulb can forward packets for the mesh but can't unlock the door, where the network segments things automatically and the devices enforce permissions at the application layer. We're not there yet, but the pieces exist.
Daniel's question lands at a transition point. Right now, if you care about security, you do the VLAN, you do the client isolation, you carve out your exceptions. In a few years, a lot of this will be automatic — the network and the devices will negotiate trust without you opening an admin panel.
Which is the dream, honestly. Security that doesn't require a weekend of research and a spreadsheet of MAC addresses.
Until then, check that checkbox.
Now: Hilbert's daily fun fact.
Hilbert: In eighteen eighty-seven, a French mineralogist exploring the Comoros islands discovered a deposit of scheelite that fluoresced an unusually intense blue under ultraviolet light and nearly mistook it for a previously unknown gemstone. He spent three weeks drafting a paper announcing the discovery before a colleague in Paris wired him to point out that scheelite fluorescence had been documented in Saxony four years earlier. The paper was never published.
The near-miss glory of almost discovering something already discovered.
Three weeks of writing, vaporized by a telegraph.
That's the show. Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. If you want to send us a question like Daniel did, email the show at show at my weird prompts dot com.
We'll be back next week.
