VLAN segmentation for a home network

The argument for segmenting a residential network is no longer theoretical. The FBI's Internet Crime Complaint Center has recommended it explicitly since at least 2018 — PSA I-080218-PSA states, verbatim, that households should “isolate IoT devices from other network connections.”⁸ A follow-up FBI alert in June 2025 — PSA I-060525-PSA — warns specifically about “cyber criminals gain[ing] unauthorized access to home networks through compromised IoT devices, such as TV streaming devices, digital projectors, aftermarket vehicle infotainment systems, digital picture frames and other products.”¹³

The standards bodies are aligned. NIST's Cybersecurity Framework 2.0, published February 2024, names the relevant trust boundaries by hand. Subcategory PR.IR-01 — “Networks and environments are protected from unauthorized logical access and usage” — gives its implementation example as: “Logically segment organization networks and cloud-based platforms according to trust boundaries and platform types (e.g., IT, IoT, OT, mobile, guests).”⁴ NIST SP 800-53 Rev. 5 control SC-7 (Boundary Protection) requires “subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks.”⁵ NSA's February 2023 cybersecurity information sheet on home networks tells homeowners to separate private WLAN, guest WLAN, and IoT onto distinct networks.⁷

The incidents that justify all of this are public, attributed, and recent. The October 2016 Mirai botnet — covered in US-CERT Alert TA16-288A — built itself out of consumer IP cameras, DVRs, and home routers using a list of 62 common default credentials, then took down Twitter, Reddit, Netflix, and GitHub for much of a day during the attack on Dyn.⁹ In February 2024, the U.S. Department of Justice announced a court-authorized takedown of a botnet run by Russia's GRU (APT 28 / Fancy Bear); the infected devices were Ubiquiti EdgeOS routers that had been compromised by criminals via default passwords, then resold to the GRU as a global espionage platform.¹² The same week, CISA, NSA, FBI, and the Five Eyes published joint advisory AA24-038A on Volt Typhoon — Chinese state actors pre-positioning on U.S. critical infrastructure by way of compromised end-of-life SOHO routers.¹¹ And in August 2024, CISA published ICS advisory ICSA-24-214-07 covering CVE-2024-7029, an unauthenticated command-injection vulnerability (CVSS 8.8) in AVTECH IP cameras — end-of-life devices, no vendor patch, actively exploited by Corona Mirai variants since March 2024.¹⁰

The volume on the homeowner side is similarly clear. Bitdefender and NETGEAR's October 2025 IoT Security Landscape Report — built on telemetry from 6.1 million smart homes and 58 million IoT devices — reported 13.6 billion attacks, 4.6 billion exploit attempts, and an average of almost 30 attempted attacks per day per home. The report notes that “streaming devices, smart TVs, and IP cameras now account for more than half of all known vulnerabilities.”¹⁹ A 2024 ACM ASIA CCS paper that tested 40 commercial home routers found 46 potential vulnerabilities, 30 confirmed exploitable in the latest firmware, with only 5 fixed by the manufacturer.¹⁸ And a 2025 ACM CHI study of household router configuration habits found that 60.6% of users“configure their home router mainly by accepting the default settings.”¹⁷

None of this proves a segmented network is impervious. It proves that the population of devices a household connects to its single flat LAN is being attacked continuously, that a measurable share of those devices ships with exploitable defaults, and that the firms running the federal advisories have stopped framing segmentation as optional. The standards body, the vendor security teams, and the criminal-attribution record now point in the same direction.

The recommended structure for a residential network with smart-home, AV, and surveillance gear:

A sixth ManagementVLAN — holding the gateway, switches, APs, and the UniFi controller itself — is appropriate where the network is professionally installed and the integrator wants a clean out-of-band management plane. For self-installed homes, a single LAN LOCAL firewall rule blocking the IoT, AV, Cameras, and Guest VLANs from reaching the gateway's management ports (22, 80, 443, 8443) accomplishes most of the same goal without adding a whole VLAN to maintain.

The IP-addressing convention worth borrowing from Evan McCann's widely-shared writeup: pick a /16 like 10.250.0.0/16, then make the third octet match the VLAN ID. VLAN 10 becomes 10.250.10.0/24, VLAN 20 becomes 10.250.20.0/24, and so on. The /16 keeps you out of the homogenized 192.168.1.0/24 space that conflicts with every coffee-shop and site-to-site VPN.

Trusted (VLAN 10)

The household's personal computing fabric. Laptops, phones, tablets, a NAS, the home-automation hub (Home Assistant, Hubitat, Apple Home hub on an Apple TV or HomePod). This VLAN is the only one allowed to initiate connections into other VLANs. Stateful return traffic comes back via the Established/Related allow. Outbound internet is unrestricted.

