A cheap Wi-Fi plug runs firmware you cannot audit, and many of them talk to a cloud you do not control. On a flat home network that plug sits next to your laptop, your NAS and your phone. Moving smart devices to their own VLAN means a compromised gadget can reach Home Assistant and nothing else.
The catch is that a lot of smart home convenience depends on everything sharing one network. Automatic discovery stops working, some devices appear offline, and Matter can fail in confusing ways. Most of that can be avoided if you plan the split before you move the first device.
What the separation breaks
Almost every problem comes down to one protocol: mDNS (multicast DNS, also called Zeroconf or Bonjour). Devices announce themselves with multicast packets to 224.0.0.251 on UDP port 5353, and those packets do not leave their own subnet.
- Home Assistant discovery. The Google Cast documentation is blunt: Cast devices can only be discovered automatically on the same subnet as Home Assistant, "because mDNS packets are not routed across subnets". Discovery across subnets is "not recommended and not supported". Many other integrations rely on the same Zeroconf mechanism.
- ESPHome Device Builder. ESPHome uses mDNS to resolve
.localnames and to track whether a device is online. According to the ESPHome FAQ, a server and devices on different subnets or VLANs break this. - Matter. Home Assistant's Matter documentation says the protocol relies on local IPv6 and mDNS travelling freely, and "may not integrate well with enterprise networking solutions like VLANs, Multicast filtering, and (malfunctioning) IGMP snooping".
Ordinary unicast traffic, such as Home Assistant connecting to an ESPHome node by IP or a plug connecting to an MQTT broker, crosses a router without trouble as long as the firewall allows it.
Decide what goes where
Before you touch the router, sort devices into groups:
- IoT VLAN: Wi-Fi plugs, relays, ESPHome nodes, bulbs and other devices that only need to talk to Home Assistant (and possibly their cloud).
- Same network as Home Assistant: Matter devices that use Wi-Fi and Thread border routers. Home Assistant's Matter documentation asks for them to be on the same VLAN as Home Assistant, so do not move them unless Home Assistant moves with them.
- Zigbee and Z-Wave devices do not use IP at all, so a VLAN does not affect them. Only the coordinator matters, and only if it is a network coordinator (Ethernet or Wi-Fi) rather than a USB stick. Treat it like any other IoT device that Home Assistant must reach.
- Main network: computers, phones, NAS, anything with personal data.
Two layouts that work
Layout A: Home Assistant on the main network, the router in between. Every packet between the IoT VLAN and Home Assistant passes through the router's firewall, so you decide exactly what is allowed. The price is discovery: you either forward mDNS between the networks or add devices by IP address.
Layout B: Home Assistant with an interface in both networks. Home Assistant sees the IoT VLAN directly, so mDNS discovery works there without any forwarding. On Home Assistant OS you create the extra interface with the ha network vlan command. Home Assistant's developer documentation lists VLANs among the settings available only through the ha network CLI. Check the interface name with ha network info first, then for example:
ha network vlan eth0 20 --ipv4-method static --ipv4-address 192.168.20.2/24 --ipv6-method disabled
If Home Assistant runs in a virtual machine, add a second virtual network card in the hypervisor instead. A long-running VLAN tutorial on the Home Assistant forum recommends setting a gateway on only one interface, the main one, to avoid routing problems.
Then check the network settings in Home Assistant under Settings > System > Network. By default the Network integration detects one interface automatically, the one the system uses to reach the mDNS address 224.0.0.251, which is usually the default interface. Zeroconf only broadcasts on the interfaces chosen there, so disable automatic detection and select both adapters.
The drawback of layout B is real: traffic between IoT devices and Home Assistant no longer passes through the router, so the firewall cannot filter it. Every device on the IoT VLAN can reach every port Home Assistant listens on, including the web interface. If isolation is the main goal, layout A is the stricter choice. Layout B mostly suits setups that depend heavily on discovery.
The Wi-Fi network for devices
Create a separate SSID mapped to the IoT VLAN. A few details save trouble later:
- 2.4 GHz. The ESP8266 and the original ESP32 only work on 2.4 GHz. In ESPHome, the
band_modeoption for 5 GHz exists only on the ESP32-C5. - WPA2, or WPA2/WPA3 mixed mode. ESPHome's
min_auth_modedefaults to WPA2, and WPA3-only mode is available only on the ESP32. A WPA3-only SSID would lock out every ESP8266. - Client isolation. Many access points can block wireless clients from talking to each other. It is a good idea on an IoT network, but after enabling it, check that Home Assistant can still reach every device, especially when Home Assistant itself is connected to the same SSID.
Firewall rules for layout A
The order and syntax depend on the router, but the logic is the same everywhere. Firewalls go through rules from the top, so put the allow rules before the general block.
| Rule | From | To | What |
|---|---|---|---|
| 1 | any | any | allow established and related traffic (replies) |
| 2 | Home Assistant | IoT VLAN | allow (control, ESPHome API, OTA updates) |
| 3 | IoT VLAN | Home Assistant | allow only the services devices start themselves, e.g. MQTT |
| 4 | IoT VLAN | router | allow DHCP and DNS |
| 5 | IoT VLAN | main network | block |
| 6 | IoT VLAN | internet | allow or block per device |
Ports worth knowing:
- ESPHome native API: TCP 6053 on the device. Home Assistant opens the connection, so rule 2 covers it and the device needs no rule toward Home Assistant.
- ESPHome OTA updates: TCP 3232 on the ESP32 and 8266 on the ESP8266 (defaults from the ESPHome documentation). If Device Builder runs as a Home Assistant add-on, rule 2 covers this too. If you compile on a laptop in the main network, allow that laptop to reach the IoT VLAN on these ports.
- MQTT: TCP 1883, or 8883 with TLS. These are the Mosquitto add-on's default ports. Here the device opens the connection, so it needs rule 3.
Rule 6 is where you gain the most and where you can lose control of devices. An ESPHome node needs nothing from the internet if it gets the time from Home Assistant: the homeassistant time platform synchronises the clock over the native API, and ESPHome's documentation calls it the preferred way to get time. A device that depends on its vendor's cloud will stop working the moment you cut it off, so block the internet per device, not for the whole VLAN at once, and test each one.
Bringing discovery back
You have two options, and you can mix them.
Forward mDNS between the networks. The ESPHome FAQ describes this for routers with Avahi, such as OpenWrt or pfSense: enable Avahi on both subnets and allow UDP traffic from the device subnet to 224.0.0.251 on port 5353. In Avahi's configuration file the option is enable-reflector=yes in the [reflector] section. Avahi's manual adds a warning: do not run more than one reflector between the same networks, or they will bounce mDNS packets back and forth. Many routers offer the same thing as a single switch named mDNS or multicast DNS.
Skip discovery and use fixed addresses. Give each device a DHCP reservation or a static IP. In ESPHome that is manual_ip: under wifi:, and use_address: overrides the address used to connect to the device. Then add the ESPHome integration in Settings > Devices & services with the IP address instead of waiting for discovery. ESPHome's FAQ says Device Builder falls back to a periodic ping sweep, so a device stays visible as online as long as its address resolves some other way, for example as a literal IP. For Google Cast, the integration's options include a list of known hosts, which the documentation recommends together with static IPs when discovery does not work.
Fixed addresses are more work at the start, but they keep working when mDNS forwarding misbehaves after a router update.
What to keep out of the VLAN
Matter is the exception to almost everything above. Home Assistant's documentation gives a clear remedy for unreliable Matter: put Wi-Fi Matter devices and Thread border routers on the same VLAN as Home Assistant, and make sure IPv6 multicast reaches the Home Assistant host. IPv6 must also be enabled in Home Assistant (Settings > System > Network, IPv6 set to automatic or static), although you need neither an IPv6 internet connection nor a DHCPv6 server. If you want untrusted gadgets off your Wi-Fi altogether, Matter devices that use Thread are worth a look: they join the Thread mesh instead of your Wi-Fi and reach the rest of the network through the border routers.
Common problems
- An ESPHome device reboots every 15 minutes. The API component reboots the device when no client connects for
reboot_timeout, which defaults to 15 minutes. Usually the firewall is blocking Home Assistant from reaching the device on port 6053. - Device Builder shows devices as offline, but they work. mDNS does not cross the VLAN. Use fixed IPs or forward mDNS.
- Nothing new is discovered. Expected in layout A without mDNS forwarding. Add integrations by IP.
- Matter commissioning fails or devices drop off. Check that Matter devices and border routers are on Home Assistant's network, that IPv6 is enabled and that the network does not filter multicast.
- A device works in the vendor's app but not in Home Assistant, or the other way round. You probably blocked its internet access or the phone cannot reach the IoT VLAN. Decide which control path you want and adjust rules 2 and 6.