Devices & Setup

IoT VLAN segmentation: trusted, IoT, guest networks

Smart-home devices live on a different security tier than your laptop. Cameras, smart plugs, voice assistants, doorbells, robot vacuums — most of them have minimal security testing, infrequent firmware updates, and direct internet connectivity. The right network design separates them onto an IoT-only VLAN with rules that prevent IoT-to-trusted traffic, while preserving the discovery (mDNS / SSDP / Matter / Thread) that smart-home platforms need.

Three-tier VLAN segmentation model

Reference images and diagrams. Click any image to view full resolution.

Diagram showing three VLANs separated by a router/firewall: Trusted (laptops, phones, NAS, HomePod), IoT (smart plugs, vacuums, bulbs, doorbells), and Guest (visitor devices). Trusted to IoT is allowed; IoT to Trusted is blocked; mDNS/SSDP is reflected between Trusted and IoT. — Original concept diagram (not vendor copyright). The router enforces firewall rules: Trusted → IoT is allowed (for control); IoT → Trusted is BLOCKED (segmentation); mDNS/SSDP is reflected between Trusted and IoT so Apple Home / Google Home / Chromecast still discover devices across the VLAN boundary.

Who this is for

Home operators with VLAN-capable routers (UniFi, OPNsense/pfSense, Mikrotik, OpenWrt) who want to isolate IoT/smart-home devices from the trusted home network without breaking Matter / Thread / Apple Home / Google Home / Chromecast discovery.

Outcome

A working three-tier home network: Trusted VLAN for laptops/phones, IoT VLAN for smart devices with blocked egress to Trusted, optional Guest VLAN for visitors. mDNS / SSDP reflection enabled so cross-VLAN discovery works for legitimate platforms.

Required inputs

VLAN-capable router or firewall (UniFi UDM, OPNsense, pfSense, Mikrotik, or OpenWrt with VLAN support).
Wi-Fi access points that support per-SSID VLAN tagging (most modern APs).
List of smart-home devices to move to IoT VLAN.
Concrete decision on whether cameras get a separate Camera VLAN or share IoT.

GuideFollow in order

Step-by-step procedure

Plan the VLAN layout before configuring anything

Do: Decide subnet ranges per VLAN (Trusted 192.168.1.0/24, IoT 192.168.20.0/24, Guest 192.168.30.0/24). Decide which devices belong in each tier.

Expected result: Written list of devices per VLAN with subnet planning.

If not: Don't start router config without this — moving devices between VLANs after the fact is more disruptive than planning right the first time.

Create the VLANs on the router

Do: Add the IoT VLAN (and optionally Guest, Cameras) in router admin. Set up DHCP for each. UniFi: Settings > Networks > New > VLAN ID; OPNsense: Interfaces > add VLAN; Mikrotik: /interface vlan add.

Expected result: Each VLAN has a working DHCP range; devices on the right VLAN get IPs in the right range.

If not: If DHCP isn't issuing IPs, check the VLAN is bound to the right interface and DHCP server is enabled on it.

Create the IoT Wi-Fi SSID and assign to IoT VLAN

Do: Wi-Fi controller > new SSID > assign to IoT VLAN. Don't broadcast SSID widely; use a different name from main SSID.

Expected result: Connecting a smart plug to the IoT SSID gives it an IP in the IoT range.

If not: If the device gets a main-LAN IP, the SSID isn't bound to the VLAN correctly.

Configure firewall rules: block IoT → Trusted

Do: Firewall > Rules > IoT or LAN_IN interface > Block IoT to Trusted RFC1918 ranges. Allow IoT → Internet. Allow Trusted → IoT (so phones can control IoT devices).

Expected result: From IoT VLAN: can reach internet but not Trusted LAN. From Trusted: can reach IoT and internet.

If not: If IoT can still reach Trusted, the firewall rule order is wrong (more-specific rules need to come first).

Enable mDNS / SSDP reflection between VLANs

Do: UniFi: Networks > IoT > enable mDNS Reflector. OPNsense: install Avahi service. Mikrotik: install avahi-daemon. Configure the daemon to reflect between Trusted ↔ IoT.

Expected result: From Trusted phone: Apple Home / Google Home / Spotify Connect / Chromecast finds devices on IoT VLAN. From IoT VLAN: limited cross-VLAN visibility (only mDNS/SSDP).

If not: If discovery doesn't work, check the reflector covers both directions (Trusted → IoT for queries; IoT → Trusted for responses).

Move smart-home devices to IoT SSID

Do: On each smart plug, voice assistant, robot vacuum, smart bulb hub: connect to the new IoT SSID. Many require factory-reset to change Wi-Fi networks.

Expected result: Each device gets an IoT-range IP; appears in its platform app as before; control works.

If not: If device fails to connect, check IoT SSID password is correct; some old devices don't support 2.4 GHz/5 GHz mixed networks — provide an IoT-specific 2.4 GHz-only SSID.

Test the boundaries

Do: From a phone on Trusted VLAN: ping a smart plug at its IoT IP (should succeed). From the IoT VLAN (or a tethered IoT device): try to reach the NAS LAN IP (should FAIL).

Expected result: Trusted → IoT works; IoT → Trusted blocked.

If not: If IoT reaches Trusted, firewall rule isn't active — recheck rule order and that it's applied to LAN_IN or equivalent direction.

