Why your UniFi VLANs aren't doing what you think they are

What it looks like

A homeowner has invested in 10 Gigabit infrastructure — a NAS with a 10 GbE port, a workstation with a 10 GbE port, an aggregation switch with 10 GbE on the relevant ports. iPerf inside the same VLAN delivers near-line rate. The NAS, however, lives on its own VLAN (for isolation, for AppleTV scoping, for organisational reasons), and the workstation is on the trusted-devices VLAN. Backups crawl. Time Machine never finishes. iPerf between them tops out around 2.5 Gb and never moves.

Why it's happening

The traffic isn't staying on the switch. Every packet leaves the switch, transits the trunk up to the gateway, gets routed at Layer 3, transits the trunk back down, and re-enters the switch on the destination VLAN. Whatever speed the gateway's uplink to the switch is, that's the speed of all inter-VLAN traffic.

The Cloud Gateway Max's uplink to the switch in this scenario is 2.5 Gb. The 10 Gb ports on the switch are real, but only useful for traffic that stays inside a single VLAN. The same trap appears on the UDM Pro (whose internal switch backplane is Gigabit-uplinked), on the older USG family, and on any UniFi gateway whose LAN-side trunk to the access switch is smaller than the speed of the devices inside the VLAN.

The evidence

The canonical residential case study is the r/Ubiquiti thread “Don't be me! Performance implications of VLANs” — 451 score, 230 comments, flair: Solved.² The OP spent a week trying to figure out why 10 GbE gear couldn't break 2.5 Gb. Top-voted reply (693 score): “Layer 3 switch instead.” Second-most-voted reply (87 score): “Sounds like a misunderstanding of VLANs.” A related thread, “making an illegal u-turn” — 1,302 score, 140 comments — documents the workaround a homeowner built because UniFi only allows one IP per LAN interface, forcing a physical loop-back cable to make a second gateway interface usable.³ The top comments on that thread are entirely about the broadcast-storm and STP risks of the workaround. The underlying problem is the same: people doing 10-Gigabit things across VLANs that the gateway can't route at that speed.

Nothing in the UniFi UI warns about this. The switch reports 10 Gb on the port. The NAS reports 10 Gb. The link lights green. Throughput halts at gateway uplink speed, and the user is left scrolling forums.

The fix

Three options, in increasing order of effort:

• Don't cross VLANs for things that need speed.If two devices need to talk fast and there's no security reason to separate them, keep them on the same VLAN. VLANs are a tool, not a default. The Reddit consensus on this specific question is consistent: don't over-VLAN.
• Use a UniFi gateway with sufficient uplink.UDM Pro Max, UDM SE, UCG-Fiber, UCG Max have multi-gig LAN-side interfaces; if your inter-VLAN traffic is below that ceiling, the gateway can carry it without the hairpin biting. Check the actual port speed used as the trunk to your access switch, not the gateway's brochure-grade WAN speed.
• Move inter-VLAN routing to a Layer 3 switch.UniFi's Pro and Enterprise switches (USW-Pro-24, USW-Pro-48, USW-Enterprise, USW-Pro-Max) support Layer 3 routing on the switch backplane itself. Configured correctly, inter-VLAN traffic never transits the gateway uplink — it stays on the switch. This is the right call when you genuinely need both isolation and inter-VLAN speed.

One detail worth calling out: when you offload inter-VLAN routing to a Layer 3 switch, the gateway's firewall rules no longer see that traffic. The L3 switch is now the routing path. If you want firewall enforcement between two VLANs and backplane-speed throughput, you need either per-VLAN firewall features on the switch itself (Pro and Enterprise models support limited ACLs) or you need to accept that the gateway will be the bottleneck.

What it looks like

A homeowner adds an IoT VLAN, then a firewall rule: Allow IoT to reach the printer in the trusted VLAN. The rule is saved. The printer is still unreachable from the IoT VLAN. The rule looks correct in the UI. The rule is also in the wrong scope.

The three scopes

UniFi gateways evaluate LAN-side firewall rules in three independent scopes. The official Ubiquiti guidance on inter-VLAN behaviour lives on the Implementing Network and Client Isolation in UniFi page, which describes the Network Isolation feature and frames inter-VLAN traffic as a routed, rule-evaluated path.⁴ The three relevant scopes are:

• LAN IN — traffic from a LAN client toanother LAN destination (including the gateway as a routed hop). This is where almost every “allow VLAN A to reach VLAN B” or “block VLAN A from reaching VLAN B” rule belongs.
• LAN LOCAL — traffic from a LAN client to the gateway itself— its DHCP server, its DNS resolver, its management UI, its VPN server. Rules in LAN LOCAL control which VLANs can use the gateway's own services.
• LAN OUT — traffic originating from the gateway, going out to a LAN client. This is rarely what residential users need. If you've written a LAN OUT rule, double-check whether you actually meant LAN IN.

The mistakes

Three patterns repeat:

