I created VLANs in UniFi but devices can still reach everything. Why?

Because on a current UniFi gateway (Zone-Based Firewalls, Network 9.0+), new networks land in the Internal zone by default, and the shipped zone matrix sets Internal to Internal traffic to Allow All. Creating VLANs separates broadcast domains and addressing; it does not, by itself, isolate anything. Isolation arrives only when you add policy: placing the guest network in the Hotspot zone (whose defaults block initiation to Internal), using Network Isolation, a custom zone, or explicit firewall policies. Ubiquiti's own VLAN documentation notes the mirror image: most third-party gateways block inter-VLAN communication by default, which is why tutorials written for other gear describe the opposite behaviour.

Why did printing and casting break after I set up VLANs, and how do I fix it?

Printers, AirPlay, Chromecast and similar services are discovered by multicast DNS (mDNS), which does not cross VLAN boundaries on its own. UniFi's documented answer is the mDNS Proxy setting per network (Settings > Networks), which forwards mDNS traffic between selected networks and requires a UniFi gateway. Its modes are All (the default), Auto (a predefined service list including AirPlay, Chromecast, the AirPrint/IPP printer family, HomeKit and others), and Custom. Ubiquiti's broadcast-traffic guidance prescribes exactly this design: put printers, speakers and cameras on a dedicated VLAN and use mDNS relaying only where needed. Also check Multicast & Broadcast Control settings — Ubiquiti documents that they can block cross-AP discovery and even starve DHCP.

How do I avoid locking myself out when setting up VLANs?

Move management last — or never. UniFi devices are managed over the untagged (native) network by default, and Ubiquiti's Network Override documentation warns that a wrong native/tagged configuration on the upstream port 'may require a physical reset'. The safe build order: back up; create the new networks empty; zone the guest network; build SSIDs; keep AP uplink ports' native network unchanged while adding tagged VLANs; move wired IoT and cameras; apply policy; enable mDNS where needed; and only then — with a verified second management path — consider touching anything management-related. If you do strand a device, recovery is re-patching it to a port whose native network is your main network, reverting through a surviving path, or a physical reset and re-adoption.

UniFi · VLANs · Small business

UniFi VLANs for a small business — segmentation that actually segments

First published 20 October 2026 · Zone defaults, mDNS mechanics and port behaviour from Ubiquiti's Zone-Based Firewall, Virtual Networks, Switch Settings, Isolation and Broadcast Traffic documentation, read in full for this guide.

Do not fix the wrong thing first. The most misunderstood fact in UniFi segmentation: under Zone-Based Firewalls, new networks land in the Internal zone, and the shipped matrix is Internal → Internal: Allow All. So you can build four beautiful VLANs, move everything, and have isolated exactly nothing. VLANs are plumbing; policy is the lock. This guide does both, in the order that never locks you out.

The map — four networks, each with a reason

Network	Who lives there	Why
Main / Staff (the default network)	Staff PCs, the printer (see below), POS back-office, and management — the controller and APs are managed on the untagged network by default	It's the network everything already trusts; the build starts by leaving it alone
Guest	Customer devices via the guest WLAN	Zoned as Hotspot (our guest guide covers its portal + isolation verification)
IoT / Media	Smart plugs, TVs, speakers, thermostats, the gadgets with 2019 firmware forever	The least-maintained devices on your premises get the least-trusted network — reachable from staff (casting, control), initiating almost nothing back
Cameras	Protect cameras and their console/NVR together	Protect expects its cameras reachable/same-network as the host (see the Protect guide); a camera VLAN that strands the console is the classic self-own

The printer decision, once: keep it on Main and printing can never break (simplest, and the printer is a relatively trusted device) — or move it to IoT for purity and pay the mDNS + policy tax documented below. For most small businesses: Main. Decide now; the ladder assumes it.

The build ladder — management moves last (i.e., never)

Back up the controller. Screenshot port assignments. This ladder is safe; the backup is for your confidence, which you'll need at rung 6.
Create IoT and Cameras networks (empty). Note their VLAN IDs and DHCP ranges — every UniFi network gets its own DHCP by default.
Zone the Guest network into Hotspot (Network 9 / ZBF) — or apply Network Isolation — so guest policy exists before guests move.
Build the SSIDs bound to their networks (IoT WLAN; guest already exists). PPSK (one SSID, per-device passwords landing on different VLANs) exists as a documented UniFi option for tidier fleets — optional.
AP uplinks: add the new VLANs as tagged on AP switch ports. Do not change the native network on those ports — devices are managed over the untagged network; Ubiquiti's Network Override text warns a wrong native/tagged setup “may require a physical reset.”
Move wired IoT (TVs, speakers) by changing their switch ports' assigned network. Verify: each gets an IoT-range address.
Move cameras + console together into Cameras. Verify: Protect shows all cameras connected before continuing.
Apply inter-VLAN policy (next section). Verify with the matrix.
Enable mDNS Proxy between Main and IoT (below).
Stop. Management stays on Main. There is no rung 11 where you re-VLAN the controller for elegance.

