Create isolated UniFi guest WiFi

Outcome and equipment

Build a guest network that provides internet access while preventing guests from reaching your private devices. Separately test whether guests can reach one another. You need a UniFi gateway, an adopted AP, an administrator computer connected through a preserved management port, and two test clients. Switch level client isolation requires compatible switching hardware. An AP attached to a third party router cannot independently enforce all the gateway policies described here. [1] [2]

Use these example values: network Guest, VLAN 30, subnet 192.168.30.0/24, gateway 192.168.30.1, DHCP range 192.168.30.100 to 192.168.30.199, and WiFi name Example Guest. Keep the current management LAN and its administrator connection unchanged. Replace the example subnet if it overlaps an existing network or VPN.

Procedure

  1. Save a configuration backup and record which switch port provides your working administrator connection. Choose a short test window. Keep that computer connected while you use a different device to test the new WiFi.
  2. In Network, open Settings and Networks, then create the Guest virtual network. Select the UniFi gateway as its router. Enter the VLAN, gateway and DHCP values above. For this introductory exercise, leave IPv6 unconfigured on this new VLAN. Do not change the WAN or other networks' IPv6 configuration. Production networks using IPv6 need equivalent isolation and separate verification.
  3. Enable Network Isolation for Guest. This creates inter-network restrictions. If your interface uses a policy or object workflow, locate the equivalent local network isolation control and inspect its generated policies. Use one isolation method for this exercise; avoid layering contradictory rules from older guides. A VLAN identifier alone does not provide the intended access policy. [1] [3]
  4. Ensure every switch link between the gateway and AP carries VLAN 30 as tagged traffic. Keep the AP's existing management network as the native network. Follow Access and trunk ports guide if a switch requires explicit VLAN configuration. Do not make Guest the AP's management network.
  5. Open Settings and WiFi, create Example Guest and associate it with Guest. Use a new password, select the intended APs and keep the normal compatibility settings initially. Leave the captive portal disabled for the first test so authentication and isolation can be diagnosed separately. Enable Client Device Isolation on the guest WiFi. [1]
  6. Where supported, enable Device Isolation ACL for the Guest network to address traffic passing between guest clients through switches. Confirm that all relevant switches support the feature. AP client isolation alone does not prove isolation between clients using different APs or a wired guest port. [2]
  7. Review guest access to the gateway itself. Inter-VLAN blocking and gateway administration are distinct paths. Attempt to open the console's administrative address from the guest client. If accessible, add a Guest-to-Gateway policy blocking the actual administrative ports, such as HTTPS and SSH, while preserving DHCP, DNS and required network control traffic. Zone-based firewall guide provides the policy method. A blanket block of all gateway traffic can also stop address assignment and name resolution. [3]
  8. Exclude Guest from any mDNS sharing scope. Guests in this example do not need discovery of your private printers or media devices. Apply changes and reconnect the test clients to renew their network information.

Verify the result

On the first guest client, confirm an address in 192.168.30.100 to 199 and gateway 192.168.30.1. Open two unrelated HTTPS websites. Then attempt an actual service on a known private device, such as a printer's web page, and attempt console administration. Those private connections must fail. A failed ping alone is insufficient because the destination could simply ignore ping.

Connect the second guest client and test a temporary service between them. Repeat with both clients on one AP, then on different APs if available, and finally from any wired guest port. Record which combinations were tested. Check that no global IPv6 address has unexpectedly been assigned on this IPv4-only test VLAN. If IPv6 is in use, repeat the service tests using IPv6 addresses and review both firewall and switch capabilities.

Troubleshooting and recovery

No DHCP address usually points to the VLAN path, DHCP configuration or a gateway rule. Correct those before changing WiFi security. Internet working while private devices remain reachable indicates a policy problem: confirm the client's assigned network and the source and destination matched by the rule. Discovery without a successful connection can mean mDNS announcements are still being shared.

If a change disrupts service, disable the most recent guest policy from the preserved management connection. To remove the exercise, disable Example Guest, disconnect guest clients, then remove its policies and network after checking that no switch ports still use it. Keep your original management network intact.

Sources

Back to the series

Leave a comment

Please note, comments need to be approved before they are published.