How-to · OpenWrt
OpenWrt VLANs for IoT: a separate network for smart devices
An IoT VLAN on OpenWrt is one extra network segment, carried over the same switch and radio as your main LAN, that holds the smart plugs, bulbs, cameras and ESP32 boards. You create it once on the bridge, firewall it so devices cannot reach your laptops, bind a Wi-Fi network to it, and then spend the rest of the afternoon solving the part nobody warns you about: discovery. Home Assistant finds devices by multicast, and multicast does not cross a router.
This guide covers the whole job on current OpenWrt — 25.12.6 is the stable release published 18 October 2026, with 24.10.8 still built for most devices — and it is honest about the step that has no clean answer.
What a VLAN buys you
A VLAN is a way to run more than one logical network over one physical switch and one access point. Devices on different VLANs behave as if they were plugged into separate routers: they cannot talk to each other unless a router forwards the traffic, and you decide per port and per protocol whether it does.
For a smart home that buys three things. First, a cheap bulb or an unpatched camera with a cloud account can no longer reach the machine holding your files. Second, broadcast traffic from fifty chatty devices stays off your main network. Third, you get a clean place to apply rules: the IoT segment reaches the internet, reaches Home Assistant on exactly the ports it needs, and reaches nothing else.
It does not buy you privacy from the manufacturer. A bulb that phones home still phones home; the VLAN only decides what it can reach inside your house. Blocking outbound traffic is a separate decision, made in the firewall, and many devices misbehave when you make it.
Before you touch anything: know your hardware target
OpenWrt's switch configuration is not one thing. Modern targets — mediatek/filogic and ramips/mt7621, which cover most current routers — use the DSA network stack, where ports appear as individual interfaces under a bridge. Older ath79 hardware still uses the swconfig-era model with a single switch device and a port map. The menu names, and the way tagged and untagged membership is expressed, differ between the two.
Check the device's own page before copying any configuration from a guide, including this one. That matters more than usual right now: OpenWrt's documentation wiki sits behind a JavaScript proof-of-work bot check (Anubis), so automated fetches get a challenge page instead of the article. Reading the wiki needs a normal browser. Everything below is written to be true across releases at the concept level; exact labels should be checked against the wiki and your device page on the day you do it.
Both current branches are worth knowing about, because a device page may describe one and your router may run the other. OpenWrt 25.12.6 shipped on 18 October 2026; 24.10.8 shipped on 26 July 2026. Official images for a specific device and release are listed in the OpenWrt firmware selector, and the per-release target indexes live under downloads.openwrt.org.
The plan, in numbers
Pick your addressing before you create anything. A simple scheme that stays readable:
| Segment | VLAN ID | Example subnet | Holds |
|---|---|---|---|
| Main LAN | 1 (untagged) | 192.168.1.0/24 | Laptops, phones, Home Assistant |
| IoT | 20 | 192.168.20.0/24 | Plugs, bulbs, cameras, ESPHome nodes |
| Guest | 30 | 192.168.30.0/24 | Visitors, internet only |
Keep Home Assistant on the main LAN and treat the IoT segment as the far side of a firewall. The alternative — moving Home Assistant onto the IoT VLAN — removes the routing problem for discovery but exposes the server to every compromised device on that segment, which is the thing you were trying to avoid.
Step 1: create the VLAN on the bridge
In DSA builds, the LAN ports are members of a bridge device. You add a new VLAN to that bridge, set the CPU port as tagged for it so the router's own network stack can see it, and set the physical ports you care about as either untagged (a device that does not speak VLANs, like a TV or a dumb switch) or tagged (a downstream managed switch or a second access point). Ports you leave out of the VLAN simply do not carry it.
The practical rule: a port that should belong entirely to the IoT network is untagged in VLAN 20 and removed from VLAN 1. A port feeding a second access point carries both VLANs tagged. Getting this wrong is the usual cause of a router that boots into an unreachable state, so make the change over a wired connection with a rollback timer set, and keep a copy of the config.
Step 2: give the VLAN an interface and a DHCP server
A VLAN with no interface is just a label on a wire. Create a new interface on top of the VLAN device, give it the gateway address for the subnet (192.168.20.1 in the example), and enable a DHCP server on it. Set the DHCP lease time long — twelve hours or a day — because IoT devices reconnecting every few minutes add nothing but noise.
This is also where you decide whether the segment gets IPv6. If you run Matter or Thread anywhere in the house, it should. Matter depends on IPv6, and a segment with IPv4 only will look healthy right up until commissioning fails.
Step 3: firewall zones, and the two rules that matter
OpenWrt's firewall works on zones, and a zone is usually one interface. Create an iot zone containing the new interface and set input and forward to reject, output to accept. Then add forwarding from IoT to WAN so devices can reach the internet, and leave IoT to LAN blocked.
Home Assistant still needs to reach devices, so add the narrow exception: a forwarding rule from LAN to IoT, restricted to the Home Assistant host address and to the ports you actually use. For ESPHome that is 6053 for the API and 80 for over-the-air updates; for a camera stream it is whatever the camera serves. The point of the exercise is that the rule names one source address, not the whole LAN.
Do not forget the return path. Forwarding from IoT to LAN is what most people block first, and it is also what breaks devices that call back to a local server. If something works until you enable the firewall and then stops, this is where to look.
Step 4: bind Wi-Fi to the IoT network
Wireless is a separate step from switching. Create a new wireless network, attach it to the IoT interface as its network, and give it its own SSID and passphrase. Most IoT devices are 2.4 GHz only, so put that SSID on the 2.4 GHz radio and, if your hardware allows it, leave it off 5 GHz entirely to stop devices from wandering.
Two habits worth keeping: give the IoT SSID a name that does not advertise what it is (an SSID called "IoT-VLAN" tells a passer-by which network to target), and disable WPA3-only modes on that SSID if older devices refuse to associate. WPA2/WPA3 mixed mode is the usual compromise.
Step 5: the discovery problem
This is where most people get stuck, and it is not an OpenWrt bug. Home Assistant's zeroconf integration — mDNS, Bonjour, Avahi — is enabled by default through default_config:. It is what populates the discovered list with HomeKit, ESPHome, Google Cast and Android TV devices. It works by listening to multicast announcements on the interfaces the Network integration tells it to use, and it enables IPv6 automatically when a selected interface has an IPv6 address.
Multicast does not route. The moment your bulbs are on VLAN 20 and Home Assistant is on VLAN 1, the announcements never arrive. The same applies to names: a default Home Assistant OS install answers at http://homeassistant.local:8123, and .local is a private mDNS suffix that only resolves where multicast works.
You have two honest options.
Reflect or forward mDNS. Run a reflector that listens on the IoT interface and re-announces on the main LAN, or forward the mDNS group between zones. This keeps vendor apps and automatic discovery working, at the cost of one more moving part and more multicast noise on the main LAN.
Stop depending on discovery. Give every device a fixed address and add it by IP. ESPHome's own documentation recommends a static address through manual_ip: — with static_ip, gateway and subnet — saying it "can dramatically improve connection times". It also removes the dependency on DHCP and on .local resolution across subnets. The domain option controls the hostname suffix used for uploads and defaults to .local; use_address overrides the address used to reach the device, which is what you need after it has moved to another subnet or its address changed. For ESPHome nodes this is the better answer, because you are editing the configuration file anyway.
Whichever you choose, confirm it with the Zeroconf Browser at Settings, System, Network, Zeroconf Browser. If devices appear there, discovery traffic is reaching Home Assistant. If the browser is empty, nothing downstream will work.
Step 6: Matter and Thread need more than routing
Matter in Home Assistant runs as a separate Matter Server app that Home Assistant talks to over a WebSocket; the controller then speaks to devices over the local Wi-Fi or Thread network. Thread devices need a border router, and commissioning starts over Bluetooth before the device joins the Thread mesh. A border router has to sit on the same layer-2 segment as the devices, or have working multicast and IPv6 routing to them.
The consequence is blunt: a VLAN design that forwards only IPv4 unicast will break Matter commissioning while every ping test passes. If Matter matters to you, either place the Thread border router and the devices on the same segment, or verify multicast and IPv6 across the boundary before you start moving devices around.
Gotchas worth knowing before you start
- Locking yourself out. Change one thing at a time, and apply switch changes from a wired port you are not reconfiguring.
- DSA versus swconfig instructions. Guides written for a 2019 Archer do not describe a 2026 filogic router. Check the device page's switch and driver notes.
- Zigbee and Z-Wave are unaffected. A coordinator is a USB radio on the Home Assistant host, not a network device. Segmenting Wi-Fi changes nothing for them. See Zigbee hub for Home Assistant if you are weighing radios.
- Printers, TVs and speakers. Cloud-dependent consumer gear often needs to see the phone or app that set it up. Expect a few devices that only work when they share a subnet with the controller app.
- Guest network is not a VLAN. It gives isolation, but not the per-port control that lets Home Assistant talk to devices while nothing else does.
Routers with official OpenWrt builds
VLAN work is easier on hardware with a current official image and DSA-era switch configuration. From the official download index, these all have builds for both 25.12.6 and 24.10.8:
- GL.iNet GL-MT3000, target
mediatek/filogic: firmware selector, device page, Amazon search - GL.iNet GL-MT6000, target
mediatek/filogic: firmware selector, device page, Amazon search - Cudy WR3000 v1, target
mediatek/filogic: firmware selector, device page, Amazon search - TP-Link Archer AX23 v1, target
ramips/mt7621: firmware selector, device page, Amazon search - ASUS RT-AX53U / RT-AX1800U, target
ramips/mt7621: firmware selector, device page, Amazon search
Model and hardware revision matter; a v2 with the same retail name can be a different target with different switch support. Check the revision in the firmware selector before buying, and see OpenWrt for the smart home for more hardware that has official builds.
Where this fits
If you are new to OpenWrt itself, start with the OpenWrt pillar, then decide whether this router OS suits you at all with OpenWrt vs DD-WRT. Once the VLAN is in place, a road-warrior tunnel is the natural next step — WireGuard on OpenWrt — and the Home Assistant side of networking is covered on the Home Assistant section front. Anyone weighing a Thread network should read our Matter & Thread coverage before putting devices behind a firewall.
FAQ
Do I need a VLAN for Home Assistant, or is a guest network enough?
A guest network is a start: it usually isolates clients from each other and from your main LAN, which is most of the security benefit. What it does not give you is control. A VLAN lets you decide exactly which ports are open between Home Assistant and your devices, keep the IoT subnet on its own addressing plan, and bind several SSIDs or ports to the same isolated segment. If your router can only do a guest SSID, use it, but expect to solve discovery problems the same way you would on a VLAN.
Why did my ESPHome and HomeKit devices disappear from Home Assistant after I created an IoT VLAN?
Because discovery is multicast, and multicast does not cross a router by default. Home Assistant's zeroconf integration listens for mDNS announcements, and Home Assistant OS itself is reached at an address ending in .local. Once devices sit behind a different interface, those announcements stop arriving and the .local name no longer resolves. The fix is either to forward or reflect mDNS between the two networks, or to stop depending on it by giving devices fixed addresses and adding them by IP.
How do I keep Home Assistant discovering devices on a separate IoT VLAN?
Two workable patterns. Forward multicast between the IoT VLAN and the network Home Assistant sits on, so mDNS announcements arrive, and check results in Settings > System > Network > Zeroconf Browser. Or accept that discovery will not work, give every ESPHome node a static IP with manual_ip, and add devices by host or IP address. The second is more predictable; the first keeps vendor apps working.
Does a Zigbee or Z-Wave coordinator care about VLANs at all?
No. A Zigbee or Z-Wave coordinator is a USB radio attached to the machine running Home Assistant. It speaks to sensors over 802.15.4 or sub-GHz radio and to the host over the USB cable, so IP routing never enters the picture. Zigbee and Z-Wave devices are unaffected by how you segment Wi-Fi.
Will isolating IoT devices break Matter or Thread commissioning?
It can. Matter relies on IPv6 and mDNS, and Thread commissioning needs a border router on the same link or working multicast and IPv6 routing to the devices. A VLAN design that only forwards IPv4 unicast will look routed and still fail at commissioning. Give the IoT segment IPv6, and either keep the border router on that segment or verify that multicast crosses the boundary.
Which cheap OpenWrt routers have official builds for 25.12.6?
From the official download index: the GL.iNet GL-MT3000 and GL-MT6000, the Cudy WR3000 v1, the TP-Link Archer AX23 v1 and the ASUS RT-AX53U all have 25.12.6 builds on the mediatek/filogic and ramips/mt7621 targets, alongside 24.10.8 builds. Check your exact model and revision in the firmware selector before flashing.
- Primary sources
- OpenWrt 25.12.6 release; OpenWrt 24.10.8 release; official target index; OpenWrt VLAN documentation (behind a bot check; open in a browser); Home Assistant zeroconf; ESPHome Wi-Fi component; Home Assistant Matter; Companion app networking notes
As an Amazon Associate, HA News earns from qualifying purchases.