UniFi Guest Networks and Captive Portals: Isolation, Bandwidth Limits, and Hotspot Configuration

Have you ever traced a printer discovery broadcast back to the guest SSID and found out why? If you run a small-business UniFi site, there is a good chance your guest network is doing less isolation work than you assume.

The Guest Network toggle in UniFi Network is not a single control. It is a bundle of behaviors — client isolation, guest control firewall rules, portal authorization, and optional rate limiting — and each one of them can be misconfigured independently while the SSID still says "Guest" in the UI.

This guide walks the four decisions that actually determine whether your guest traffic is contained: the VLAN and isolation model, the guest control rule set, the hotspot portal type, and the bandwidth profile. Treat each one as a configuration decision with a rationale behind it, not a checkbox you flip on Friday afternoon.

The first failure mode is the simplest: the guest SSID was never given its own VLAN. It sits on the default network, which means every guest device shares a broadcast domain with your POS terminals, NAS, and IP cameras.

Enabling the Guest Network checkbox on the SSID applies client isolation and the guest control rule set, but it does not by itself move traffic into a separate Layer 2 segment. If the SSID's network assignment still points at your default LAN, guest devices pull DHCP from the same scope your servers use.

The second failure mode is subtler. Guest control rules in UniFi are written against RFC1918 destinations by default — they block guests from reaching private address space — but any service you have exposed on a public IP, including your own WAN address, is still reachable from the guest VLAN unless you add an explicit rule.

A third leak path is mDNS and multicast. If you have enabled mDNS forwarding or IGMP snooping settings that span networks, Bonjour discovery can cross segments even when unicast traffic is correctly firewalled.

The fix in every case starts upstream of the guest toggle. Build the guest network as a real VLAN first — the same way you would build any other segment, per how VLANs work in a UniFi deployment — and then layer the guest behaviors on top of it.

A practical sanity check: connect a laptop to the guest SSID and try to reach your gateway's management address, your NAS share, and a camera's web UI. If any of the three answers, your isolation is not doing what the UI implies.

These are two different controls that people routinely conflate, and getting them confused is how a guest network ends up half-secured.

Client isolation operates at the wireless layer. It prevents two devices associated to the same SSID from talking to each other directly, which stops guest-to-guest lateral movement — one compromised phone cannot scan the other devices in the lobby.

Network isolation operates at the routing layer on the gateway. It prevents the guest VLAN from initiating traffic toward your other VLANs, which is what stops guest-to-production movement.

You need both, and enabling one does not imply the other. A guest SSID with client isolation but no network isolation lets a guest device reach your Protect NVR. A guest VLAN with network isolation but no client isolation lets guests scan each other, which matters in any waiting room, cafe, or coworking space where devices you do not control sit side by side.

On recent UniFi Network versions, isolation is exposed both as the SSID-level guest toggle and as a per-network Isolate Network setting under the VLAN's configuration. The per-network control is the stronger one because it is enforced by the gateway regardless of which SSID or wired port the traffic arrives on.

That wired-port detail matters more than people expect. If you have tagged the guest VLAN onto a conference-room wall jack for a presentation drop, SSID-level isolation does nothing for that port — only the network-level rules apply.

Here is the decision in practice: set the guest VLAN to isolated at the network level, then enable the guest SSID toggle on top of it for the wireless-layer protection. Belt and suspenders is the correct posture here because the two controls cover different attack paths.

UniFi's guest control section holds a pre-authorization access list and a post-authorization restriction list, and most misconfigurations live in the first one.

Pre-authorization access defines what a guest device can reach before it has completed the portal flow. You need entries here for anything the portal itself depends on — the captive portal host, any external payment or voucher processor, and DNS.

If your portal uses a hosted landing page, a Facebook Wi-Fi style social login, or an external RADIUS server, those endpoints must be reachable pre-auth or the portal will hang on a blank page. This is the single most common reason a captive portal "doesn't load" after a config change.

Post-authorization restrictions define what an authorized guest still cannot reach. The default set blocks RFC1918 space — 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 — which covers the common cases but leaves gaps.

Things worth adding to the post-auth restriction list include but are not limited to:

• Your own WAN IP address. Guests hairpinning to a port-forwarded service on your public address is a real path, and RFC1918 rules do not cover it.
• The 169.254.0.0/16 link-local range. Useful for blocking some discovery and auto-config behaviors.
• Any carrier-grade NAT range your ISP uses, typically 100.64.0.0/10, if your gateway sits behind CGNAT.
• Management VLANs at other sites reachable over a site-to-site tunnel, if your gateway participates in one.

That last one is the case people miss on multi-site deployments. A guest at Branch A whose traffic can traverse the VPN to Branch B's LAN is a genuine cross-site exposure, and the default guest rules say nothing about it.

After you have written the list, verify it from a client rather than from the UI. Reading your own rules back tells you what you intended; a nmap sweep from a guest-connected laptop tells you what the gateway actually enforces.

If you are also running intrusion detection, remember that guest traffic counts toward your gateway's inspection load — see how IDS/IPS affects UniFi gateway throughput before you assume the guest VLAN is free capacity.