What does notbelong here: anything you bought because it was on sale on Amazon Prime Day with a vendor name you don't recognize, anything that requires its own app to function, anything that phones home to a cloud service you can't identify.

IoT (VLAN 20)

The home for everything cloud-mediated and low-trust. Bridges (Hue, Lutron Caséta, Aqara, SwitchBot), smart speakers (Alexa, Google Home), Wi-Fi smart plugs, generic Matter / Thread devices, smart appliances. The default outbound is internet only; inbound from Trusted is allowed for specific control paths.

Most IoT compromise events end here. The Mirai retrospective, the AVTECH advisory, the Volt Typhoon takedown all involve devices in this category.⁹¹⁰¹¹ The point of segmenting them is not that the device magically becomes safer — it doesn't — but that the rest of the household's network is not on the inside of the bubble when the device gets compromised.

AV / Media (VLAN 30)

Whole-home AV control and media playback. Crestron, Control4, or Savant processor and touch panels; Sonos; intercoms; AV-over-IP endpoints (DM NVX, NetGear AV switching, etc.); the AppleTV or media player when it's tightly integrated with the control system. This VLAN runs an active IGMP querier because most of the audio and video paths on it are multicast, and switches must learn the membership.

Whether AppleTV / HomePod live here or on Trusted is a question of integration depth. In a household with a Crestron or Control4 system that drives the AppleTV, the AppleTV lives on AV with the rest of the control surface. In a household with no AV-control processor at all, the AppleTV is a Trusted device that happens to play media.

Cameras (VLAN 40)

Surveillance cameras and doorbells, plus the NVR if you can justify keeping it on this VLAN rather than Trusted. Cameras speak only to the NVR. Outbound internet is dropped at the firewall by default — turn it on per-camera only if a specific cloud feature is required and the camera's firmware cadence justifies the exposure.

On Ubiquiti hardware, UniFi Protect has a specific requirement: cameras should be on the same VLAN as the NVR (CloudKey, UNVR, or Dream Machine) by default; if you want them on a different VLAN, you must manually set the UniFi Host on each camera.²⁰ Don't fight it — put the NVR on this VLAN, or leave the cameras on whatever VLAN the NVR lives on and accept the structure.

Guest (VLAN 50)

Visitor and contractor devices. Internet only, no inbound, no inter-VLAN. Ubiquiti's own guest-WiFi best practices recommend enabling Network Isolation (the global inter-VLAN block), Client Device Isolation (per-AP), and Device Isolation at the switch level — three controls that collectively prevent a guest device from reaching anything other than its own internet path.²⁵ The DNS resolver this VLAN points at should be the gateway's own resolver, not a Pi-hole or a Trusted-VLAN DNS server, so that guest devices can't probe the household's internal name space by guessing hostnames.

A clean five-VLAN structure works for most of the hardware in the home. A few platforms have specific network requirements that either change which VLAN they live on or change how that VLAN has to be configured. The four worth knowing:

Apple — Bonjour does not cross subnets

Apple's deployment guide states the constraint in its own words: “Bonjour works by using multicast traffic to advertise the availability of services. Because multicast traffic is usually not routed across subnets, it requires Apple TV devices and AirPrint printers to be on the same IP subnet.”²⁶ AirPlay, HomeKit, and AirPrint all use Bonjour discovery (IETF RFC 6762 multicast DNS, on UDP 5353, IPv4 multicast 224.0.0.251, TTL 255 with explicit link-local scope).²

Practical consequence: an iPhone on the Trusted VLAN cannot discover an AirPlay receiver on the AV VLAN unless the gateway is configured to proxy mDNS between the two VLANs. UniFi calls this feature the Multicast DNS Proxy; it's a per-network toggle under Settings. The proxy listens for mDNS queries on one VLAN and replays them on another, so discovery works across the trust boundary without collapsing the boundary itself.²² Matter accessories specifically also require IPv6 link-local routing to be enabled across the VLANs that the Matter hub and the accessory live on — a gotcha that the Apple developer documentation makes clear and that the UniFi default IPv6 firewall does not.

Sonos — same VLAN, IGMP querier, STP enabled

Sonos is the platform most likely to be blamed for a VLAN deployment that “just stopped working.” The vendor's own published guidance is non-negotiable on three points: “Your managed switch must have Spanning Tree Protocol (STP) enabled and BPDU flooding enabled,” and “Sonos products must be on the same VLAN as all devices running the Sonos app.”²⁷ The same support article warns that “many managed switches have STP and BPDU flooding disabled by default” and that the consequence is broadcast storms and network loops.²⁷

