Guest networks and keeping smart home gear off your main LAN

Switching on your router's guest SSID does not move your smart plugs onto a separate network. It gives them a different name and password, usually on the same Layer 2 segment, plus an optional filter that blocks traffic between wireless clients. That filter is a vendor firmware feature with no standardized scope. A boundary that actually holds needs an 802.1Q VLAN with a router or firewall enforcing rules between it and your LAN.

Client isolation is a firmware option, not a certification

The Wi-Fi Alliance's security page lists what it certifies: WPA3, Wi-Fi Enhanced Open, and Protected Management Frames. Not one of them is about keeping clients away from each other or from a LAN. Enhanced Open is the one that gets misread as an isolation feature, and its own description says otherwise: it "preserves the convenience that open networks offer while reducing some of the risks associated with accessing an unsecured network." That is encryption for open networks, not segmentation.

"Client isolation" and "AP isolation" are names various vendors give to broadly similar behavior, with no shared definition. Whether the filter covers one radio, one access point, or every node in a mesh is a per-product, per-firmware question, and it changes between releases. The usual mistake follows: people ping a laptop from a phone on the same mesh node, watch it fail, and conclude the house is covered. Test from a different node, and to a wired device.

Three different things get called isolation

The middle row is the one that fools competent people. Handing your cameras a second DHCP scope, say 192.168.20.0/24 alongside 192.168.1.0/24 on the same switches and access points, looks like separation in the address plan and delivers none. Broadcast and multicast traffic does not care about your subnet mask. A permissive router will also route between the two subnets unless a rule stops it.

IEEE 802.1Q-2022, published in December 2022 and still the active revision, is the VLAN standard, and its scope is the operation of "MAC Bridges and VLAN Bridges." It is a Layer 2 bridging and tagging specification, independent of IP addressing. That independence is the point: the tag creates a genuinely separate broadcast domain, and traffic between domains has to pass through something that routes, which is also something you can filter.

The mDNS rule that makes a second subnet pointless

RFC 6762, the Multicast DNS standard published in February 2013, defines the discovery boundary as the link rather than the subnet. Queries for .local. names go to the IPv4 link-local multicast address 224.0.0.251 or the IPv6 address FF02::FB, and the RFC states that responses arriving at those addresses "are necessarily deemed to have originated on the local link, regardless of source IP address." It spells out why: to keep things working in "unusual configurations, such as multiple logical IP subnets overlayed on a single link."

That sentence is why a second subnet does not hide anything. Your Chromecast will still see and be seen by everything sharing its physical segment.

A routed VLAN behaves differently because of where those addresses sit, not because of anything mDNS does. The address 224.0.0.251 falls inside 224.0.0.0/24, the Local Network Control Block, which RFC 5771 describes as carrying "protocol control traffic that is not forwarded off link." FF02::FB is link-local scope on the IPv6 side. A router is not weighing whether to pass this traffic; it does not pass it at all. Put the phone and the speaker in separate broadcast domains and the query never arrives.

RFC 6762 adds a receiver-side rule on top: a host querying one of those addresses "MUST only accept responses to that query that originate from the local link, and silently discard any other response packets." The TTL detail that gets quoted in forum threads is narrower than it looks. Responses "SHOULD be sent with IP TTL set to 255," but the RFC gives the reason as backwards compatibility with "older Multicast DNS queriers (implementing a draft version of this document, posted in February 2004)" that discarded anything arriving with another value. It is not what stops discovery at a VLAN edge.

The threat is the cheap device nobody patches

Mirai remains the clearest evidence that consumer gadgets, not PCs, are the practical attack surface. Cloudflare's retrospective puts the peak at "over 600,000 vulnerable IoT devices," assembled from "home routers, air-quality monitors, and personal surveillance cameras." The same analysis records that "OVH reported that these attacks exceeded 1 Tbps," and that the assault on Krebs on Security was "topping out at 623 Gbps." Those numbers describe 2016. Treat them as the landmark case for the category, not a measurement of botnets now.

