·11 min read

IoT VLAN Segmentation for Smart Homes: Home Assistant, Matter, Thread

guideprivacysecuritynetworkingvlanhome assistantmatterthread

Segmenting a smart home network is less about creating a VLAN and more about deciding which conversations should be allowed across it. A VLAN separates broadcast domains; firewall rules decide whether devices on one network can reach another. That distinction matters because an IoT VLAN with no rules is just another subnet, not isolation (The Homelab Bench).

Why segment at all - and what a VLAN actually buys you

A smart home mixes trusted devices (laptops, phones, NAS) with devices you did not write and cannot easily patch. Segmentation gives those devices their own network and makes cross-network access explicit. The practical benefit is containment: a compromised or noisy IoT device should not automatically reach your trusted LAN.

The important caveat is that a VLAN is a broadcast boundary, not a security boundary, until firewall rules enforce it (The Homelab Bench). Without rules, VLANs are just subnets. For untrusted or guest devices, a separate network is the usual design, and The Homelab Bench adds a Guest VLAN only when there is a clear reason (The Homelab Bench).

The two questions that shape your whole design

First, which devices really need internet access? Fully local devices may need no outbound rule at all, while cloud-dependent devices need a path to WAN (The Homelab Bench). That single decision drives whether you need two, three, or four networks.

Second, what counts as “good enough” device security? The NIST IR 8259 series, including IR 8259A, defines a core baseline of device capabilities generally needed to support common cybersecurity controls, but it is aimed at manufacturers, not homeowners (NIST IR 8259 series). For a homeowner, the realistic lever is network design plus Home Assistant hardening, not a device-capability checklist.

Picking your VLAN layout: two, three, or four networks

The layouts below are the ones described in the cited guides, not a universal ladder of correctness.

  • Two VLANs: Trusted + IoT. This is the recommended starting point, with Guest added only when needed (The Homelab Bench).
  • Three VLANs: Main (trusted, Home Assistant), IoT (VLAN 20), and Guest (VLAN 30) (smarthomeassistant.co.uk).
  • Four VLANs: an advanced split that can include a local-only, no-internet IoT network (Hierl.dev).
  • VLAN ID convention: keep the VLAN ID equal to the third octet, for example VLAN 20 on 192.168.20.0/24 (The Homelab Bench).

The table compares the tradeoffs.

Approach What it protects What breaks (and the fix) Who should use it
No VLAN (flat network) Baseline convenience; nothing is isolated Nothing “breaks,” but IoT and trusted devices share fate Anyone not ready to maintain firewall rules
Two VLANs: Trusted + IoT Separates untrusted IoT from the trusted LAN once rules exist mDNS discovery and Thread commissioning can break; fix with HA on the IoT VLAN or an mDNS repeater on needed VLANs Most homes starting out
Three VLANs: Main / IoT / Guest Adds guest isolation and clearer policy boundaries Same as two-VLAN, plus guest devices need their own rules; enable client isolation on the IoT SSID Homes with frequent guests or many IoT devices
Four VLANs incl. local-only, no-internet IoT Strongest containment for devices that do not need the internet Internet-dependent features stop for local-only devices; cross-VLAN Thread needs IPv6 route work Advanced users who will test boundaries
Same-VLAN HA + IoT with firewall rules only Keeps HA and IoT discovery simple while still filtering IoT-to-LAN traffic HA and IoT share one broadcast domain, so no firewall rule separates them; keeps HA and the Thread border router on one subnet, per Position A People who want the simplest Matter/Thread setup

These are documented options, not ranked by measured outcomes.

The firewall rules, in the order that matters

The order below follows The Homelab Bench, which places the RFC1918 block below the specific allow rules (The Homelab Bench). smarthomeassistant.co.uk uses a similar sequence without an RFC1918 alias, and places the HA-to-IoT allow on the main LAN interface (smarthomeassistant.co.uk).

  1. Allow established and related traffic first (smarthomeassistant.co.uk).
  2. Add specific allow rules next, including IoT to Home Assistant (The Homelab Bench; Michael Sleen). When Home Assistant sits on the trusted LAN, add an allow rule from Home Assistant to the IoT VLAN on the trusted-LAN interface, not in the IoT ruleset (smarthomeassistant.co.uk).
  3. Block IoT to RFC1918 below those allows. An RFC1918 alias covers 10/8, 172.16/12, and 192.168/16 (The Homelab Bench).
  4. Then pass IoT to WAN for devices that genuinely need internet (The Homelab Bench; smarthomeassistant.co.uk).
  5. Enable client isolation on the IoT SSID so IoT devices cannot scan each other over Wi-Fi (smarthomeassistant.co.uk).