Smart-home VLAN segmentation completeness check

Item	Status
IoT VLAN created with separate subnet	Done / Not done
IoT SSID created and assigned to IoT VLAN	Done / Not done
Firewall: IoT → Trusted RFC1918 BLOCKED	Done / Not done
Firewall: Trusted → IoT ALLOWED	Done / Not done
Firewall: IoT → Internet ALLOWED	Done / Not done
mDNS / SSDP reflection enabled between VLANs	Done / Not done
Smart-home devices moved to IoT SSID	Done / Not done
Test: Trusted → IoT ping succeeds	Done / Not done
Test: IoT → Trusted ping fails	Done / Not done
Test: Apple/Google Home discovery still works	Done / Not done

Commands and settings paths

Create IoT VLAN (UniFi)

Settings > Networks > New > VLAN ID 20

Where: In the UniFi controller / network application.

Expected: IoT VLAN appears in the network list with a DHCP range distinct from the main LAN.

Failure means: VLAN tag conflict or interface binding error.

Safe next step: Pick a different VLAN ID (any 2-4094); verify it doesn't collide with existing tagged traffic from the ISP modem.

Add firewall rule blocking IoT → Trusted

Firewall > Rules > LAN_IN > Block IoT → 192.168.1.0/24 (and other Trusted RFC1918)

Where: Router/firewall admin UI.

Expected: From an IoT VLAN device, ping to a Trusted LAN IP returns 'Destination Host Unreachable' or times out.

Failure means: Rule order is wrong (allow rules above the block), or interface binding is wrong.

Safe next step: Move the block rule above any broad-allow rules; confirm it's applied to the right interface direction (LAN_IN or equivalent).

Enable mDNS reflector (UniFi)

Settings > Networks > IoT > enable mDNS

Where: UniFi controller / network application.

Expected: From Trusted phone, Apple Home / Google Home / Spotify Connect finds devices on IoT VLAN.

Failure means: Reflector not enabled, or VLAN/SSID mapping wrong.

Safe next step: Verify mDNS is enabled on both Trusted and IoT networks (it's per-network); restart any platform apps to refresh discovery.

Test IoT → Trusted block from an IoT device

From a phone tethered to IoT SSID: `ping 192.168.1.10` (a Trusted LAN device)

Where: From an IoT VLAN client.

Expected: Ping fails (timeout or destination unreachable).

Failure means: Firewall rule isn't actually blocking; segmentation is incomplete.

Safe next step: Recheck firewall rule direction and interface assignment; verify the rule is enabled and processed before any allow-all rule.

Evidence to record

Screenshot of router VLAN list showing IoT VLAN created.
Screenshot of firewall rules confirming IoT → Trusted is blocked.
Screenshot of mDNS reflection enabled.
Test results: ping from Trusted to IoT succeeds; ping from IoT to Trusted fails; Apple Home / Google Home discovers IoT devices.

Common mistakes

Skipping mDNS reflection — Apple Home / Google Home / Chromecast won't work cross-VLAN without it.
Putting the smart-home hub (HomePod mini, SmartThings Hub) on IoT instead of Trusted — these are control devices; they belong with the trusted phones that command them, with IoT devices only as the targets.
Forgetting to set Trusted → IoT firewall rule to ALLOW — without it, you isolate the IoT VLAN even from the controlling phones.
Using a consumer router's 'guest network' as IoT segregation without verifying it actually blocks LAN access (some consumer guest networks don't).

Stop points

Stop before opening mDNS / SSDP reflection in both directions if you don't understand which devices need to be reachable from Trusted — over-broad reflection defeats the segmentation.
Stop before moving cameras to IoT without considering a separate 'Cameras' VLAN with stricter egress rules — cameras have specific risk patterns.
Stop before disabling firewall rules to debug — keep the IoT → Trusted block active; if something needs cross-VLAN access, add a specific allow rule.

Last reviewed

2026-05-18

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

NIST: Network segmentation guidanceUsed for the principle of segmenting IoT/smart-home devices from trusted networks; from NIST SP 800-207 Zero Trust Architecture.Ubiquiti / Home Assistant: IoT VLAN segmentation patternsUsed as a representative vendor example of VLAN-based IoT isolation; principles apply across routers that support VLAN tagging.Connectivity Standards Alliance: MatterUsed for Matter commissioning, fabric, and credential framing in smart-home pairing diagnostics.

FAQ

I have a consumer router that doesn't support VLANs — what's the next best thing?

Use the guest network feature as a basic IoT segregation: put smart plugs, voice assistants, and other untrusted devices on the guest SSID; keep laptops/phones on the main SSID. Guest networks block client-to-client and client-to-LAN traffic by default. You lose mDNS discovery between trusted phone and IoT devices (so Apple Home / Google Home control becomes harder), but you gain the security separation. For full smart-home function with segmentation, you eventually need a VLAN-capable router.

What about putting cameras on the IoT VLAN — same idea?

Cameras can go in IoT, but consider a separate 'Cameras' VLAN with even stricter egress rules. Many home cameras either (1) phone home to a cloud service in another country, (2) have known firmware vulnerabilities, or (3) have been involved in botnet activity. A 'Cameras' VLAN that only allows outbound to the specific NVR or cloud destination (and blocks everything else) is the strongest pattern. If you only have one camera and trust the vendor, IoT VLAN is fine.