VLAN for IoT Devices: Step-by-Step Setup Guide

TL;DR: A VLAN for IoT devices puts your smart plugs, cameras, and speakers on their own logical network, separate from your laptops and NAS, using a single physical router and switch. You create the VLAN on your router/firewall, tag it on your switch and access point, put IoT devices on their own SSID, then write firewall rules that block that VLAN from reaching your main LAN while still allowing internet access.

Here's the situation that gets people to actually do this: a $12 smart plug from three years ago that hasn't had a firmware update since 2022, sitting on the same flat network as your work laptop and the NAS with your tax documents on it. If that plug gets popped — and cheap IoT firmware is popped constantly — the attacker is now on your LAN, not just on "a smart plug." VLANs fix that by drawing a hard line between "things I trust" and "things I plug in because they're convenient."

This is home-network and small-office segmentation, not enterprise campus design, so I'm going to skip the CCNA-textbook stuff and focus on what actually breaks when people try this: mDNS discovery, rule ordering, and the "VLANs exist but nothing's actually blocked" trap that catches almost everyone the first time.

What Does a VLAN Actually Do for IoT Devices?

A VLAN (Virtual LAN, IEEE 802.1Q) splits one physical network into multiple logical broadcast domains using a tag in the Ethernet frame — a number from 1 to 4094. Devices on VLAN 10 can't see broadcast or multicast traffic from VLAN 20, and by default they can't reach each other at Layer 2 at all. The only way traffic crosses between VLANs is through a router or firewall doing Layer 3 routing, which is exactly where you get to write rules.

That's the part people miss: creating the VLAN by itself does nothing for security. On most routers and controllers — UniFi included — inter-VLAN routing is allowed by default once you've assigned an IP range to each VLAN. The VLAN gives you the separation; the firewall rule is what turns that separation into isolation. Skip the firewall rule and you've just built a more complicated flat network.

What You Need Before You Start

  • A router or firewall that supports VLAN interfaces and stateful firewall rules per interface (OpenWrt, pfSense, OPNsense, UniFi Gateway/UDM, or similar — most ISP-supplied routers do not do this).
  • A managed switch that supports 802.1Q tagging, if you have more than one switch or wired device per segment. Unmanaged switches pass VLAN tags through fine as long as you don't need per-port control, but you can't assign a port to a specific VLAN on one.
  • An access point that supports multiple SSIDs mapped to different VLANs (most consumer mesh systems — Eero, base Google Wifi/Nest Wifi, plain Deco — do not expose this; UniFi, most OpenWrt-capable APs, Omada, and prosumer Aruba/Ruckus gear do).
  • A rough list of your IoT devices, or at least the categories (cameras, voice assistants, smart plugs, thermostats) so you're not guessing at firewall rules blind.

If your current router is an ISP-issued combo unit, this is the point where you either replace it with something VLAN-capable or drop a VLAN-aware router downstream in bridge/passthrough mode. There's no clean way around this — it's the one hard requirement.

The Basic Design: One Router, Three VLANs

The layout I'd start with for a typical home or small office:

VLANPurposeTypical subnetTrust level
VLAN 1 (native/default)Trusted LAN — your laptops, phones, NAS192.168.1.0/24High
VLAN 20IoT — smart plugs, bulbs, sensors, cameras192.168.20.0/24Low
VLAN 30Guest — visitor devices192.168.30.0/24Untrusted

Numbering VLAN IDs in tens (10, 20, 30) isn't required by anything technical — it's just so you have room to insert VLAN 15 later without renumbering everything. I split cameras onto their own VLAN if you're running more than a couple, since NVR/camera traffic patterns and bandwidth needs are different from a smart plug checking in every 30 seconds, but for a first pass, lumping "IoT" together is fine.

Setting This Up on UniFi (UDM / UniFi Gateway)

UniFi is the path of least resistance if you're starting from scratch, because the controller handles VLAN tagging across switches and APs automatically once devices are adopted.

  1. In UniFi Network, go to Settings > Networks > Create New Network, choose Advanced, give it a name like "IoT," and set a VLAN ID (e.g. 20) and subnet (e.g. 192.168.20.1/24). Leave DHCP on auto unless you need static reservations.
  2. Go to Settings > WiFi > Create New WiFi Network, name it something like "Home-IoT," and under Network select the IoT VLAN you just created. Most IoT gear only does 2.4 GHz, so don't be surprised if this SSID sees more traffic there than your main one.
  3. This is the step people skip: go to Settings > Firewall & Security > Firewall Rules (or the zone-based policy screen on newer UniFi OS versions) and add a rule blocking the IoT network from reaching your main LAN network — source: IoT subnet, destination: LAN subnet, action: Drop.
  4. Add a second rule allowing established/related sessions back through, so devices you initiate contact with (e.g., opening a camera stream from your phone) still get responses.

