How to Set Up an IoT VLAN for Home Assistant

The Homelab Bench is reader-supported. As an Amazon Associate we earn from qualifying purchases; this article contains affiliate links.

This guide walks you through splitting your home network into two (or more) separate VLANs — one for trusted devices like laptops and phones, another locked down for IoT gadgets like smart plugs, bulbs, and cameras. By the end you will have a firewall that stops a compromised smart bulb from ever touching your NAS or your Home Assistant backup files, while still letting Home Assistant control everything it needs to. No networking background required — just a couple of evenings and the right gear.

Why VLAN Separation Matters for a Home Assistant Homelab

Every smart device you add is a potential entry point. Smart cameras, voice assistants, robot vacuums, and connected appliances all connect to your network and communicate with external servers you have no direct control over. If one of them is compromised, a flat network gives an attacker a straight path to everything else — your NAS, your Proxmox node, your router admin page. A dedicated IoT VLAN prevents a compromised smart device from reaching your primary network and personal data.

VLANs let you split one physical network into multiple separate logical networks without buying extra hardware. The security comes from your firewall, which controls exactly which VLAN can talk to which other VLAN, and on what ports. VLANs alone do not enforce isolation — your firewall rules do the real work. Creating a VLAN without adding blocking firewall rules is a flat network with extra steps.

If you run Home Assistant inside Proxmox, also read our guide on installing Home Assistant in a Proxmox VM and our primer on creating your first VM and LXC container in Proxmox before tackling this — understanding how Proxmox bridges and virtual NICs work makes the networking steps here much clearer.

What You Need Before You Start

• A VLAN-capable router or firewall. Your ISP-supplied router almost certainly cannot do this. You need something running OPNsense, pfSense, OpenWrt, or a Ubiquiti UniFi gateway (UDM Pro, Cloud Gateway, etc.). These let you create multiple VLAN interfaces, assign them to subnets, and control traffic between them using firewall rules.
• A managed switch that supports 802.1Q VLAN tagging. An unmanaged switch is VLAN-blind — it will either drop tagged traffic or strip the tags, breaking your segmentation entirely.
• A VLAN-aware wireless access point if you have Wi-Fi IoT devices. Most consumer mesh systems — standard Eero, base Google Wifi, plain Deco — do not expose VLAN mapping. UniFi, Omada, and OpenWrt-capable APs do. If your access point supports multiple SSIDs mapped to different VLANs, you are good to go.
• A rough list of your IoT devices (or at least categories — cameras, smart plugs, thermostats, bulbs) so you are not guessing at firewall rules blind.

Budget Switch Picks

The TP-Link TL-SG108E is the standard budget entry point for VLAN-capable switching. It is an 8-port gigabit managed switch with a web interface, supports 802.1Q port-based VLANs, QoS, and IGMP snooping. It fits on a desktop or can be wall-mounted, has a metal case, and draws under 4 watts.

Check price: Amazon UK | Amazon US | Amazon IE

The Netgear GS308E is a solid mid-range alternative with an intuitive web GUI, advanced VLAN support, QoS, and IGMP snooping in a fanless design.

Check price: Amazon UK | Amazon US | Amazon IE

Orienting Yourself: Key Concepts Before You Touch a Menu

• VLAN ID (VID): A number, typically between 2 and 4094, that tags network traffic with a label. Think of it like a coloured sticker on a packet — the switch reads the sticker and sends the packet only to ports that belong to that colour group.
• Access port (untagged port): A switch port where a single end device (a laptop, smart plug, camera) is connected. The device itself has no idea VLANs exist — the switch silently stamps outgoing frames with the VLAN ID and strips the tag on incoming frames.
• Trunk port (tagged port): A switch port that carries multiple VLANs simultaneously, each with its tag intact. This is the cable between your switch and your router, and between your switch and an access point — one physical cable, many logical networks.

There is a 1:1 relationship between a VLAN and a subnet — for example, VLAN 10 = 192.168.10.0/24. This lets your router know which network each VLAN belongs to, and gives each VLAN its own DHCP scope and its own gateway address.

Step 1: Plan Your VLAN Layout on Paper First

Do this before touching any menu. A solid starting layout for a Home Assistant homelab looks like this:

Keep the VLAN ID matching the third octet of the subnet — VLAN 20 on 192.168.20.0/24 — so firewall logs stay readable. Starting with two VLANs (Trusted and IoT) is perfectly fine; add a Guest VLAN only when you have a clear reason to.

