IoT Security: Isolate Smart Devices via VLAN

Another box arrived — a smart plug, a camera, a voice assistant — and before it finished pairing you had the same thought you had with the last one: this thing now shares a network with the laptop that has your tax documents on it. That thought is correct, and the fix isn't a slogan.

TL;DR

A guest-network toggle is not the same as a VLAN — on most consumer routers it still allows some east-west chatter between "isolated" devices.
Real isolation needs 802.1Q VLAN tagging on a managed switch plus explicit inter-VLAN firewall rules, not just a checkbox.
The rule set that matters: block IoT → trusted, allow trusted → IoT for control apps, allow IoT → internet only.
Isolation you haven't tested is a guess. Verify it with a port scan from inside the IoT VLAN.
This stops lateral movement — it does not patch the device or protect its cloud account.

KEY-STAT: 29 — average smart-home cyberattacks per US household per day in 2025, a number that kept climbing into early 2026.

Why IoT devices need their own network

Smart plugs, cameras, and voice assistants have a worse patch record than almost anything else on a home network. Firmware update cadence varies wildly by manufacturer, as covered in our router firmware guide — but IoT devices are consistently the worst offenders, often shipping with default credentials and receiving security patches rarely, if ever.

The risk isn't that any single smart plug gets compromised — it's what happens next. If that plug sits on the same flat network as your laptop or your homelab, a compromised device can scan, probe, and pivot toward everything else. Segmentation doesn't stop the plug from getting attacked. It stops the plug from being a launchpad.

Guest network vs. VLAN: what actually isolates traffic

Most "put IoT on its own network" advice stops at flipping the guest-network toggle built into consumer routers. That's better than nothing, but it isn't the same guarantee a proper VLAN gives you:

Approach	Requires	Blocks IoT → trusted traffic	Blocks IoT → IoT traffic	Survives a compromised IoT device
Guest network toggle	Any consumer router	Usually	Rarely — most guest networks are one flat segment	Partial
802.1Q VLAN + firewall rules	VLAN-capable router/firewall + managed switch	Yes, explicitly	Yes, per-rule	Yes

The gap that matters most: on a guest network, your smart camera and your smart plug are usually still on the same segment as each other, with no rule stopping one from probing the other. A VLAN with explicit rules closes that gap.

My setup: a real router behind the FRITZ!Box, plus a managed switch

My FRITZ!Box handles the WAN connection and Wi-Fi, but it doesn't do real 802.1Q VLAN tagging — most consumer ISP routers don't. So the actual routing and firewalling happens one hop in: a pfSense VM running in my Proxmox homelab, connected to an 8-port managed switch (a TP-Link TL-SG108E, the cheapest common switch that does real VLAN tagging) that fans out to the rest of the house.

That split — dumb router for WAN, a real firewall for everything internal — is also what makes the rest of this guide possible. Three VLANs, tagged at the switch:

VLAN 10 (Trusted):  laptop, phone, Proxmox management interface, NAS
VLAN 20 (IoT):       smart plugs, cameras, voice assistants, smart TV
VLAN 30 (Guest):     visitor Wi-Fi, no LAN access at all

VLAN tagging config

On the managed switch, the uplink port to the pfSense VM is a trunk carrying all three VLAN tags; each access point or wired IoT port is set to untagged access mode on VLAN 20:

TP-Link TL-SG108E -- port config
Port 1 (uplink to pfSense):  Trunk, tagged VLAN 10/20/30
Port 2 (IoT access point):    Access, untagged VLAN 20
Port 3 (trusted wired):       Access, untagged VLAN 10
Port 4 (guest access point):  Access, untagged VLAN 30

pfSense -- Interfaces > VLANs
VLAN 10  Parent: igb1  Description: Trusted
VLAN 20  Parent: igb1  Description: IoT
VLAN 30  Parent: igb1  Description: Guest

Each VLAN then gets its own interface in pfSense with its own subnet and its own firewall rule set — that last part is the piece a guest-network toggle can't give you.

Inter-VLAN firewall rules that matter

The VLANs alone don't isolate anything — routers happily forward traffic between them unless you tell them not to. The rules that do the actual work:

Rule	Direction	Action
Block IoT → Trusted	VLAN 20 → VLAN 10	Deny
Allow Trusted → IoT	VLAN 10 → VLAN 20	Allow (so phone apps can still control devices)
Block IoT → IoT broadcast/multicast beyond mDNS needs	VLAN 20 → VLAN 20	Deny except required discovery ports
Block IoT → Guest	VLAN 20 → VLAN 30	Deny
Allow IoT → Internet	VLAN 20 → WAN	Allow
Block Guest → Trusted/IoT	VLAN 30 → VLAN 10/20	Deny

Tip

Order matters in pfSense — put the specific "block" rules above any broader "allow" rule on the same interface, or the broad rule will match first and the block never fires.

That single "allow Trusted → IoT" rule is why my phone can still open the camera app or toggle a smart plug from VLAN 10 — the isolation is one-directional, which is the point.

Verifying isolation actually works

A firewall rule you haven't tested is a hope, not a fact. After setting this up, I ran a scan from a laptop temporarily connected to the IoT VLAN, aimed at my trusted-VLAN NAS:

$ nmap -p 22,80,443,445 192.168.10.20
Starting Nmap ...
Nmap scan report for 192.168.10.20
Host seems down. If it is really up, but blocked by
an inline firewall, add -Pn

"Host seems down" from inside the IoT VLAN, while the same scan from the trusted VLAN returns open ports normally, is the confirmation that matters — the rule is actually dropping the traffic, not just sitting unused in a rule list. I re-run this check any time I add a new inter-VLAN rule, because a typo in a subnet mask is a silent failure mode: the rule looks correct and does nothing.

Warning

The most common mistake here isn't a missing rule — it's a rule with the wrong direction or an "any/any" allow rule left over from testing that quietly cancels everything below it. Check rule order after every change.

What this doesn't fix

VLANs stop lateral movement across your network. They do not patch the device's firmware, and they do not protect the vendor's cloud account behind the app that controls your camera — if that account is compromised, the attacker doesn't need your network at all. Segmentation is one layer, alongside keeping WPA3 on your wireless and actually applying firmware updates when they ship — not a replacement for either.

Frequently asked questions

Do I need a managed switch for IoT VLANs, or does a guest network work?

A guest-network toggle is a real improvement over nothing and is the right starting point if you don't own VLAN-capable hardware. But most consumer guest networks are a single flat segment — devices on it usually can't reach your trusted network, but they often can reach each other. A managed switch with 802.1Q tagging, paired with a router or firewall that supports VLAN interfaces, is what gets you per-device, per-direction rules instead of one broad toggle.

Can smart home hubs still control IoT devices on a separate VLAN?

Yes, with one explicit allow rule: trusted-VLAN traffic toward the IoT VLAN. Your hub, phone, or tablet stays on the trusted VLAN and is allowed to reach devices on the IoT VLAN — the isolation only blocks the reverse direction, which is the direction that matters for containing a compromised device.

Does putting IoT devices on a VLAN slow them down?

No — VLAN tagging adds a few bytes to each frame and is handled in switch/router hardware at line rate. In over a year running this setup, I've seen no measurable latency difference on smart-home traffic versus the flat network it replaced.

What's the practical difference between a guest network and a VLAN for IoT isolation?

A guest network is usually a pre-built, simplified VLAN with one fixed rule set the manufacturer chose for you. A VLAN you configure yourself lets you write per-direction rules — including the "trusted can reach IoT, IoT can't reach trusted" split that most guest-network implementations don't offer.