The regulatory response tells you how bad the default state was. NIST IR 8425, published September 2022, sets out ten capabilities for consumer IoT products in two groups. Six are product capabilities: Asset Identification, Product Configuration, Data Protection, Interface Access Control, Software Update, and Cybersecurity State Awareness. Four more are non-technical: documentation, query reception, information dissemination, and product education. The UK made one of them law. SI 2023/1007 came into force on 29 April 2024 and requires in Schedule 1 that passwords be "unique per product" or "defined by the user of the product," and not derived from incremental counters, public information, or product identifiers. The EU's Cyber Resilience Act entered into force on 10 December 2024, covers consumer smart-home products explicitly, starts its vulnerability-reporting obligations on 11 September 2026, and applies its main obligations from 11 December 2027.

The US label is further behind than most articles suggest. The FCC's Cyber Trust Mark is voluntary, ioXt Alliance became Lead Administrator effective 13 April 2026 after UL Solutions withdrew on 19 December 2025, and as of a 9 June 2026 snapshot of the FCC's own page the program had not yet opened for product applications. It also "does not include personal computers, smartphones, and routers."

Segment on the assumption that the device in front of you will stop receiving firmware updates and that nobody will tell you when.

What breaks the moment you segment

Casting is first. Google's Chromecast support documentation states the requirement without qualification: "Make sure your mobile device or computer is connected to the same Wi-Fi network as your Chromecast." There is no documented guest-network or VLAN exception. The same page says discovery of Cast-enabled devices needs the Local Network permission on iOS 14 or later and macOS 15 or later, so a failed discovery has two possible causes on Apple hardware.

AirPlay and AirPrint fail for the same underlying reason. Apple's zero-configuration stack, Bonjour, is "available as Open Source under the Apache 2.0 license" and ships as mDNSResponder, and RFC 6762 itself was written by two Apple engineers. The link-local scoping above applies to it identically. A printer on the IoT VLAN disappears from the print dialog on a laptop that is not on that VLAN, and no amount of driver reinstalling changes it.

Matter does not rescue you here. The Connectivity Standards Alliance calls it "a unifying, IP-based connectivity protocol" and says the first specification release "will run on Wi-Fi and Thread network layers and will use Bluetooth Low Energy for commissioning." Thread is IPv6-based and, per the Thread Group, integrates with larger IP networks without needing "proprietary gateways or translators." A Thread device reaches everything else through a border router, so a VLAN boundary drawn on the Wi-Fi and Ethernet side still applies. Matter 1.6 arrived in mid-2026; Silicon Labs' summary covers thermostat suggestions, capability reporting and certificate revocation, nothing about discovery across subnets.

If your firmware offers a function that forwards multicast discovery between segments, confirm it works on your specific model before building a design that depends on it. Names and coverage vary, and a relay that passes announcements both ways gives back part of what the VLAN was for.

Draw the line where discovery does not need to cross it

The workable split is not "IoT on one side, everything else on the other." It is "devices you discover and control from a phone stay with the phones, devices you never interact with directly go behind the wall." Cameras, sensors, plugs, bulbs, and anything with a cloud app that works over the internet belong on the isolated VLAN, outbound internet allowed, inbound from the main LAN blocked. Chromecasts, AirPlay receivers, printers, and speakers you cast to belong on the same segment as the phones and laptops. Fighting that with relays costs more evenings than the marginal risk reduction is worth.

Two VLAN-capable options, priced from the vendors' own stores. The Ubiquiti UniFi Dream Router lists at $199.00 and is described as a "Desktop UniFi Cloud Gateway with integrated WiFi 6 and PoE switching," running the UniFi Network application on the device itself; Ubiquiti's store marked it sold out when this was written, so confirm availability first. The Firewalla Gold SE lists at $519.00 with a quad-core ARM CPU, 2 x 2.5 Gbps and 2 x 1 Gbps interfaces, 4096 MB of RAM, 32 GB of storage, VLAN support listed as unlimited, and per-segment policy its page describes as creating "secondary firewalls within your network through network segmentation." It carries no radios, so it suits the case where you already own access points and can tag each SSID to its VLAN.

One trap to plan for first: commissioning. Plenty of Wi-Fi devices expect your phone on the same segment during setup, because pairing leans on the same local discovery you just blocked. Join the IoT SSID from your phone, pair the device, then switch back. Matter is the exception, since the CSA specifies Bluetooth Low Energy for that step rather than the IP network.