Translated: every Sonos speaker, and every device that drives them through the Sonos app, has to be on the same VLAN. In our structure, that VLAN is AV / Media. The iPhone on Trusted reaches Sonos via the mDNS proxy; the Sonos speakers themselves talk to each other on the AV VLAN where STP behaves correctly. IGMP snooping should be enabled on the switches but only paired with an active IGMP querier on the VLAN — snooping without a querier is the single most common cause of Sonos dropping off the network after some idle period.

Crestron — DM NAX requires its own subnet, and cannot use VLAN tags itself

Crestron's own Plan a Network documentation is direct: “Crestron devices should exist on a network separate from other device traffic … Whenever possible, all Crestron devices should be separate on their own VLAN. This allows for smoother operation of the control network.”²⁹ The reason is concrete: Crestron control protocols are latency-sensitive, and the company's AV-over-IP lines — DM NAX (audio) and DM NVX (video) — use PTP clock synchronization, which has hard real-time requirements.

The catch: Crestron's AV-over-IP design guide states that “DM NAX networks should be designed to isolate traffic on network segments specifically configured to handle DM NAX AoIP and DM NVX A/V-over-IP traffic” and that “all DM NAX traffic must be relegated to a single subnet” because PTP uses TTL=1.³⁰ DM NAX endpoints themselves do notsupport 802.1Q VLAN tagging — meaning the switch ports they attach to have to be configured as untagged access ports on the AV VLAN. Other Crestron control hardware (touch panels, the processor itself) can live on the same AV VLAN as tagged or untagged participants. The takeaway: AV-over-IP endpoints don't tag; touch panels and processors share the VLAN; IGMP querier and DSCP marking (CS7 for PTP, CS6 for control, EF for audio) are mandatory.

Savant — the platform that refuses to be segmented

Savant is the cleanest counterexample in this article. Their published Network Troubleshooting Guide states, verbatim: “All Savant devices use self-discovery methods. Therefore, all devices communicating with a Savant device must be added to the same subnet (Ex: 192.168.1.xxx).”³¹ The same guide continues: “Do not block or restrict UDP broadcasts. Do not block multicast messages.” and “Network Packet Shaping, Traffic Shaping, QoS, and other Bandwidth Management techniques are NOT recommended.”³¹

Practical consequence: in a Savant household, the AV VLAN holds essentially everything Savant touches — the host, the iPads running the Savant app, the AppleTVs, the streamers, the lighting hardware, and anything else expected to be discoverable. The Trusted-vs-AV split is softer than in a Crestron or Control4 household; the household's phones are still on Trusted, but Savant's own ecosystem stays inside one broadcast domain. The mDNS proxy from Trusted to AV becomes load-bearing.

Lutron — Bonjour on, IGMP snooping off

Lutron's network requirements page for Caséta, RA2 Select, and RadioRA 3 / HomeWorks is unusual on the multicast side. It explicitly tells the installer: “Enable: Bonjour, mDNS, multicast” and “Disable: QoS, IGMP Snooping.”²⁸ The IGMP-snooping-off requirement is the inverse of the Sonos / Crestron position and surprises every installer who learns it the first time. In a home that mixes Lutron with Sonos or with Crestron AV-over-IP, IGMP snooping has to be enabled on the AV VLAN but explicitly disabled on the Lutron management path — in practice, that means the Lutron processor on its own VLAN, or the Lutron processor on the AV VLAN with a per-port snooping exception. Either is acceptable; neither is the default.

A useful at-a-glance reference, because the four major residential AV / lighting platforms do not agree with each other on what the network underneath should look like.

The honest summary the table is reaching toward: a clean “one VLAN structure for every home” doesn't exist. The vendor mix dictates the VLAN strategy more than any best-practice guide. The five VLANs are the chassis; the contents adjust to which AV ecosystem the house actually runs.

VLANs without firewall rules are aesthetic; they do not produce a security improvement. NIST SP 800-41 Rev. 1 — the federal firewall guideline — defines the default posture: “deny by default: to block all inbound and outbound traffic that has not been expressly permitted by firewall policy,”with the reasoning that “because of the dynamic nature of hosts, networks, protocols, and applications, deny by default is a more secure approach than permitting all traffic that is not explicitly forbidden.”⁶

On a UniFi gateway, deny-by-default isn't the shipping posture between VLANs — it has to be turned on. The Network Isolation feature (under each VLAN's settings) “automatically configures the necessary firewall rules to block inter-VLAN traffic and is the most common way to restrict traffic between VLANs with minimal setup.”²¹ Enable it on IoT, AV, Cameras, and Guest. Trusted stays open so that it can initiate to the others.