Note which IoT devices genuinely need internet access (cloud-dependent bulbs, voice assistants) versus which can be fully local (ESPHome sensors, Shelly in local mode). Devices that work entirely locally do not need an outbound internet rule at all.

Step 2: Create the VLAN Interfaces on Your Router/Firewall

On OPNsense

1. Log in to your OPNsense web interface (default: 192.168.1.1).
2. Go to Interfaces → Other Types → VLAN. Click Add.
3. Set Parent Interface to the physical LAN port that connects to your managed switch (e.g., igc1 or em1 — not your WAN port).
4. Set VLAN Tag to 20. Set a Description like IoT. Click Save.
5. Go to Interfaces → Assignments. Find the new VLAN interface in the dropdown and click Add, then Save.
6. Click the newly assigned interface (e.g., OPT1). Tick Enable interface, set IPv4 Configuration Type to Static IPv4, enter 192.168.20.1 as the IPv4 address with a /24 subnet mask. Click Save, then Apply Changes.
7. Set up DHCP for the new interface. On recent OPNsense installs this is under Services → Dnsmasq DNS & DHCP, where you add a DHCP range for the IoT interface; on older or upgraded installs it is Services → ISC DHCPv4, where you select the IoT interface and tick Enable. Either way, set the range to 192.168.20.100–192.168.20.239, and click Save. Each VLAN needs its own DHCP scope — skip this and every IoT device will fail to get an address, with confusing symptoms that make you suspect the switch first.
8. Repeat steps 2–7 for VLAN 30 (Guest) if you want one, using 192.168.30.1 and a matching DHCP range.

On UniFi (UDM/UniFi Gateway)

1. Log into UniFi Network and go to Settings → Networks.
2. Click New Virtual Network. Give it a name (e.g., IoT).
3. Deselect Auto-Scale Network if you want to control the subnet yourself. Set VLAN ID to 20 and the host address to 192.168.20.1 with a /24 netmask. UniFi creates the DHCP scope automatically.
4. Click Save. Repeat for any additional VLANs.

Step 3: Configure the Managed Switch

1. Open the switch’s web interface. On the TP-Link TL-SG108E, the default IP is printed on the label; on UniFi switches, everything is managed through the UniFi controller.
2. Navigate to the 802.1Q VLAN section.
3. Create VLAN 20 (IoT). For each port:
   • The port going up to your router: set as Tagged for VLAN 20 (and every other VLAN you create — this is your trunk port).
   • Any port going to an IoT device directly: set as Untagged for VLAN 20.
   • Any port going to a trusted device: leave as Untagged on VLAN 1 (the default).
   • Any port going to your access point: set as Tagged for all VLANs so the AP can carry multiple SSIDs.
4. Set the PVID for each access port to match its VLAN — port going to an IoT device gets PVID 20, port going to a trusted device gets PVID 1. On TP-Link and Netgear switches, also remove each IoT port from VLAN 1’s member list — otherwise it keeps receiving trusted-LAN traffic.
5. Save and apply.

Quick sanity check: Plug a laptop into a port set to VLAN 20. It should receive an IP in the 192.168.20.x range. If it gets a 192.168.1.x address instead, the PVID on that port is still set to VLAN 1 — go back and correct it.

Step 4: Create a Separate Wi-Fi SSID for IoT

1. Log into your access point’s management interface (UniFi: Settings → Wi-Fi → Add New Wi-Fi Network; Omada: similar path under Wireless Networks).
2. Name the SSID something obvious like Home-IoT. Under Network, select the IoT VLAN. This tags all traffic from this SSID into VLAN 20.
3. Set security to WPA2-AES. Most IoT devices only support 2.4 GHz and do not support WPA3 — a WPA3-only configuration will cause connection failures on older gear.
4. Save and wait for the AP to push the update.

A trusted network and an IoT network can share the same physical access point with separate SSIDs, provided your AP supports VLAN mapping — which is one reason prosumer APs earn their place in a homelab.

Step 5: Write the Firewall Rules

This is the step most beginners skip or get wrong, and it is the most important one. A VLAN separates broadcast traffic, but devices can still communicate through the router unless firewall rules explicitly block them. VLANs without firewall rules are just subnets — not security boundaries.

The goal for your IoT VLAN is: IoT devices can reach the internet. IoT devices cannot initiate connections to your trusted LAN. Your trusted LAN (and specifically Home Assistant) can reach IoT devices to control them.