For the Home Assistant allow rule, accept traffic only to the HA server, using HA as the destination address group (Michael Sleen). Assign fixed IPs to any device referenced by firewall rules, especially Home Assistant, so the rules keep working (Michael Sleen).

Keeping Home Assistant reachable - and locked down

Placement is a choice, not a rule. Home Assistant can live on the same VLAN as IoT, or on the trusted LAN with an allow rule from IoT to a fixed Home Assistant IP (The Homelab Bench; Michael Sleen). The same-VLAN option simplifies discovery and Thread; the trusted-LAN option keeps HA with your other trusted machines.

Securing Home Assistant itself is separate from VLAN design. Home Assistant is reachable only on the local network by default (Home Assistant remote access docs). Do not expose it directly to the internet; options include Home Assistant Cloud (no port forwarding), TLS via Duck DNS plus Let’s Encrypt, or a VPN/SSH tunnel (Home Assistant securing docs). If you use a reverse proxy, Home Assistant must be configured to trust it, or requests are blocked by design (Home Assistant remote access docs; HTTP integration docs). Port forwarding is not secure by itself, and dynamic IP or CG-NAT ISPs can break inbound access (Home Assistant remote access docs). Named VPN options include Tailscale and ZeroTier One (Home Assistant remote access docs).

Basic hardening still applies: strong unique passwords, multi-factor authentication, monthly updates, and centralized secrets, with the caveat that secrets.yaml does not encrypt them (Home Assistant securing docs).

mDNS discovery: the thing that breaks first

mDNS is link-local and does not cross subnets or VLANs by default (Home Assistant community: Thread/Matter router rules; Home Assistant community: Matter with multiple VLANs). That is why discovery is the first casualty of segmentation: a Home Assistant instance on one subnet cannot see mDNS announcements from devices on another.

Two fixes are documented:

  • Put Home Assistant on the IoT VLAN, so discovery stays on one broadcast domain (The Homelab Bench).
  • Or enable an mDNS repeater/reflector, but only on the VLANs that need it. Implementations include the OPNsense os-mdns-repeater, a per-network mDNS toggle in UniFi, Omada’s mDNS gateway (v5.9+), and the Home Assistant mdns-repeater add-on (The Homelab Bench; smarthomeassistant.co.uk).

Limiting the repeater to the necessary VLANs avoids turning one discovery leak into another.

Matter-over-Thread: the honest, contested part

This is the one area where credible sources disagree, and the post does not resolve it.

Position A, same VLAN: Home Assistant’s documentation, as summarized in a Home Assistant community thread, requires the HA instance and the Thread border router to be on the same subnet/VLAN (Home Assistant community: Thread/Matter router rules). The Homelab Bench says Thread uses link-local IPv6 addresses and will not cross a VLAN boundary even with mDNS reflection in place (The Homelab Bench).

Position B, cross-VLAN with a static route: Hierl.dev reports running Matter-over-Thread across VLANs by giving each relevant VLAN its own IPv6 /64, enabling a gateway mDNS proxy across three VLANs, and adding a static IPv6 route on the gateway. The destination is the Thread mesh-local /64 derived from the address in the matter server log; the next hop is the border router’s IPv6 address in its own VLAN. The author reports that IPv6 per VLAN, the mDNS proxy, and the static route together were required, and that without the route commissioning failed because the Thread mesh address was unreachable from Home Assistant (Hierl.dev).

Position A has fewer moving parts, which makes it the simpler default for most homes; that is this guide’s judgment, not a sourced ranking. Position B is a documented alternative for people who want the border router on another VLAN, but it comes with specific IPv6 and routing requirements and is one author’s single-network result, not a general guarantee. Thread is IPv6-only, so without IPv6, Matter-over-Thread does not work at all (Hierl.dev).