On top of the deny-by-default base, four rule categories cover the residential case:

1. Allow ESTABLISHED and RELATED first. Stateful firewalls keep a connection table and automatically permit return traffic for any conversation that's already in progress. This rule has to be near the top of the chain on every VLAN, or specific allow rules below it become unidirectional and break in subtle ways.
2. Asymmetric Trusted → other-VLAN allows. Trusted can initiate to IoT (control), to AV (the iPad app), to Cameras (live view), and to the gateway (management). None of the other VLANs can initiate back to Trusted on their own.
3. Specific service allows.If the IoT VLAN's Home Assistant bridge needs to reach an MQTT broker on Trusted, that's one rule. If a Sonos speaker on AV needs to read music off a NAS on Trusted, that's another. These rules name the source VLAN, destination IP, and destination port — not blanket inter-VLAN allows.
4. LAN LOCAL: block IoT / AV / Cameras / Guest from the gateway. A separate category on most firewalls (UniFi included) for traffic destined to the firewall itself. Lock down 22, 80, 443, 8443 from the non-Trusted VLANs.

The ordering matters. Established/Related at the top. Specific allows in the middle. The default deny at the bottom, where it catches everything that hasn't matched a rule above it. CIS Critical Security Control 12 v8.1 puts the architectural principle plainly: “Establish, implement, and actively manage … network devices, in order to prevent attackers from exploiting vulnerable network services and access points.”¹⁵

The single most common reason a freshly-segmented home network breaks the homeowner's daily experience is multicast service discovery. AirPlay, Chromecast, HomeKit, Matter, and Sonos all rely on multicast DNS to find one another. RFC 6762 — the IETF standard authored by Apple engineers — defines mDNS as “the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server.”² The phrase that matters is on the local link. mDNS queries go to multicast address 224.0.0.251 with TTL=255 on transmit; the protocol's own receivers reject packets with any other TTL. The effect: a router doesn't forward mDNS between its interfaces, by design.

So an iPhone on Trusted issues a multicast query for _airplay._tcp.local.; the Apple TV on AV would respond if it heard the query; the router refuses to relay the query across the VLAN boundary; the iPhone times out and shows no AirPlay receivers. The fix is not to break the VLAN boundary — that would defeat the segmentation. The fix is a proxy running on the gateway that listens for mDNS on one VLAN, re-emits the same query on another, and relays the responses back.

On UniFi gateways, this feature is called the Multicast DNS Proxy and lives under each network's advanced settings. Ubiquiti documents it directly:“A Multicast DNS Proxy is active on the UniFi Gateway and forwards multicast traffic from devices between different networks (VLANs). Enable this feature when features like AirPlay, AirPrint, or Chromecast should be shared across different networks/VLANs.”²² Three modes are offered: Auto (forward all mDNS across selected VLANs), Off (no forwarding), and Custom (specific services only, such as AirPlay without Chromecast). Custom is the right answer if the household wants to avoid IoT discovery advertisements leaking into the Trusted VLAN's browse list.

For non-UniFi gateways, the equivalent is Avahi running on a Linux router with enable-reflector=yes in avahi-daemon.conf, or vendor-specific features like pfSense's Avahi package and OPNsense's Bonjour Multicast Repeater plugin. The mechanic is the same: relay the link-local packets across the boundary while keeping the boundary itself intact.

One Ubiquiti-specific gotcha worth surfacing: their published AirPlay / Chromecast best-practices page states that “mDNS should be enabled for both your client network, and the network associated with your AirPlay/Chromecast devices” — meaning the proxy has to be turned on for the source VLAN andthe destination VLAN, in both directions. Enabling it only on one side produces a subtle one-way discovery failure that's hard to diagnose from the client.²³

Over-segmentation is a real failure mode

The single most important caveat in this article belongs to Troy Hunt — founder of Have I Been Pwned, one of the most-cited security researchers writing for general audiences. In his 2020 essay IoT Unravelled Part 3: Security, Hunt describes abandoning a stricter VLAN deployment in his own home, on his own time, after concluding the debugging cost outweighed the security gain: “you end up tracking down devices, ports and protocols and creating ever more complex firewall rules between networks.”³² He kept a separate IoT SSID for visible separation but folded the underlying VLAN traffic back together.

The lesson is not don't segment. The lesson is that complexity isn't security and that the upper-bound number of VLANs in a home is the number the household's technically-fluent person is willing to keep working through firmware updates, vendor app changes, and the occasional Matter or HomeKit protocol shift. The five VLANs proposed here are at the upper end of that practical limit; nine is too many.