On OPNsense

Firewall rules in OPNsense are written on the source interface — they control what traffic is allowed out of that interface. Go to Firewall → Rules and select your IoT interface tab.

1. Allow DNS to the gateway: Create a rule — Action: Pass, Interface: IoT, Protocol: TCP/UDP, Source: IoT net, Destination: 192.168.20.1, Destination Port: 53. This ensures IoT devices can resolve hostnames even after you apply blocking rules.
2. Allow IoT devices to reach your MQTT broker (if you use one): Add a pass rule — Source: IoT net, Destination: your MQTT broker’s IP (e.g., 192.168.1.50), Destination Port: 1883. Tasmota, Shelly, Zigbee2MQTT and other MQTT devices open the connection to the broker, so they need this. You do not need a rule for Home Assistant polling or controlling IoT devices: the firewall automatically lets replies back for connections Home Assistant starts. Only add an IoT → Home Assistant port 8123 rule for devices that push data to Home Assistant’s API or webhooks.
3. Block IoT → Trusted LAN: Create an alias called RFC1918 containing 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Then add a rule — Action: Block, Source: IoT net, Destination: RFC1918 alias. Place this below any specific allow rules — OPNsense processes rules top to bottom and stops at the first match. This single rule stops IoT devices from reaching any private IP range — your NAS, your Proxmox node, your router admin — while internet IPs pass through because they are not in RFC1918 ranges.
4. Allow IoT → Internet: After the block rule, add — Action: Pass, Source: IoT net, Destination: Any. Because the block above already stops RFC1918 destinations, this rule only permits real internet traffic. For fully local devices (ESPHome sensors, Shelly in local mode), skip this rule entirely — if a device does not need internet to work, do not give it access.

Use descriptive rule names like IoT – allow DNS to gateway and IoT – block to private ranges. Cryptic names cause real pain six months later.

On UniFi (Zone-Based Firewall, Network 9.0+)

1. Go to Settings → Firewall & Security. New networks start in the built-in Internal zone, where every network can reach every other, so first click Create Zone, name it IoT, and move your IoT network into it.
2. In the zone matrix, set traffic from the IoT zone to the Internal zone to Block, and make sure Internal to IoT is allowed so Home Assistant can control your devices (replies are allowed automatically).
3. Add specific exceptions as policies above the block — for example IoT to your MQTT broker’s IP on port 1883 with Action: Allow. The first matching rule wins, so the specific allow must sit above the broad block.

Step 6: Solve the mDNS Problem for Home Assistant

This is the most common gotcha when moving IoT devices to a separate VLAN. Home Assistant finds most devices through mDNS (also called Zeroconf or Bonjour) — the same protocol that makes your phone discover a Chromecast. mDNS uses link-local multicast, which a standard router does not forward between VLANs. Move your devices to VLAN 20 and Home Assistant on VLAN 1 simply stops seeing them.

• Option A — Put Home Assistant on the IoT VLAN. Discovery works natively because Home Assistant hears every mDNS announcement on its own network. The firewall only needs one deliberate opening: trusted clients (your laptop, your phone) reaching Home Assistant’s web interface on port 8123. This is the cleaner design for most setups, especially if you run ESPHome devices, Shelly, or WLED. One catch: the RFC1918 block rule from Step 5 now applies to Home Assistant too, so add pass rules above it for anything HA needs on the trusted LAN, such as your NAS for backups or an MQTT broker.
• Option B — Run an mDNS reflector/repeater. OPNsense has a built-in Multicast DNS Proxy — install it via System → Firmware → Plugins, search for os-mdns-repeater, install it, then go to Services → mDNS Repeater and select both your LAN and IoT interfaces. UniFi has a per-network mDNS toggle — enable it on both the trusted and IoT networks. Only relay mDNS between the specific VLANs that need it; do not enable it globally.

Zigbee and Z-Wave hubs are largely unaffected by the mDNS problem. The hub moves to the IoT VLAN, but the radio protocol it uses does not pass through the IP network at all — you just need a firewall rule allowing HA’s IP to reach the hub’s IP on the relevant port. For more on how Zigbee sits in your network, see our guide on setting up Home Assistant with Zigbee2MQTT from scratch.