1. Allow rule in LAN OUT instead of LAN IN. Symptom: rule looks correct, never applies. The scope is the bug.
2. Missing Established/Related baseline. Symptom: outbound requests work but the responses appear blocked — HTTP times out at the firewall, DNS lookups return nothing. The first rule in LAN IN must be Accept Established/Related. Without it, every return packet from a connection initiated inside the VLAN is treated as new traffic and matched against the rules from scratch. UniFi ships pre-defined rules for some traffic classes (DHCP, ICMP, DNS in certain configurations), but the Established/Related rule is the one to put at the top explicitly.
3. Block rule in LAN IN that catches intra-VLAN traffic by accident.Symptom: a rule meant to block IoT from reaching trusted VLAN also stops IoT devices from talking to each other. The source/destination need to be set to specific networks, not just “Any.”

The fix

The working pattern for a residential four-VLAN home:

• LAN IN, rule 1: Accept Established/Related. Source: Any. Destination: Any. This is the baseline that makes everything else work.
• LAN IN, rules 2-n: explicit Source-Destination pairs for each cross-VLAN allow. “Trusted → IoT: Accept” for the homeowner's phone to reach the thermostats. “Trusted → AV: Accept” for the homeowner's phone to reach the AV processor. Everything else: omit.
• LAN IN, default: Drop. Anything not matched by an explicit Accept is dropped. This is the deny-by-default posture and is the right starting point.
• LAN LOCAL: restrict guest-VLAN access to the gateway. Guest clients need DHCP and DNS; they don't need to reach the management UI. Allow guest → gateway: DHCP, DNS. Drop the rest.
• LAN OUT: usually empty.

Order matters: rules are evaluated top-to-bottom. A broad Drop followed by a narrow Accept will not behave the way the wording suggests. Put specific Accepts above generic Drops.

What changed

UniFi Network 9.x introduced a top-level Network Isolation / Block Inter-VLAN Routing toggle on the per-network settings page — a single click that applies a global deny across all cross-VLAN traffic for that network. The toggle is attractive: turn it on, and the homeowner gets the isolation posture without writing a single firewall rule. Ubiquiti documents this feature on the Implementing Network and Client Isolation in UniFi page.⁴

The trap

With the toggle on, Allow Traffic Rules don't supersede it. In older versions of UniFi Network, an Allow Traffic Rule for a specific source-destination pair would override the global block; in 9.x, the behaviour is less consistent, and the community thread“Allow Firewall rule not working when Inter-VLAN Routing is blocked (UniFi Network 9.5.21) ” documents the regression with multiple user reproductions.⁵ Many older blog posts and guides on the internet still describe the old behaviour. The toggle has the same name and lives in roughly the same place; the semantics underneath have shifted.

Practical consequence: a homeowner who turns the toggle on, then adds a single Allow Traffic Rule (“let my phone on Trusted reach the cameras on IoT”), and finds it doesn't work, will not find a clear error message anywhere. The Allow rule exists. The toggle exists. They visibly conflict, but only one wins, and which one wins is no longer predictable from the UI.

The fix

Two stable patterns, depending on what the household needs:

• Pattern A — toggle on, no exceptions. Suitable for the Guest VLAN, where the policy is “nothing crosses, ever.” Turn the Network Isolation toggle on for the Guest network and write no rules at all. Don't mix it with Allow Traffic Rules for that same network.
• Pattern B — toggle off, explicit rules manage everything. Suitable for Trusted, IoT, and AV VLANs where some cross-VLAN traffic is legitimate. Leave the Network Isolation toggle OFF on those networks. Place an explicit Block all inter-VLAN traffic rule at the bottom of LAN IN. Place specific Allow rules above it. This is the deny-by-default pattern, expressed in rules the homeowner can read and reason about.

Both patterns are stable across Network 9.x versions. The pattern that breaks in 9.x is the hybrid one — toggle on, plus Allow rules, expecting the Allow rules to win. Don't build on that pattern in 2026, regardless of what 2023 guides say.

For the residential case, four VLANs is the usual shape:

• Trusted (VLAN 10, 192.168.10.0/24) — homeowner laptops, phones, personal devices.
• IoT (VLAN 20, 192.168.20.0/24) — cameras, doorbells, thermostats, smart speakers, smart appliances.
• AV / Automation (VLAN 30, 192.168.30.0/24) — Crestron, Control4, Savant, Lutron processor, AV gear, automation controllers.
• Guest (VLAN 40, 192.168.40.0/24) — visitor SSID. Client Isolation on. No path to any of the other three.

Firewall rules (LAN IN, in order — top wins):

1. Accept Established/Related — Any → Any.
2. Accept — Trusted → IoT (phone reaches thermostats / cameras).
3. Accept — Trusted → AV (phone reaches the AV processor).
4. Accept — AV → IoT (lighting / shade / climate integrations).
5. Drop — Guest → any internal network.
6. Drop — IoT → Trusted.
7. Drop — IoT → AV.
8. Drop — any → any (default catch-all).

