An external captive portal can turn guest WiFi into a branded, measurable visitor experience. But before launch, test the full guest journey—not merely whether the SSID appears.
This checklist is for UniFi installers, MSPs, and venue operators using an external portal server.
1. Confirm the guest network is actually isolated
Start with the network boundary:
- Put guest WiFi on its intended guest network or VLAN.
- Prevent guest devices from reaching internal business networks.
- Enable client isolation where the deployment requires it.
- Confirm the hotspot/captive-portal setting is applied to the intended SSID or guest network.
A portal is not a substitute for network segmentation. Solve isolation first, then test the guest experience.
2. Check the redirect from a real guest device
Join the guest SSID using a phone or laptop that has not recently used the network.
Verify that:
- The device is initially blocked from normal internet access.
- The device is redirected to the external portal.
- The redirect includes the expected client and SSID context.
- The portal loads quickly over the guest connection.
If the portal does not load, inspect guest DNS, the pre-authorisation policy, the external portal hostname, and any firewall rules between the guest network and required portal assets.
3. Make every portal asset reachable before authorisation
A common failure is a page that partly loads but cannot show its logo, styles, scripts, consent form, or authentication controls.
Test the portal as an unauthorised guest and ensure all essential assets are available before login. Avoid dependencies that require unrestricted internet access before the guest has completed the portal flow.
4. Verify client lookup and authorisation separately
The portal flow has two distinct technical jobs:
- identify the joining client from the redirect context;
- authorise that client after the portal action succeeds.
Test each step independently. Confirm the client lookup resolves the correct connected device, then confirm the authorisation request changes that guest to authorised with the intended time, data, or rate limits.
5. Test the outcome that matters: browsing after login
A successful form submission is not a successful deployment.
After authorisation, test that the guest can:
- reach ordinary HTTPS websites;
- use the venue's expected guest services;
- reconnect within the intended session policy;
- receive the expected portal behaviour when the session expires.
If login succeeds but browsing remains blocked, review the guest network’s Hotspot policy, DNS and gateway behaviour, and the authorisation result returned by UniFi.
6. Run a venue-ready acceptance test
Before handover, run the above test on at least two common device types and record:
- SSID and guest-network name;
- portal URL and timestamp;
- redirect result;
- client lookup result;
- authorisation result;
- post-login browsing result;
- owner responsible for future portal and guest-network changes.
This gives the venue a useful support record and gives the installer a clean handover point.
Captive portal or Passpoint?
Choose a captive portal when the venue needs a branded landing experience, guest authentication, consent, contact capture, or an external portal workflow. Passpoint is designed for seamless compatible-device onboarding; UniFi documents that Passpoint-enabled SSIDs do not support captive portals or redirects. The two approaches solve different guest-experience problems.
Need an external-portal readiness check?
LiquidEdge is preparing self-service availability for UniFi guest WiFi operators. If you are planning an external portal and want to be notified when the path is available, request an availability check.