Thread is a different story — Thread uses link-local IPv6 addresses and will not cross a VLAN boundary even with mDNS reflection in place. If you use Thread-based Matter devices, your Thread Border Router must be on the same VLAN as your Home Assistant instance. Read more in our guide to the best Thread Border Routers for Home Assistant.

Step 7: Migrate Devices and Test Thoroughly

Do not move every device at once. Test one boundary at a time.

1. Start with a single non-critical device. Connect one smart plug or a spare phone to your new IoT SSID. Confirm it gets an IP in the 192.168.20.x range.
2. Verify internet access from IoT: Ping 1.1.1.1 from that device or a laptop plugged into an IoT-tagged port. It should succeed. If it fails, check your allow rule on the IoT interface and confirm it is not shadowed by a block above it.
3. Verify isolation from Trusted: From the same IoT-tagged device, try pinging a trusted device — your router’s LAN IP (192.168.1.1) or a laptop on the trusted network. This should fail. If it succeeds, your block rule is missing, in the wrong order, or the device is still on the wrong VLAN.
4. Verify Home Assistant can reach IoT devices: Trigger an automation or manually control the device from the HA dashboard. If it fails, check that traffic from the trusted LAN to the IoT VLAN is still allowed — on OPNsense the default LAN “allow any” rule covers this, so make sure you have not removed it; on UniFi check the Internal → IoT entry in the zone matrix.
5. Check HA discovery: Verify that integrations for devices on the IoT VLAN still show as available. If an integration shows unavailable, your mDNS reflector needs attention.
6. Migrate the rest in batches by type — all smart plugs, then all bulbs, then cameras. Moving in batches makes it easy to identify which category of device triggers a rule you did not anticipate.

Keep a note of every firewall exception you add, with a reason. A rule with no documented reason is a rule you will not feel confident removing later.

Where Home Assistant Fits in Your Proxmox Setup

If you run Home Assistant as a VM inside Proxmox, assign the VM’s virtual NIC to a VLAN by tagging it on the Proxmox bridge. Go to the VM’s Hardware tab, click the Network Device, and set the VLAN Tag field to 20. Proxmox will tag that VM’s traffic into VLAN 20 on your physical trunk link without needing a separate physical NIC. Make sure the upstream port from Proxmox to your switch is configured as a trunk (tagged on all VLANs the host needs to carry), and tick VLAN aware on the bridge under System → Network in the Proxmox UI. Once done, any VM can be assigned to any VLAN just by setting the tag on its virtual NIC.

For a full walkthrough of hardware suited to this kind of setup, take a look at our guide to the best mini PCs for Proxmox homelabs.

Quick Reference: VLAN Firewall Policy Table

FAQ

Does Home Assistant need to be on the IoT VLAN or the trusted LAN?

Either works, but putting Home Assistant on the IoT VLAN is the simpler design. mDNS discovery works natively because HA shares a broadcast domain with the devices it controls. The only firewall exception you then need is trusted clients (your phone, laptop) reaching HA’s web interface on port 8123. If HA stays on the trusted LAN, you must run an mDNS reflector and keep traffic from HA’s IP to the IoT subnet allowed — more moving parts, but achievable. The key exception is Thread-based Matter devices: Thread uses link-local IPv6 and will not cross a VLAN boundary, so your Thread Border Router must always share a VLAN with Home Assistant.

My IoT device stopped working after I moved it to the IoT VLAN. Where do I start?

Work through it in order: first confirm the device got an IP in the 192.168.20.x range — if not, the PVID on the switch port or the DHCP scope on the router is wrong. If the IP is correct, confirm the device can reach the internet (ping 1.1.1.1 from the same subnet). If internet works but Home Assistant cannot see or control it, the issue is either traffic from HA to the IoT subnet being blocked, or an mDNS discovery problem — enable the mDNS reflector and verify HA rediscovers the device. For hub-based integrations like Zigbee2MQTT, check that the broker’s IP is accessible from HA’s IP on the correct port.

Can I use a standard ISP router or a cheap unmanaged switch?

No on both counts. An ISP-supplied router almost never exposes VLAN interface creation or per-interface firewall rules — you need to replace it with OPNsense, pfSense, OpenWrt, or a UniFi gateway. An unmanaged switch cannot enforce 802.1Q VLAN tagging; it will either drop tagged traffic or ignore the tags entirely, making it impossible to keep VLANs separated at the switch layer. The minimum hardware is a VLAN-capable router and a managed switch — both available at budget prices, as the TP-Link TL-SG108E demonstrates.