Plus, in LAN LOCAL: Guest gets DHCP and DNS to the gateway; nothing else. The Trusted VLAN is the only one with access to the management UI.

And — separately, because this is a different finding — mDNS / Bonjour / Chromecast / AirPlay / Sonos requires the multicast DNS proxy enabled on the Trusted and IoT VLANs so the homeowner's phone can discover speakers and casting targets that live on the IoT side. That is its own audit finding and its own article.

One follow-on issue is worth flagging because it shows up the moment you build VLANs: AirPlay, Chromecast, Sonos, AirPrint, and most other smart-home discovery protocols are multicast. Multicast is, by definition, scoped to a single broadcast domain — a single VLAN. Once you split your network into a Trusted VLAN and an IoT VLAN, those discovery protocols stop crossing.

UniFi has an mDNS proxy (sometimes called the Bonjour reflector) that bridges multicast across VLANs you select. Ubiquiti documents the specific Sonos and AirPlay / Chromecast guidance in dedicated help-center articles — the fact that Sonos has its own KB on Ubiquiti's site is itself a sign of how often this comes up.⁶⁷ The Hookup's residential UniFi guide also documents the specific Chromecast / mDNS firewall rules that have to coexist with the proxy.⁸

We'll cover the multicast-across-VLANs problem in its own article — it's a distinct finding that we see almost as often as the three traps above. The brief version: enable the mDNS proxy on the trusted and IoT VLANs, allow Established/Related and the appropriate Chromecast / Sonos ports across, and don't enable mDNS proxy on the Guest VLAN unless you explicitly want guests to discover your household's speakers.

Most homes don't need a Layer 3 switch. The cases where the answer flips:

• 10 Gigabit (or faster) fabric internal to the home, with VLAN boundaries between devices that need to talk at full speed. NAS on its own VLAN, workstation on Trusted, doing 4K-video editing or large dataset moves. Without an L3 switch, the gateway is the bottleneck. With one, the switch backplane carries the traffic.
• Multi-tenant or large-residence deployments where inter-VLAN traffic is high-volume by design — separate dwellings sharing a single network spine, but with isolation between them.
• Mixed business / residential setups in homes that double as production studios, where a Pro switch was already in the rack for other reasons.

The cases where it's wasted money:

• 1 Gigabit WAN, 1 Gigabit LAN, four-VLAN security setup. The WAN is the ceiling anyway. The gateway routes inter-VLAN at line rate; the L3 switch is a solved-problem-twice.
• Households where inter-VLAN traffic is rare and small. Most residential traffic goes north-south (to the internet), not east-west (to other rooms). If your inter-VLAN volume is a rounding error, the L3 switch is a rounding-error fix.

And one detail worth repeating: with an L3 switch handling inter-VLAN routing, the gateway's firewall no longer sees that traffic. Pro and Enterprise switches do support per-port and per-VLAN ACLs, but the configuration surface is different, and most of the UniFi blog content on residential firewall rules assumes the gateway is the routing point. If you move routing to the switch and you care about firewall enforcement between VLANs, you'll need to configure ACLs on the switch explicitly — they don't inherit from the gateway.

• UniFi Network's firewall UI changes meaningfully between major versions.The specifics of where rules live, what the toggles are called, and how Traffic Rules vs Firewall Rules interact have shifted across 7.x, 8.x, and 9.x. Screenshot-driven guides on the internet age fast. Test the actual rule behaviour on your build; don't trust 2023 advice on a 2026 deployment.
• The Network 9.x precedence behaviour around the Block Inter-VLAN Routing toggle may be a Ubiquiti bug rather than designed behaviour. We've cited the community thread that documents it, but Ubiquiti has not formally addressed it in release notes that we've found. The two stable patterns described above (toggle-on-no-exceptions and toggle-off-explicit-rules) work regardless of whether the 9.x behaviour is a bug or a feature.
• Layer 3 switch capability requires explicit configuration.Owning a UniFi Pro or Enterprise switch is not the same as having inter-VLAN routing on the switch. The routing has to be turned on, the per-VLAN gateway IPs configured on the switch, and the default route on the gateway updated. Just slotting in a Pro switch doesn't move inter-VLAN traffic off the gateway.
• The four-VLAN layout above is a typical shape, not a prescription.Some homes collapse IoT and AV into a single VLAN; some split IoT further into “trusted IoT” (the homeowner-installed devices) and “untrusted IoT” (the cheap doorbell from a vendor nobody's heard of). The principles in this article apply to any of those layouts.
• Reddit and forum threads are evidence of what's common, not population-level statistics. The vote counts and comment volumes cited here are signal that the trap is real and recurrent, not a precise measurement of how many homes are affected.

None of this changes the underlying picture. VLANs are easy to create on UniFi. Making them perform, enforce, and route correctly is harder, and the three traps in this article are where most homes get them wrong.