The policy step — turning plumbing into segmentation

Defaults, from Ubiquiti's shipped zone matrix: Internal may initiate to Internal, Gateway, VPN, Hotspot and DMZ (Allow All); External is policy-driven. Hotspot may only return traffic to Internal and is blocked to Hotspot/DMZ peers. Your deliberate work:

Guest: Hotspot zone (done at rung 3) — verify, don't assume.
IoT: the asymmetric pattern — staff (Internal) may initiate to IoT; IoT may not initiate to Internal. ZBF's intra-zone filtering with Auto Allow Return Traffic produces exactly this staff→IoT-answers, IoT→staff-blocked shape; Network Isolation is the blunter one-click alternative where it fits. Build it as an explicit policy set (or a custom zone) so the intent is readable later.
Cameras: initiate to almost nothing; the console reaches cameras, Protect viewers reach the console.
The printed warning (Ubiquiti's own caution): blocking traffic to the Gateway zone “may disrupt critical network functions like DHCP and DNS.” Every VLAN's DHCP/DNS flows to the gateway — a heroic block-all that includes Gateway is an outage with extra steps.

The breakage catalogue — and the documented cures

It broke	Mechanism	Cure
Printer vanished from phones/PCs	mDNS discovery doesn't cross VLANs (yours moved to IoT, or clients did)	mDNS Proxy per network (Settings → Networks, UniFi gateway required): All (default), Auto (predefined list incl. AirPlay, Chromecast `_googlecast`, the AirPrint/IPP printer family, HomeKit, Sonos, Matter), or Custom. Use Auto/Custom — relay only where needed
Casting to the TV gone	Same mDNS wall, Chromecast/AirPlay services	Same mDNS answer — it's precisely what the Auto list exists for
IoT gadget “on Wi-Fi but dead”	Now isolated correctly — and its app needed phone↔device initiation the policy denies; or Multicast & Broadcast Control is blocking discovery/DHCP (a documented side-effect)	Decide per service: staff-initiated pattern usually satisfies apps; check the multicast controls before loosening policy
POS terminal lost its fixed address	New network = new DHCP range	Reserve/re-set the static address in the new network before the lunch rush — plan POS moves like maintenance windows
All cameras vanished in Protect	Cameras moved, console didn't (or vice versa)	Rung 7's discipline: console travels with its cameras; verify before policy
You locked yourself out	Changed the native/management network on the port your access hangs off	Rescue ladder: re-patch the device to a Main-native port → revert through any surviving management path → physical reset + re-adopt (our recovery guide)

Verify — the reachability matrix (service-level, not just ping)

From → To	Must be
Staff → Internet, printer (print a page), POS back-office, IoT (cast something), Cameras console (view a camera)	Works
Guest → Internet	Works
Guest → printer / office PC / NAS / a camera / gateway admin	Blocked (any success here is a security hole, not a convenience)
IoT device → Staff PC (initiate: it should never try — simulate with a laptop placed on IoT)	Blocked
Laptop-on-IoT → printer's IP directly	Blocked by policy (discovery relay ≠ open access)

A “Works” cell failing is a build error; a “Blocked” cell succeeding is a security hole. Both get fixed before this project is called done.

FAQ

Does PCI/payment compliance require the POS VLAN?

No Ubiquiti source says so, and neither will we — card-compliance obligations come from your processor/acquirer and assessor, not from a networking vendor. Segmentation is good hygiene regardless; just don't cite a requirement nobody issued.

Should I fear “VLAN hopping” attacks?

Ubiquiti's documentation doesn't treat it as a practical exposure for this design; your real documented exposures are the three boring ones this guide closes: Allow-All defaults left standing, multicast controls mis-set, and management reachable from guest space. Fear accurately.

Third-party gateway instead of UniFi?

Then invert one assumption: Ubiquiti's VLAN article notes most third-party gateways block inter-VLAN traffic by default, and UniFi's mDNS Proxy requires a UniFi gateway — your segmentation may start isolated and your printer fix lives in the other vendor's settings.

Sources

Ubiquiti Help Center — Zone-Based Firewalls (default matrix, intra-zone filtering, return-traffic behaviour, Gateway-zone caution), Creating Virtual Networks, Switch Settings (native/tagged, Network Override warning, mDNS Proxy modes), Implementing Isolation, Managing Broadcast Traffic (the dedicated-VLAN + selective-relay pattern, multicast-control caveats) · This site's Packs #6/#24/#29 (inform path, Protect networking, guest layers).

Verification note: zone defaults and mDNS modes were confirmed from Ubiquiti's documentation on 20 October 2026. Whether mDNS relay crosses a Network-Isolation boundary is not documented and is not promised here; fine-grained blog firewall recipes are practice, with only their mechanisms stated as fact.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.