Assign WiFi VLANs with UniFi PPSK passwords

Outcome and limitations

Create one WiFi name with two passwords: one assigns a client to IoT VLAN 20 and the other to Guest VLAN 30. This demonstrates Private Pre-Shared Keys, or PPSK. It does not create isolation by itself; each destination VLAN still needs the policy established in Guest WiFi isolation, IoT VLAN with casting and Zone-based firewall tutorials.

Ubiquiti documents PPSK as WPA2-only and unavailable on the 6 GHz band. For this exercise, use 2.4 and 5 GHz on compatible APs. Keep a separate appropriately configured WiFi for clients that need 6 GHz or a different authentication method. Do not confuse WiFi 6 on 2.4 or 5 GHz with the 6 GHz band. [1] [2]

You need a working gateway with the two VLANs, an AP and switching path carrying both VLANs, and a client on which you can forget and rejoin a WiFi network. Keep your existing Main WiFi and wired administrator connection available throughout the test.

Procedure

  1. Create or verify IoT 192.168.20.0/24 and Guest 192.168.30.0/24. Each uses its .1 gateway and .100 to .199 DHCP range. Confirm the intended isolation rules using a temporary single-network WiFi or access port before involving PPSK. This gives you a known working network baseline.
  2. Inspect the AP switch port and all upstream trunks. The AP's current management network stays native, while VLANs 20 and 30 are explicitly allowed as tagged traffic. A password can authenticate successfully even when the subsequent VLAN path cannot deliver a DHCP reply. [3]
  3. Open Settings and WiFi, then create a new network called Example Shared. Select the APs for the exercise. Choose the 2.4 and 5 GHz bands, ensure 6 GHz is disabled for this WiFi, and use the WPA2-compatible settings required by the PPSK control.
  4. Enable Private Pre-Shared Keys. Create an entry labelled IoT devices, assign IoT as its network and generate a unique strong password. Create a second entry labelled Visitors, assign Guest and generate a different password. Treat labels and passwords as separate fields; a descriptive label does not replace the secret. Save the WiFi configuration. [1]
  5. On the test client, connect to Example Shared using the IoT password. Confirm that the client receives an address in 192.168.20.0/24, with gateway 192.168.20.1. Check its network in UniFi as well as on the client. Verify an allowed internet service and an intentionally blocked Main resource.
  6. Forget Example Shared on the test device, then reconnect using the visitor password. Confirm a new address in 192.168.30.0/24 and gateway 192.168.30.1. Test the Guest policy. A client can retain a saved password or lease, so verify the actual assignment instead of assuming that typing a different password changed the network.
  7. Repeat both password tests on a second client, then on another AP if the WiFi is broadcast by several APs. This catches inconsistent provisioning and missing tagged VLANs on a downstream switch. Keep a simple test table containing password label, AP, resulting subnet and policy result.
  8. Test password removal or rotation on the visitor entry. Change the visitor password, disconnect the visitor test client and attempt a fresh connection with the old password. It should fail. Then connect with the replacement password and confirm that the IoT entry still works. Do not assume changing a password immediately terminates every already established wireless session; explicitly disconnect relevant clients when immediate removal is required and test the result.

Practical choices

Use PPSK when a manageable set of shared credentials fits the deployment. Maintain a record of which devices or groups use each key. Someone who knows the IoT key can join the IoT VLAN, so key distribution is part of your network policy. A key labelled Staff is not proof of an individual employee's identity.

For individual enterprise credentials, consider the separate RADIUS-based workflow described by Ubiquiti. That involves different authentication infrastructure and compatibility decisions. Do not enable Enterprise merely to make the PPSK option appear on 6 GHz; they are different configurations. [1]

Troubleshooting and recovery

If the PPSK control is absent, inspect the WiFi's selected bands, security mode, AP compatibility and application version. If authentication succeeds but the client has no valid address, inspect DHCP and VLAN tags. If the address is correct but access is excessive, repair the destination VLAN's firewall or isolation policy.

To undo the exercise, move clients back to their original WiFi, disable Example Shared and remove its credentials. Delete test VLANs only after confirming that no wired ports, other WiFi networks or policies still depend on them. Keep the working management path available until all migrated devices reconnect.

Sources

Back to the series

Leave a comment

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