I've seen UniFi documentation and user guides differ slightly on exact menu wording between UniFi OS versions (Settings vs. Classic UI), so if a menu path doesn't match what you see, search "UniFi Network" plus your current app version rather than assuming the guide is wrong.

Setting This Up on pfSense or OPNsense

pfSense gives you more granular control but nothing happens automatically — you're writing every rule.

  1. Go to Interfaces > Assignments > VLANs, add a new VLAN, pick your parent interface (the physical NIC facing your switch), and set the VLAN tag — any integer 1–4094.
  2. Back on the Interface Assignments page, assign that new VLAN device to an OPT interface, then go into that interface's settings, enable it, and give it a static IPv4 address (e.g. 192.168.20.1/24). pfSense won't let you bind a DHCP scope to the interface until it has a static IP set.
  3. Turn on the DHCP server for that interface under Services > DHCP Server.
  4. Now the important part — go to Firewall > Rules, select the tab for your new VLAN interface, and add rules in this order (pfSense evaluates top-down, first match wins):
    • Allow: source = IoT subnet, destination = "This Firewall," port 53 (DNS) and, if you run DHCP off this box, ports 67/68 — only needed if you want to explicitly document it, since pfSense passes DHCP itself by default.
    • Block: source = IoT subnet, destination = an alias covering all private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — build this as a Firewall > Aliases network alias, commonly named RFC1918).
    • Allow: source = IoT subnet, destination = any (this is what gives IoT devices internet access after the block rule above has already stopped them reaching other private subnets).
The block rule has to sit above the "allow any" rule, or the allow rule matches first and your isolation does nothing. This is the single most common reason people post "my VLAN isn't isolated" — the rules exist, just in the wrong order. Also double-check your alias actually covers every private range in use; a rule that only blocks 192.168.0.0/16 won't stop traffic to a 10.x management network.

Setting This Up on OpenWrt

If you're on OpenWrt 21.02 or later, VLANs go through DSA (Distributed Switch Architecture), which replaced the old swconfig switch page. There's no more "Switch" tab in LuCI for most modern targets — you configure VLANs directly on the bridge.

  1. Go to Network > Interfaces > Devices, edit your br-lan bridge device, and open the Bridge VLAN filtering tab. Enable VLAN filtering.
  2. Add a VLAN entry (e.g. VLAN 20), and for each physical port decide: t (tagged — for trunk links to a switch or AP), u (untagged — for a port with an IoT device plugged in directly), or leave it off entirely.
  3. Go to Network > Interfaces, add a new interface, set its device to br-lan.20 (the VLAN 20 sub-device DSA creates automatically), give it a static IP like 192.168.20.1/24, and set up its own DHCP pool.
  4. Under Network > Firewall, create a new firewall zone for this interface (e.g. "iot"), and edit the forwarding rules so the IoT zone can forward to wan but not to lan. By default a new OpenWrt zone can't forward anywhere, so you're adding permission for internet only, not removing anything.

Here's what that firewall config looks like in /etc/config/firewall once it's in place — I'm showing the raw config because it's genuinely easier to read than screenshotting six LuCI tabs:

config zone
    option name 'iot'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    list network 'iot'
 
config forwarding
    option src 'iot'
    option dest 'wan'

Notice there's no forwarding stanza pointing from iot to lan — that's the isolation. It's not a "block" rule you add; it's a permission you simply never grant.

Why Won't My Google Home / Chromecast / Smart Speaker Find Devices Across VLANs?

This is the gotcha almost everyone hits in week one. Chromecast, AirPlay, HomeKit, and a lot of smart home discovery relies on mDNS (multicast DNS, UDP port 5353) and SSDP/UPnP — both of which are inherently link-local and don't cross VLAN boundaries by design. That's not a bug; multicast traffic staying inside its own broadcast domain is the entire point of segmentation. But it does mean your phone on the trusted VLAN won't "see" a Chromecast sitting on the IoT VLAN out of the box.

Three ways to handle it, roughly in order of how much I trust them:

  • mDNS reflector/repeater — a service (Avahi in reflector mode on Linux-based routers, or a dedicated mDNS repeater container) that listens on both VLANs and re-broadcasts mDNS announcements across them. This is the standard fix and what most OpenWrt/pfSense/UniFi guides point to.
  • Targeted firewall rule — instead of reflecting all mDNS traffic, allow UDP 5353 specifically between the two subnets, or better, allow the trusted VLAN to reach only the specific IP/port a device like Home Assistant needs (e.g., port 8123) rather than opening broad multicast access.
  • Don't fully isolate that one device — if a device genuinely needs two-way discovery and you don't want to fuss with a reflector, some people just leave media/cast devices on the trusted VLAN and isolate the riskier stuff (plugs, bulbs, no-name cameras) instead. Less pure, more pragmatic, and honestly fine for a lot of home setups.

I lean toward option two for anything that talks to a hub like Home Assistant, and I don't bother reflecting mDNS globally — it re-introduces some of the cross-segment visibility you built the VLAN to remove.

