Quick Summary (TL;DR): For a dependable smart home, put trusted phones and computers, Home Assistant/server services, untrusted IoT devices, NASAliExpress price storage and IP cameras into separate VLANs only where the security benefit justifies the complexity. Use one subnet and DHCP scope per VLAN, route between them through a firewall, deny unsolicited IoT/camera access to trusted devices, and allow only the specific flows that Home Assistant, Frigate, backup jobs and management actually need. VLANs do not automatically block traffic: isolation comes from router/firewall policy. Start with three networks (trusted, IoT and cameras) if five are too many; keep a wired recovery port and a configuration backup before changing switch trunks. mDNS reflection can restore discovery for some products, but it does not replace unicast firewall rules and does not fix every Matter, SSDP or vendor-specific discovery problem.
This is a design and configuration guide, not a hands-on benchmark or a claim that any particular router was tested. The example below uses private IPv4 ranges and common ports; replace them with the actual services and firmware in your home. The guiding principle is simple: make necessary traffic work, document it, and keep everything else closed.
The Recommended VLAN Layout at a Glance
| Zone / example VLAN | Example subnet and gateway | Typical devices | Default access policy |
|---|---|---|---|
| Trusted / 10 | 192.168.10.0/24 · .1 | Phones, laptops, administrator PC | May reach selected internal services; never a blanket pass to every camera |
| Services / 20 | 192.168.20.0/24 · .1 | Home Assistant, MQTT broker, Frigate, optional DNS | Receives only required connections; restricted management |
| IoT / 30 | 192.168.30.0/24 · .1 | ESPHome, plugs, TVs, Wi-Fi appliances | DNS/NTP plus explicit Home Assistant or MQTT flows; no trusted LAN access |
| Cameras / 40 | 192.168.40.0/24 · .1 | IP cameras, optional doorbell | Normally no internet; allow streams only to recorder |
| Storage / 50 | 192.168.50.0/24 · .1 | NASAliExpress price, backup server | SMB/NFS/backup only from approved clients; admin from trusted workstation |
| Guest / 60 (optional) | 192.168.60.0/24 · .1 | Visitors | Internet only; no access to private networks |
The VLAN numbers are labels, not security levels. A VLAN ID of 40 does not require subnet 192.168.40.0/24; using matching numbers simply reduces mistakes. Avoid copying these ranges if they overlap a VPN, remote site or existing LAN. Each VLAN normally needs a gateway interface, DHCP scope and suitable DNS/NTP service.
If you are running a small installation with fewer than a dozen devices, a trusted VLAN, a separate IoT VLAN and a camera VLAN can be sufficient. A dedicated services or storage VLAN becomes worthwhile when you need different rules for NASAliExpress price backups, server management or multiple virtual machines. A VLAN for every light bulb creates work without adding much meaningful protection.
What a VLAN Does—and What It Does Not
IEEE 802.1Q VLAN tagging separates Ethernet broadcast domains. A managed switch can place an ordinary wired device into one untagged access VLAN, while a tagged uplink can carry multiple VLANs to a router, another switch or a VLAN-aware wireless access point. Devices on different IP subnets normally need Layer 3 routing to talk to one another.
The firewall is the policy boundary. A router that routes all VLANs freely offers organisational separation, not meaningful lateral-movement protection. Conversely, a firewall rule that blocks the camera subnet from the trusted subnet can be useful even when all cameras share one switch. For stronger protection against a compromised device, use separate VLANs, restrict east–west traffic and keep network equipment management on an appropriately controlled network.
| Term | What it means | Common mistake |
|---|---|---|
| Access port | One untagged/native VLAN to an ordinary endpoint | Connecting an untagged NASAliExpress price to a tagged-only port |
| Trunk / tagged uplink | Carries multiple VLANs with 802.1Q tags | Forgetting to allow the camera VLAN on an upstream link |
| Native / PVID | Where untagged frames land on a port | Different native VLANs at opposite ends of a link |
| Inter-VLAN routing | Router or L3 switch forwards packets between subnets | Assuming different VLANs are automatically firewalled |
| Client isolation | AP feature that restricts Wi-Fi client-to-client traffic | Confusing it with inter-VLAN filtering |
| mDNS proxy/reflector | Re-advertises selected multicast DNS services across segments | Assuming it opens the required application ports |
A switch with only unmanaged Ethernet ports cannot perform the access/trunk assignments required here. A smart/managed switch and a router capable of VLAN interfaces and firewall rules are the minimum. Your access points must also support assigning different SSIDs to tagged VLANs if you want multiple Wi-Fi zones.
Choose Where to Put Home Assistant
Preferred default: put Home Assistant on the services VLAN, keep it at a stable DHCP reservation or static address, and let it initiate connections to the IoT subnet. This makes the security policy easier to audit than giving Home Assistant interfaces in every VLAN. It also avoids bridging the networks accidentally through a multihomed host.
There are exceptions. Some local-discovery integrations work best on the same Layer 2 segment as their devices. Bluetooth, USB Zigbee/Thread coordinators and certain Matter deployments have separate transport constraints; moving the Home Assistant host to another VLAN will not be cured merely by opening TCP ports. If one integration absolutely requires same-subnet multicast, consider keeping those particular devices with Home Assistant rather than weakening the policy for every IoT device.
Home Assistant uses Zeroconf/mDNS, SSDP and DHCP-based discovery for different integrations. Its Settings → System → Network page controls the interfaces used for network discovery, and its Zeroconf and SSDP browsers help diagnose missing advertisements. Home Assistant documents that Google Cast discovery across subnets is not generally supported automatically; a reflector or known-host configuration may help in specific cases, but do not promise universal cross-VLAN discovery.
For Home Assistant hosted in Proxmox, decide whether the virtual NIC is connected to a single VLAN-aware bridge with a VLAN tag set on the VM, or to an access-port-style bridge on a dedicated VLAN. Do not tag the VM and treat the switch port as a different untagged VLAN without understanding where the tags are inserted.
Place NAS Storage Behind a More Selective Policy
A NASAliExpress price usually has a higher concentration of valuable data than a light bulb or a camera. Give it a stable address, keep management restricted to a trusted administrator device and permit SMB, NFS or backup protocols only from machines that genuinely need them. If a NAS also hosts Home Assistant, Frigate or Docker containers, it may be simpler to keep those services on the same physical host but assign carefully managed virtual interfaces or service-level firewall restrictions; multiple NICs are not a substitute for sound routing.
For example, a family laptop might need SMB access to a NAS share while an ESPHome temperature sensor needs none. A Frigate recorder might need a dedicated recording share; the cameras themselves should not need SMB credentials or direct NAS access. Backup traffic is directional: the backup agent may initiate from NAS to backup server, or the backup server may pull from the NAS. Open the actual direction, not both by default.
Do not expose a NAS management page to the guest or camera VLAN. Avoid exposing SMB (TCP 445) to the internet. NAS permissions, snapshots, encryption and offline backups still matter: a VLAN cannot prevent deletion by an authorised but compromised account.
A Practical Firewall Rule Matrix
The table is an initial allow-list, not a universal firewall configuration. Firewall rule syntax and state tracking differ by product. On a stateful firewall, allow the connection initiator and permit established/related replies; do not add a second broad reverse rule merely to make responses work. Make rules as narrow as possible using source addresses, destination addresses and the actual transport protocol.
| Initiator → destination | Service / typical port | Suggested policy | Why / caveat |
|---|---|---|---|
| Trusted admin PC → gateway, APs, switches | HTTPS/SSH as configured | Allow selected admin IP only | Protect network configuration |
| Trusted devices → Home Assistant | TCP 8123 (default) | Allow selected clients | Dashboard/API; remote access separately |
| Home Assistant → ESPHome node | TCP 6053 (default) | Allow HA → named IoT hosts | ESPHome native API; outbound API modes may differ |
| IoT clients → MQTT broker | TCP 1883 or TLS 8883 if configured | Allow IoT → broker only | Authentication and broker ACLs still required |
| Home Assistant → local IoT device | Vendor-specific TCP/UDP | Allow by host/integration | Shelly, WLED and other APIs vary |
| Frigate → camera | TCP 554 RTSP when used | Allow recorder → camera IPs | RTSP path, HTTP/ONVIF ports vary |
| Trusted client → NAS | TCP 445 SMB if needed | Allow approved clients | Do not allow entire IoT subnet |
| Home Assistant / backup host → NAS | Actual backup protocol/port | Allow specific initiators | NFS, SSH, rsync and SMB differ |
| All internal zones → resolver/NTP | UDP/TCP 53; UDP 123 | Allow only designated services | May need router-local exceptions |
| IoT, cameras → trusted/storage networks | All others | Deny and log selectively | Protect valuable devices and data |
| Cameras → internet | All unless required | Deny by default | Check time sync and legitimate updates first |
Port 6053 is the conventional ESPHome native API default, not a blanket requirement for all future ESPHome modes; check the node configuration. Frigate documents TCP 8971 for its authenticated interface, TCP 5000 as an internal unauthenticated interface that should be tightly restricted, and TCP 8554 for RTSP restreams. Those are Frigate host ports, not automatically the ports of your cameras. Never publish the unauthenticated interface broadly.
Be precise about DNS and time. If the firewall/router answers DNS or NTP on each VLAN gateway address, the allow rules may target that interface instead of a central services subnet. If a camera needs an NTP server to maintain accurate recording timestamps, allow only that destination. For devices with cloud-dependent features, test whether local-only operation is acceptable before denying all internet access.
The Safest Order for Firewall Rules
- Back up the router, switch and access-point configuration, then document the current management IPs and uplink port assignments.
- Reserve a wired recovery port in the trusted management network. Keep a laptop and console access method available.
- Create VLAN interfaces, DHCP scopes and DNS first. Test that a client in each VLAN gets the expected IP, gateway and resolver.
- Confirm basic routing while access is temporarily controlled, then add specific allow rules for required services.
- Add explicit denies for unwanted inter-VLAN paths. If the firewall uses a default-deny policy, do not add unnecessary duplicate denies except for logging/clarity.
- Move one non-critical device per zone and test it before migrating cameras, storage or automations.
- Review firewall logs and remove temporary broad allow rules. Export the working configuration and record a rollback plan.
Avoid editing the trunk carrying your only management connection without an alternative way back in. The most common self-inflicted outage is not a subtle multicast issue; it is a native VLAN or allowed-VLAN mismatch that cuts off DHCP and the controller.
mDNS, SSDP and Broadcast: Why Discovery Breaks
mDNS/Zeroconf normally uses UDP 5353 to multicast address 224.0.0.251 on IPv4 (and ff02::fb on IPv6). It is designed for the local link; ordinary routing does not forward it between VLANs. A gateway mDNS proxy or reflector can selectively repeat service advertisements. It still requires the destination application port to be permitted by the firewall.
SSDP commonly uses UDP 1900 with multicast 239.255.255.250 for UPnP discovery. An mDNS reflector does not automatically forward SSDP. Some TVs, audio systems and DLNA devices use SSDP, proprietary broadcast, unicast control or a combination. Avoid a catch-all multicast relay unless you understand what it exposes.
| Discovery method | Common traffic | Typical consumers | Cross-VLAN approach |
|---|---|---|---|
| mDNS / DNS-SD | UDP 5353, 224.0.0.251 | HomeKit, Cast, printers, some ESPHome discovery | Selective mDNS proxy; allow service traffic separately |
| SSDP / UPnP | UDP 1900, 239.255.255.250 | TVs, receivers, media renderers | Per-device integration or carefully scoped SSDP relay |
| Direct IP / DNS | Normal unicast to known host | ESPHome API, NAS SMB, RTSP cameras | DHCP reservations + exact firewall allow rules |
| MQTT | Broker TCP listener (often 1883/8883) | Sensors, Tasmota, Frigate events | No multicast required once broker address is known |
| Matter over Wi-Fi / Thread | IPv6 plus mDNS and other protocol needs | Matter controllers and endpoints | Prefer simple topology; verify routable IPv6 and multicast |
Do not assume that a successful mDNS query proves the application works. You can see a service name in the Zeroconf browser while its actual TCP connection is blocked. The reverse is also possible: a manually configured integration can work by IP even when discovery fails.
How to Configure mDNS on UniFi, Omada, OPNsense and pfSense
| Platform | Documented feature | Important constraint |
|---|---|---|
| UniFi gateway | mDNS Proxy with Auto, Off and Custom modes | Requires supported UniFi Gateway/Cloud Gateway; custom mode can restrict services and VLAN scope |
| TP-Link Omada | mDNS Repeater rules in controller | Feature availability depends on gateway/AP, controller and firmware versions |
| OPNsense | os-mdns-repeater plugin | Documentation states at least two and no more than five selected interfaces |
| pfSense | Avahi package for mDNS reflection; UDP Broadcast Relay package | Separate relay for SSDP if genuinely needed; firewall rules remain necessary |
On UniFi, use a Custom mDNS proxy configuration where possible, selecting only the VLANs and service types you intend to share. UniFi documentation notes that Auto mode rebroadcasts common service types, while Custom provides more control. Avoid treating a convenient default as a least-privilege policy.
On Omada, the controller documentation places mDNS settings under Settings → Services → mDNS and supports defining a service network and client network. Firmware support is not identical across all gateways and access points. Confirm your hardware/firmware combination before buying a switch or gateway specifically for this feature.
OPNsense documents installation of the os-mdns-repeater plugin from its plugins view and selection of participating interfaces under Services. On pfSense, Netgate documents Avahi for service discovery and mDNS reflection; its UDP Broadcast Relay package can handle selected UDP broadcasts such as SSDP but does not automatically add the necessary firewall permissions.
A reflector is a convenience and an exposure decision: devices on another VLAN can now discover services you choose to advertise. Start with the smallest service and VLAN scope. Test actual connectivity and review the gateway logs after enabling it.
Wi-Fi SSIDs, VLAN Tags and Switch Port Profiles
Most homes need no more than two or three SSIDs: trusted, IoT and optionally guest. IP cameras are often better wired; if they use Wi-Fi, a camera SSID mapped to the camera VLAN can be useful. Each SSID needs the intended VLAN assignment, security settings and a DHCP scope. A new SSID with the same underlying LAN is not segmentation.
The AP uplink is normally a trunk/tagged port carrying the required SSID VLANs. Its management network may be untagged/native or explicitly tagged, depending on your platform. A desktop PC or ordinary camera plugged into a switch is normally connected to an access port with a single untagged VLAN. On a multi-switch path, every intermediate trunk must permit the required tags.
If a client associates with Wi-Fi but gets a self-assigned 169.254.x.x address, suspect a VLAN-to-SSID mismatch, missing DHCP scope or blocked trunk before blaming Home Assistant. If the device gets the correct address but cannot reach the gateway, check the access port PVID and subnet mask. If it can reach the gateway but not a service, check routing, firewall policy and DNS separately.
Do IoT Devices Need Internet Access?
Some devices work entirely locally; others need a vendor cloud for initial provisioning, remote functions, firmware updates or voice-assistant features. A blanket “no internet for IoT” rule may improve security but can silently disable those functions. Classify devices before writing the policy: local-only, occasional update access, or cloud-dependent.
| Device category | Suggested starting policy | What to test |
|---|---|---|
| ESPHome nodes using native API | Local Home Assistant connection, DNS/NTP as required; internet usually unnecessary | OTA, API reconnects, clock sync and recovery |
| MQTT smart plug | Broker access plus DNS/NTP if needed | Command and telemetry flow after reboot |
| Cloud-dependent appliance | Restricted outbound access where practical | Provisioning, status, updates, failure when WAN down |
| IP camera with local RTSP | No internet; allow recorder and NTP | Streaming, night mode, firmware update method |
| Smart TV / Cast speaker | Selected outbound services; carefully scoped discovery | Casting, remote controls and app pairing |
DNS filtering is not a substitute for firewall policy: a device can connect to a hard-coded IP. Equally, blocking every outbound connection does not prevent a compromised device from attacking another host on its own VLAN. For high-risk devices, consider wireless client isolation or switch port isolation where it does not break their intended local workflows.
Frigate and IP Cameras: Keep Video Local
A useful camera design is cameras VLAN → Frigate recorder in services VLAN → NAS storage in storage VLAN. Cameras send or serve video only to the recorder; trusted clients view Frigate rather than browsing camera administration pages. Many RTSP cameras expose TCP 554, but actual ports and URLs are model-specific. ONVIF discovery and control may require additional services; confirm them rather than opening the camera subnet wholesale.
For a pull-based RTSP configuration, the Frigate host initiates the stream connection to the camera. The firewall therefore normally needs Frigate → camera access, not unrestricted camera → services access. If a camera pushes events or video, the direction changes. Use separate camera accounts with the least privileges available and avoid putting credentials into publicly readable logs.
Frigate documents its authenticated interface on port 8971, internal unauthenticated interface on 5000, RTSP restream on 8554, and WebRTC on 8555 TCP/UDP. Expose only the interface and streaming methods actually used. If Frigate records to NAS, choose the real storage protocol and allow the recorder to reach the NAS share; cameras should not mount it.
Example traffic (illustrative, not a router configuration):
192.168.20.30 Frigate recorder
192.168.40.21 Front-door camera
192.168.50.10 NAS
ALLOW 20.30 -> 40.21 TCP/554 # RTSP if used by camera
ALLOW 20.30 -> 50.10 TCP/445 # only if SMB recording path is used
ALLOW 10.25 -> 20.30 TCP/8971 # trusted viewing client
DENY 40.0/24 -> 10.0/24 # no camera to trusted LAN
DENY 40.0/24 -> WAN # camera cloud blocked by choice
# Use your firewall syntax, real IPs and actual service ports.Do not copy this pseudo-policy directly into a firewall. The prefixes are abbreviated for readability, and a camera may need additional control or discovery traffic. If the recorder is itself the NAS, the recording flow stays inside that host and should not be modelled as a separate routed connection.
ESPHome, MQTT and Bluetooth Proxies Across VLANs
An ESPHome node commonly advertises itself using mDNS and accepts a native API connection on TCP 6053. With stable IP addresses or DHCP reservations, you can often add it to Home Assistant manually and allow Home Assistant to connect to the node without cross-VLAN mDNS. ESPHome configuration, encryption and API options still determine the actual connection behaviour; recent ESPHome versions also document optional outgoing connection modes, so verify the deployment rather than hard-coding a single assumption.
MQTT is often simpler across VLANs because devices connect directly to a broker address. Put the broker on the services VLAN, give it a stable DNS name or IP, allow only the clients that need the broker port, require authentication and use topic-level ACLs. If the broker uses TLS, use the configured listener; 8883 is a common convention, not a guarantee.
An ESP32 Bluetooth proxy bridges Bluetooth radio coverage to Home Assistant over IP. The proxy must be within Bluetooth range of sensors and have an allowed IP path to Home Assistant; it does not need to share the sensors’ Wi-Fi VLAN because Bluetooth devices are not Wi-Fi clients. The same principle applies to a network-attached Zigbee or Thread coordinator: consider its IP transport separately from its radio mesh.
For a practical wired proxy project, see ESP32 W5500 Ethernet Bluetooth Proxy for Home Assistant. For Proxmox radio coordinator decisions, see USB Passthrough vs Network Zigbee and Thread Adapters for Proxmox.
Matter and Thread Need Special Care
Matter over Wi-Fi and Thread depends on IPv6 and local multicast behaviour. Home Assistant’s Matter documentation explicitly emphasises working IPv6 multicast connectivity and recommends keeping the network simple during initial setup. An mDNS reflector alone is not a guarantee that Matter works across isolated subnets: link-local IPv6 addresses cannot be routed to another VLAN, and Thread border-router behaviour and commissioning paths add more requirements.
The conservative deployment is to get Matter commissioning and normal operation working on a straightforward LAN before adding segmentation. Keep the phone used for commissioning, the Matter controller, the relevant border router and target devices in a topology known to support the required IPv6 communication. If you later separate them, confirm routable IPv6 addressing, multicast and device-specific requirements end to end.
A VLAN design that works perfectly for ordinary IPv4 REST APIs can still fail for Matter. Do not disable IPv6 merely to simplify firewall rules. Review IPv6 policies separately; an IPv4-only block list does not provide equivalent isolation for IPv6 traffic.
Example Addressing and DHCP Reservations
| Example device | Address | Why reserve it |
|---|---|---|
| Gateway services interface | 192.168.20.1 | Predictable routing and DNS target |
| Home Assistant | 192.168.20.10 | Stable integration endpoint |
| MQTT broker | 192.168.20.15 | Clients connect without discovery |
| Frigate | 192.168.20.30 | Narrow camera firewall allow rules |
| ESPHome temperature node | 192.168.30.21 | Manual integration by IP if mDNS fails |
| IP camera front door | 192.168.40.21 | RTSP and admin rules by device |
| NAS | 192.168.50.10 | Backup and SMB allow-list target |
Use DHCP reservations rather than manually setting a static address on every appliance where practical. This keeps gateway, DNS and lease management centralised. Reserve infrastructure addresses outside the dynamic pool or make an explicit reservation in the pool according to the router’s behaviour. Maintain a simple inventory with MAC address, physical location, VLAN, IP, firmware and service owner.
Check the Design Before Buying Hardware
You do not need a 10GbE core just to isolate IoT devices. A gigabit managed switch and VLAN-capable gateway can be enough for low-bandwidth sensors, cameras and normal home automation. Higher speeds matter for NAS file transfers, video editing or multiple high-bitrate streams; that is a separate throughput decision.
| Component | Minimum feature to check | When to upgrade |
|---|---|---|
| Router / firewall | 802.1Q VLAN interfaces, stateful inter-VLAN policy, DHCP/DNS | More CPU when IDS/IPS, VPN or fast inter-VLAN routing is needed |
| Managed switch | Tagged trunks, untagged access ports, PVID controls | 2.5/10GbE for NAS/server traffic; PoE for APs/cameras |
| Wireless access point | Multiple SSIDs with VLAN mapping | Wi-Fi coverage, roaming and supported clients—not merely more SSIDs |
| PoE budget | Total watts plus per-port standard | Cameras, APs and startup peaks exceed existing budget |
| UPS | Router, switch, AP and recorder power continuity | Longer runtime and graceful NAS shutdown |
For firewall hardware selection, compare router hardware for OPNsense and pfSense. For switch options, see 2.5GbE switches for a smart home and home lab. For camera recording capacity, see Frigate hardware for 4, 8 or 16 cameras. These are hardware-selection guides; this article remains focused on segmentation and application flows.
Troubleshooting: Work from Layer 2 Upwards
| Symptom | Most likely checks | First useful test |
|---|---|---|
| Wi-Fi connects but no IPv4 lease | SSID VLAN mapping, trunk allowed list, DHCP scope | Compare client VLAN and DHCP server logs |
| Correct IP but gateway unreachable | Access-port PVID, tagging, subnet mask | Ping VLAN gateway from affected device |
| Gateway reachable, service unavailable | Firewall source/destination, service listener, host firewall | Connect directly to known IP and port |
| HA device works by IP but not discovered | mDNS/SSDP boundary, selected HA interface | Use HA Zeroconf or SSDP Browser |
| Cast/TV missing across VLANs | mDNS vs SSDP distinction, vendor protocols | Identify discovery type before relaying |
| Frigate camera offline | RTSP URL, credentials, camera port, stream direction | Test RTSP from recorder host |
| NAS visible but shares fail | SMB/NFS rule, credentials, name resolution | Connect to NAS by IP from approved client |
| Matter pairing fails | IPv6 multicast, link-local scope, border router | Test with simple same-subnet setup |
| Network equipment disappears | Management/native VLAN mismatch on trunk | Use wired recovery port or console |
Useful checks on a Linux diagnostic machine include ip addr, ip route, ping, dig and nc. A packet capture on the relevant VLAN interface can show whether multicast queries or TCP SYN packets arrive. On a managed switch, inspect the MAC address table and VLAN membership. Use firewall live logs for the exact source and destination pair rather than temporarily allowing everything.
Illustrative Linux diagnostics (replace the addresses):
ip -br address
ip route
ping -c 3 192.168.20.1
getent hosts homeassistant.local
nc -vz 192.168.20.10 8123
nc -vz 192.168.30.21 6053
# On an authorised diagnostic host with tcpdump installed:
sudo tcpdump -ni <interface> "udp port 5353 or udp port 1900"
# Do not infer security from ping alone: ICMP may be blocked.If a host is unreachable by IP, stop debugging DNS. If IP connectivity works but a hostname fails, inspect DNS and mDNS. If TCP connects but the application still fails, look at authentication, protocol negotiation and the application’s own logs. This layered method prevents random firewall changes from obscuring the original problem.
A Safe Migration Plan for an Existing Smart Home
Start with a spreadsheet of devices and dependencies, not with firewall rules. Identify which phones control which speakers, which cameras Frigate pulls from, which ESPHome nodes use native API or MQTT, where DNS lives and which host performs NAS backups. Then group devices by trust and necessary access.
- Export router/switch/AP settings and record working management addresses.
- Build the new VLANs and DHCP scopes without migrating critical devices.
- Configure and test a trusted wired port, one IoT test SSID and one camera access port.
- Move a non-critical ESPHome node; add it by reserved IP if discovery fails and verify state changes.
- Move one camera and test Frigate live view, recording, time sync and reboot recovery.
- Move the NAS or service hosts only after their firewall dependencies and backups are documented.
- Apply restrictive rules, review logs over several days and retain a tested rollback procedure.
For the first migration, resist the temptation to put Home Assistant, NAS, cameras, smart TVs and Matter devices into separate VLANs in one evening. A staged migration gives you a clear cause when something stops working. Keep an offline copy of the gateway configuration and a way to access it without relying on Home Assistant.
Common Mistakes Worth Avoiding
- “Different VLANs means secure.” Not without routed firewall restrictions and device-level permissions.
- “Allow established traffic in both directions.” Stateful return traffic is normally handled by the firewall; do not create blanket reverse allows.
- “Enable mDNS everywhere.” Reflect only the services and VLANs that need discovery; it may reveal otherwise hidden devices.
- “Port 554 is every camera’s port.” Verify the actual RTSP, HTTP, HTTPS and ONVIF endpoints.
- “A NAS needs internet access from every network.” Permit only required clients and management paths.
- “Disabling IPv6 makes IoT safer.” It can break Matter and does not replace an IPv6 firewall policy.
- “An IoT SSID is automatically isolated.” Check its VLAN and gateway policy.
- “All network gear must be one brand.” Standards-based VLAN tagging works across vendors, but discovery/controller conveniences vary.
Frequently Asked Questions
Should Home Assistant and IoT devices be on the same VLAN?
Not necessarily. Home Assistant can control many devices across a routed firewall using stable IP addresses and explicit rules. Some multicast-dependent integrations, especially during commissioning, are easier on the same subnet. If reliability suffers, isolate higher-risk cameras and guest devices first rather than forcing every low-risk device into a complicated topology.
Can I put the NAS and Home Assistant on the same VLAN?
Yes, especially in a small home lab. A dedicated storage VLAN is useful when you need tighter controls on SMB, NFS, backup traffic and NAS management. Separate subnets do not replace share permissions, credentials or backups.
Will mDNS forwarding make Chromecast and Matter work?
It can help some mDNS-based discovery, but it is not a universal fix. Chromecast and other media devices can have additional protocol requirements, while Matter depends on IPv6 multicast and sometimes link-local addressing. Test each integration and do not broadly forward multicast without a clear need.
Do I need a managed switch for VLANs?
For multiple wired VLANs or tagged AP uplinks, generally yes. A VLAN-aware router alone can separate its own physical ports or Wi-Fi networks in some designs, but a conventional unmanaged switch cannot selectively assign tagged and untagged VLAN membership to downstream ports.
What is the simplest secure setup for a beginner?
Use a trusted LAN for computers and Home Assistant, an IoT VLAN for less-trusted Wi-Fi devices, and a separate camera VLAN with no internet by default. Add precise allowances for the recorder, MQTT broker and ESPHome nodes. Introduce a separate NAS/services VLAN only when the additional policy is worth maintaining.
Final Recommendation
For most technically minded households, a three- to five-zone design with a stateful firewall and explicit application flows is the sensible balance. Keep the trusted network easy to manage, protect the NAS and camera recorder, isolate low-trust devices, and handle discovery as a separate requirement rather than weakening every firewall rule. Test Home Assistant automations and camera recording after every migration, and keep a reliable wired route back to the network controller.
The best VLAN design is not the one with the most VLAN IDs. It is the one where you can explain each allowed connection, restore the network after a mistake and maintain it six months later without guesswork.
Related ESP32 and Home Lab Guides
- Best Router Hardware for OPNsense and pfSense
- Best 2.5GbE Switches for a Smart Home and Home Lab
- Best Frigate Hardware for 4, 8 or 16 IP Cameras
- ESP32 W5500 Ethernet Bluetooth Proxy for Home Assistant
- USB Passthrough vs Network Zigbee and Thread Adapters for Proxmox
Manufacturer and Project Documentation
- Home Assistant — Network Configuration
- Home Assistant — Zeroconf discovery and browser
- Home Assistant — SSDP discovery
- Home Assistant — Google Cast network limitations
- Home Assistant — Matter networking requirements
- ESPHome — Native API
- Frigate — Installation and port reference
- Ubiquiti — UniFi Gateway mDNS Proxy
- Ubiquiti — Switch VLAN assignment
- TP-Link — Omada mDNS Repeater configuration
- OPNsense — Multicast DNS Proxy
- Netgate — pfSense Avahi package
- Netgate — UDP Broadcast Relay