UniFi VLAN Segmentation: IoT, Guest, and Trusted

A flat network — every device on one subnet, everything able to talk to everything — is fine until it isn’t. The moment you add a cheap smart bulb, a guest’s laptop, or a camera you don’t fully trust, “everything can reach everything” stops being a convenience and becomes the problem. VLANs are how you fix that on UniFi without buying more hardware. This guide is the model, not a click-by-click, because the why is what people get wrong.

What a VLAN actually buys you

A VLAN is a separate Layer 2 network running over the same physical switches and access points. Devices in different VLANs are, by default, in different broadcast domains and different subnets — they can’t reach each other unless a router explicitly allows it.

The value isn’t the VLAN itself. It’s the default deny between segments. Segmentation only does something if traffic between segments is blocked by default and you allow exceptions deliberately. A VLAN with a firewall rule that says “allow all between VLANs” is just extra configuration buying you nothing.

A sane three-to-four VLAN model for homes/small offices

You don’t need a dozen VLANs. Most networks are well served by:

• Trusted (Management/LAN): your computers, phones, the UniFi controller, NAS, printers you actually administer. The segment you’d be comfortable initiating connections from.
• IoT: smart home gear, TVs, voice assistants, anything that “phones home” and you can’t patch. Internet access yes; lateral access to Trusted, no.
• Guest: visitors’ devices. Internet only. No access to Trusted, IoT, or other guests (client isolation).
• Cameras (optional but recommended if you run UniFi Protect): NVR/cameras isolated so a compromised camera can’t roam your network, and so camera traffic doesn’t flood other segments.

The principle behind the split: group devices by how much you trust them and what they legitimately need to reach, not by device category for its own sake.

Tagged vs untagged ports — the part that confuses everyone

This trips up nearly everyone configuring UniFi switching the first time:

• An untagged (sometimes called “native” or the port’s primary network) VLAN is what a device that knows nothing about VLANs sees. A laptop plugged into a port set to untagged VLAN 20 is simply “on VLAN 20” — it sends no VLAN tags and doesn’t need to.
• A tagged VLAN means frames carry an 802.1Q tag identifying the VLAN. You use tagged VLANs on links that must carry multiple VLANs: switch-to-switch uplinks, and the link to an access point that broadcasts multiple SSIDs mapped to different VLANs.

Rules of thumb:

• Edge port for a single dumb device (PC, printer, console): set its network to the one VLAN that device belongs to (untagged). Don’t tag anything.
• Uplink between switches: carry all the VLANs that need to traverse it as tagged, with a sensible native VLAN.
• Port to a UniFi AP serving multiple VLAN’d SSIDs: the AP needs those VLANs tagged so it can map each SSID to its VLAN.

The classic mistake is tagging a VLAN on an access port to a single device that doesn’t understand tags — the device then can’t communicate. If one device, one VLAN: untagged.

Mapping Wi-Fi to VLANs

On UniFi, each SSID can be bound to a network/VLAN. So you typically create:

• A Trusted SSID → Trusted VLAN
• An IoT SSID → IoT VLAN
• A Guest SSID → Guest VLAN, with guest/client isolation enabled

The access point’s switch port must carry those VLANs (tagged), and the AP must be on a UniFi setup where the gateway routes and filters between them. The SSID is just the entry point; the segmentation is enforced by routing + firewall, not by having separate SSIDs alone. Separate SSIDs with no firewall rules between their VLANs is theater.

The firewall rules that make it real

Segmentation is only as good as the inter-VLAN rules. With a UniFi gateway doing the routing, the model you want is default deny between VLANs, with narrow allows:

1. Block inter-VLAN by default. New traffic initiated from IoT/Guest/Cameras toward Trusted should be dropped.
2. Allow established/related back. When Trusted initiates a connection out to, say, an IoT device, the return traffic must be allowed (stateful return), without opening IoT→Trusted initiation.
3. Allow only the specific exceptions you need. Examples: Trusted → IoT on the ports your home-automation hub needs; Trusted → Cameras for the NVR UI; a specific printer reachable from Trusted only.
4. Guest gets internet only. No inter-VLAN, no reaching the gateway’s admin, client isolation on.

The mental model: connections flow from more-trusted to less-trusted by exception, and return traffic for those is permitted statefully. Less-trusted segments never initiate into more-trusted ones. If you can’t articulate which direction a rule allows, you don’t yet have a rule you should keep.

Common ordering and rule mistakes

• Rules are evaluated in order. A broad allow placed above your deny defeats the deny. Put specific allows above the catch-all deny, and make sure the deny exists.
• Forgetting DNS/DHCP. Each VLAN needs to reach DHCP/DNS (typically provided by the gateway for that VLAN). Blocking a segment so hard it can’t get an IP or resolve names is a self-inflicted outage.
• Locking yourself out. Don’t apply a deny that blocks your management device from the controller before you’ve confirmed the allow path. Stage changes; keep a way back in.
• mDNS/discovery across VLANs. Casting and smart-home discovery often rely on mDNS, which doesn’t cross VLANs by default. If “my phone on Trusted can’t see the TV on IoT,” that’s expected — you either relax that specific path deliberately or accept the separation. Don’t fix it by collapsing the VLANs.

A pragmatic rollout

1. Start with Trusted + Guest only. Get a clean default-deny working and verified.
2. Add IoT, move noisy/untrusted devices over, confirm they still reach the internet and nothing reaches Trusted.
3. Add Cameras if you run UniFi Protect, isolated, with only the NVR UI reachable from Trusted.
4. Add allow exceptions one at a time, each justified by a specific need, each placed above the deny.

Done this way, segmentation is robust and debuggable. Done as “lots of VLANs, allow-all between them,” it’s just complexity with none of the benefit. For the groundwork this builds on and the pieces it touches, see controller hosting options, the guest network and captive portal done properly, switch port and PoE planning, and the rest of our UniFi guides.