VLAN Support by Router/Firmware — Quick Comparison

PlatformVLAN supportNotes
UniFi (UDM/USG + switches)Yes, GUI-managedController pushes VLAN tags to adopted switches/APs automatically; inter-VLAN routing allowed by default — you must add block rules
pfSense / OPNsenseYes, full manual controlNothing blocked by default between VLANs beyond the base deny-all on new interfaces; you write every rule
OpenWrt 21.02+ (DSA)Yes, via bridge VLAN filteringReplaces the old swconfig "Switch" tab; config is bridge- and zone-based now, not per-switch-port
TP-Link OmadaYes, GUI-managedSimilar model to UniFi — controller-managed VLANs and SSID mapping
Most ISP-supplied gateway/modem combosNoTypically no VLAN interface support at all; put a real router downstream in bridge mode
Consumer mesh (Eero, base Nest Wifi, Deco standard tiers)Mostly noA few higher-end mesh SKUs added limited VLAN/IoT network features — check your specific model's current spec sheet, this changes often

Testing That Isolation Actually Works

Don't take "the rule is saved" as proof it's working. Test it:

  • From a device on the IoT VLAN, try to ping a host on your trusted LAN. It should time out.
  • From your trusted LAN, try to reach the IoT VLAN's gateway IP or a device on it directly. Same — should fail unless you added an explicit allow rule.
  • Confirm the IoT device still gets an IP via DHCP and can still reach the internet (open its companion app, check for firmware update capability).
  • If you set up an mDNS reflector or targeted discovery rule, confirm the specific use case (casting, HomeKit pairing) still works — but only for the thing you intentionally allowed.

I've had isolation "work" on paper — rule present, correctly ordered — and still fail in testing because a legacy static route on an old managed switch was providing a second path around the firewall. If ping succeeds when it shouldn't, check for anything else routing between the segments before you assume the firewall rule itself is wrong.

Common Mistakes

  • Creating the VLAN and stopping there. Covered above, but it's the single most common miss. No block rule, no isolation.
  • Blocking the wrong address range. If your block rule only covers 192.168.0.0/16 but part of your network uses 10.x, traffic sails right through to it.
  • Rule order. A permissive "allow any to any" rule placed above your block rule wins, because most firewalls (pfSense included) match top-down and stop at the first hit.
  • Blocking DNS along with everything else. If your router is also the DNS server for the IoT VLAN, a blanket private-range block will also kill DNS resolution to the router itself unless you add a narrow allow rule for port 53 first.
  • Forgetting the access point. The VLAN tag has to make it from your router, across the trunk port on your switch, out to the AP, and onto the correct SSID. Miss one hop — usually a switch port left as "access" instead of "trunk" — and devices land on the wrong network or get no IP at all.

FAQ

Do I need a managed switch to use a VLAN for IoT devices?

Only if you have more than one switch, or need to control which VLAN a specific wired port belongs to. A single unmanaged switch will pass tagged VLAN traffic through transparently between two VLAN-aware devices (say, your router and your access point), but you can't assign individual ports to individual VLANs on it.

Will putting IoT devices on a VLAN slow them down?

No meaningful difference for typical home IoT traffic. VLAN tagging adds a few bytes to each frame and is handled in hardware on any switch made in the last decade. If anything, isolating chatty broadcast/multicast traffic to its own segment reduces noise on your main network.

Can I do this with just a guest network instead of a real VLAN?

A router's built-in "guest network" feature is often just a VLAN under the hood with isolation pre-configured, and it's a reasonable quick option if your router doesn't expose full VLAN controls. The tradeoff is less control — you usually can't add a targeted allow rule for something like Home Assistant without editing router firmware directly, and guest networks are sometimes rate-limited or restricted from local network resources entirely by design.

Does 802.1Q VLAN tagging work over Wi-Fi?

The VLAN tag itself is an Ethernet (wired) concept. Over Wi-Fi, the access point maps each SSID to a VLAN and handles the tagging on the wired side; the wireless client just sees a normal Wi-Fi network. This is why AP support for "multiple SSIDs, each bound to a different VLAN" is a hard requirement, not optional.

What VLAN ID should I use for IoT?

Anything from 2–4094 works technically (VLAN 1 is commonly the default/native VLAN and best left alone or avoided for anything you're isolating). Most guides use round numbers like 10, 20, 30 for readability — there's no functional difference, just pick something documented and consistent across your gear.

Do smart speakers and cameras need internet access at all?

Almost always yes — cloud-dependent devices (most consumer cameras, voice assistants) need outbound internet to function even for local commands in many cases. The isolation goal isn't "cut off the internet," it's "cut off lateral movement to your other devices." Outbound-to-internet stays allowed; device-to-device on your trusted LAN is what gets blocked.

A Few Authoritative References

← Newer Posts Older Posts →