UniFi's hotspot portal supports several authentication models, and the right one depends on how much friction your guests will tolerate and what you need to prove afterward.

No authentication with a simple landing page is the lowest-friction option. The guest sees terms of service, clicks through, and is on. It gives you a click-wrap acceptance record and a branded touchpoint, and nothing else.

Password authentication uses a single shared passphrase presented at the portal. It is operationally simple for a cafe or a small office, but it ages badly — the password circulates, and rotating it means retraining staff every time.

Voucher authentication generates time-limited or quota-limited codes that staff hand out individually. This is the right answer for hotels, clinics, and anywhere a guest session should have a defined end. Vouchers can carry their own duration, data quota, and bandwidth limits independent of the SSID-wide profile.

External portal server hands the authorization decision to a system you run or subscribe to. Use it when you need marketing integration, PMS integration at a property, or a custom consent flow your compliance team wrote.

RADIUS authentication validates guest credentials against a RADIUS server, which is the model to use when guests are actually a known population — contractors, students, or member organizations — rather than anonymous walk-ins.

A note on the portal mechanics that trips people up: captive portal detection relies on the client OS probing a known URL and getting an unexpected response. If your guest VLAN's DNS is being intercepted, or if you have forced DNS over HTTPS at the gateway, the probe can succeed silently and the portal never pops.

HTTPS redirection is the other common snag. Modern clients rarely make plaintext HTTP requests on their own, so relying on an HTTPS redirect means the guest may see a certificate warning; a landing page served over the gateway's own hostname with a valid certificate avoids the ugly interstitial.

Whichever model you pick, keep the pre-authorization access list aligned with it. Voucher and password portals are self-contained on the gateway, while external portal and RADIUS models both need explicit pre-auth reachability to their servers.

Rate limiting on a guest network is not primarily about being stingy. It is about making sure one guest streaming 4K or running a cloud backup cannot degrade the production traffic that pays the bills.

UniFi applies bandwidth limits through a per-client rate limit profile attached to the WLAN or the user group. The important detail is that the limit is per client, not per SSID — ten guests on a 10 Mbps profile can collectively consume 100 Mbps if your WAN allows it.

That per-client behavior means the profile number should be derived from your WAN capacity divided by a realistic concurrent-guest count, with headroom reserved for production. If you have a 300 Mbps circuit and expect twenty concurrent guests, a 10 Mbps per-client cap bounds the worst case at roughly two-thirds of your link — still too aggressive for most sites, and a signal to either lower the cap or add a second layer of control.

Here is the practical construction sequence:

• Measure your actual WAN throughput first. Use the gateway's speed test, not the number on the ISP invoice, and run it at a busy hour rather than at 6 AM.
• Reserve production headroom explicitly. Decide what fraction of the circuit guests may consume at peak, and size the per-client number against that fraction rather than the full pipe.
• Set download and upload separately. Upload is usually the scarcer resource on cable and DSL circuits, and an uncapped guest upload is what saturates an asymmetric link.
• Attach the profile to the user group, not just the WLAN, so wired guest ports inherit the same limit as wireless clients.

Voucher-based limits are worth calling out separately. A voucher can carry its own bandwidth and data quota, which means you can run a permissive default profile for short sessions and a tighter one for all-day passes without creating a second SSID.

The airtime side of the problem is separate from the rate limit. A guest device connecting at a low data rate consumes disproportionate airtime and slows every other client on the radio, which is an AP capacity and placement issue rather than a bandwidth one — choosing the right UniFi access point and reading the roaming and band steering behavior matter as much here as the numbers you type into the profile.

One more consideration for sites with heavy AP counts: guest SSIDs broadcast from every AP by default, which means every beacon frame carries them. On a dense deployment where you are already watching PoE budget and switch capacity, limiting the guest SSID's AP group to the APs that actually cover public areas reduces both overhead and exposure.

Every guest network change deserves a client-side verification pass, because the UI will happily show you a configuration that the data plane is not enforcing.

Connect a test device to the guest SSID and confirm four things in order: that you received an address from the guest DHCP scope and not the production one, that the portal presented itself, that you cannot reach any production host or the gateway's management interface, and that your throughput lands near the configured cap.

The DHCP check is the fastest tell. If your test device's IP is in the same subnet as your NAS, nothing downstream of that matters — the VLAN assignment is wrong and every other control is operating on the wrong segment.

For the isolation check, test against a host you know responds: a printer's web interface, a camera, or the gateway itself. A silent timeout is the pass condition; a login page is a failure you need to fix before guests arrive.

Re-run this pass after firmware updates. Guest control rules and isolation settings have changed presentation across UniFi Network major versions, and a setting that migrated to a new location is a setting that can quietly revert to a default.

If you manage the site remotely, make sure your own access path does not depend on anything you just firewalled — the UniFi remote access options guide covers the ways to keep a management path open that guests cannot see.

Finally, document the guest configuration alongside the rest of the site: VLAN ID, DHCP scope, portal type, pre-auth allow list, and the bandwidth profile numbers with the reasoning behind them. The next person to touch this — including you in eighteen months — needs to know why the cap is 15 Mbps and not 50, or they will change it on a hunch.