VLANs without firewall rules

The number-one mistake in the named-engineer literature on UniFi VLANs: enabling VLAN tagging, creating new SSIDs for the new VLANs, then discovering months later that UniFi's default inter-VLAN posture is allow rather than deny. The aesthetic is segmentation; the behavior is a flat LAN with extra labels. Network Isolation on every non-Trusted VLAN, plus the four firewall rule categories from §07, are what turn the labels into separation.

IGMP snooping without a querier

IGMP snooping reduces multicast flooding on a switch by tracking which ports have multicast listeners. For that to work, the VLAN needs an active IGMP querier — usually the gateway, sometimes a manually configured switch. With snooping on but no querier, the membership tables age out and multicast traffic stops being delivered to listeners. Sonos drops off the network. AirPlay receivers disappear. Surveillance multicast streams stutter. The fix is either to enable a querier on the VLAN or to turn snooping off entirely — never one without the other.

The hairpin bottleneck

Inter-VLAN traffic is routed traffic. On a home gateway, all of it crosses one CPU. If the household's NAS lives on one VLAN and the household's laptops live on another, every file transfer between them goes through the gateway's routing function — which on most consumer hardware caps out somewhere below 10 Gbps and often well below 2.5 Gbps. The IMC 2024 measurement work on home networks documented the broader version of this finding: “for users with access links that exceed 800 Mbps, the user's home wireless network was the performance bottleneck 100% of the time.”¹⁶ On a wired network with VLAN segmentation, the bottleneck shifts to the routing path through the gateway. The mitigation is either a Layer 3 switch (so inter-VLAN routing happens at switch speed) or a deliberate decision to keep performance-critical pairs of devices on the same VLAN.

IPv6 link-local for Matter

Matter accessories over Wi-Fi require IPv6 link-local routing to work, and the Matter hub has to be able to reach the accessory at its link-local IPv6 address. UniFi's default IPv6 firewall does not permit this between VLANs without explicit configuration. Households running Matter accessories on an IoT VLAN with the hub on Trusted need to either keep them on the same VLAN or specifically enable IPv6 inter-VLAN routing for the relevant link-local prefixes.

• This is not the only correct structure. Four VLANs (folding cameras into IoT behind an outbound-drop rule) is a defensible alternative, and households with no AV-control system can reasonably collapse the AV / Media VLAN into Trusted. The recommendation here is for the installed-base case — homes with smart-home gear, AV / lighting control, and cameras — where five VLANs is the structure that handles all three cleanly.
• Vendor requirements take precedence over any best-practice template.Crestron's AV-over-IP requirements, Savant's flat-subnet position, Lutron's IGMP-snooping-off posture are non-optional in households that run those systems. The five-VLAN chassis is the starting point; the contents are dictated by what the household actually has installed.
• UniFi is the assumed gateway in the examples,because it's what most residential installations use and because its documentation is publicly accessible. The same patterns translate to pfSense, OPNsense, Fortinet, Cisco, MikroTik, and Aruba with different feature names — the principles (deny by default, stateful return, mDNS proxy, IGMP querier) are vendor-independent.
• The threat data does not prove that segmenting your home stops a state-sponsored attacker. Volt Typhoon and the Russian GRU Moobot operation compromised devices via default passwords on internet-reachable routers — not via lateral movement from one home VLAN to another.¹¹¹² Segmentation reduces the blast radius after a device is compromised; it doesn't prevent the initial compromise. The complementary controls — firmware hygiene, no internet-reachable admin interfaces, no default credentials — sit alongside it, not behind it.
• The percentages in §02 are not household-specific.60.6% default-accepting households (CHI 2025) and 29 attacks per day per smart home (Bitdefender 2025) are population statistics; the right way to read them is “the problem is widespread,” not “our home has been attacked 29 times today.” A specific home's exposure depends on what's on the network and how it's configured — exactly what an audit is for.
• VLAN hopping attacks are real but rare in practice for residential networks. The classic double-tagging and switch-spoofing attacks on 802.1Q require a malicious device physically attached to a trunk port — a threat model that fits enterprise edge networks better than homes. The standard mitigations (explicit native-VLAN tagging, switchport-mode-access on all user-facing ports, disabling dynamic trunking protocols) are good hygiene but not the most consequential thing to spend an audit hour on.

None of these caveats change the underlying picture. Segmentation is now the federal recommendation, the vendor recommendation, and the recommendation of every named residential network engineer who has published on the question. The five-VLAN structure handles a residential network with AV gear, IoT, and cameras without collapsing under its own complexity. The work is in the firewall rules and the multicast proxy configuration — which is exactly what the rest of this article was about.