If commissioning fails, the diagnostic signpost is the matter server log showing the Thread mesh address unreachable from Home Assistant (Hierl.dev). That points to border router placement and routing, as described above.

Zigbee, Z-Wave, and IP-based hubs

Zigbee and Z-Wave hubs that talk over IP only need one allow rule from Home Assistant to the hub (The Homelab Bench). Hub placement follows the same logic as the rest of the design: give the hub a fixed IP so the rule keeps pointing at it (Michael Sleen).

How to verify it actually works (and when it breaks)

Plug a laptop, or move a device, into an IoT-VLAN-tagged port and run these checks in order. Checks 1 and 2 are the ping tests described by The Homelab Bench (The Homelab Bench); checks 3 to 5 are this guide’s suggested additions:

  1. Internet reachable check: from the IoT port, confirm internet access works. If it fails, check your allow rule on the IoT interface and confirm it is not shadowed by a block above it.
  2. Trusted LAN unreachable check: from the IoT port, attempt to reach a host on the trusted LAN, such as a laptop or your router’s LAN address. It must fail. If it succeeds, the block rule is missing, in the wrong order, or the device is still on the wrong VLAN.
  3. Home Assistant reachable check: from the IoT port, confirm Home Assistant at its fixed IP is reachable, then trigger a control from the dashboard.
  4. Discovery check: confirm integrations for IoT devices still show as available in Home Assistant. If an integration shows unavailable, your mDNS reflector needs attention.
  5. Matter/Thread commissioning check: attempt to commission a Thread device. If the matter server log shows the Thread mesh address unreachable from Home Assistant, the border router placement or route question in the Matter-over-Thread section above is the likely cause (Hierl.dev).

FAQ

Do I need IPv6? For Matter-over-Thread, yes: Thread is IPv6-only, so without IPv6 it does not work (Hierl.dev). For other devices, this guide does not make a claim.

Does this break Alexa or Google casting? This guide’s sources do not test Alexa or Google casting. Matter discovery relies on mDNS, which is link-local and does not cross VLANs by default (Home Assistant community: Matter with multiple VLANs), so test the exact service after the discovery check.

Can I skip the firewall rules? No. VLANs without firewall rules are just subnets, not security boundaries (The Homelab Bench).

Should Home Assistant be on the IoT VLAN? Either placement is documented: HA on the IoT VLAN simplifies discovery and Thread, while HA on the trusted LAN with an allow rule to a fixed IP keeps it with trusted machines (The Homelab Bench; Michael Sleen). Choose based on which tradeoff you prefer.

What if Thread commissioning fails? Look for the matter server log showing the Thread mesh address unreachable from Home Assistant. That is the signpost for a border router placement or routing problem (Hierl.dev).

Do I need a guest network? A separate network for untrusted devices is the usual approach, and the three-VLAN layout adds Guest as its own network (smarthomeassistant.co.uk).

The Bottom Line

Start small: two VLANs, Trusted and IoT, with firewall rules in the right order, fixed IPs for referenced devices, and a single verification pass from an IoT-tagged port. Add Guest or a local-only network only when you have a concrete reason and the time to test it.

Treat Home Assistant placement and Thread border router placement as the decisions that determine whether discovery and commissioning survive. If you want the simpler path, keep Home Assistant and the Thread border router on the same VLAN. If you want the border router elsewhere, use the cross-VLAN IPv6 route approach only with its full requirements and its single-author caveat. In either case, verify each boundary with the checks above instead of assuming it works.

How This Guide Was Built

This guide is based on official documentation, vendor and community documentation, and author reports — we did not run these configurations ourselves.

It draws on NIST IR 8259A, Home Assistant’s securing and remote access documentation, community discussions of Thread and Matter across VLANs, and author guides from The Homelab Bench, smarthomeassistant.co.uk, Hierl.dev, and Michael Sleen. The one genuine source conflict - whether a Thread border router must share a VLAN with Home Assistant or can work across VLANs with a static IPv6 route - is reported as unresolved, with Position A presented as the simpler default and Position B attributed as one author’s result. No configuration here was tested by us, and no screenshots, logs, or command outputs are presented as our own.

← Back to guides