Network requirements

1. Walled garden — what a device reaches before signing in

On the controller: Settings → WiFi → Guest Hotspot → Authorization Access → Pre-Authorization Allowances. The SSID blocks everything until the device is authorized; this list is the exception that lets the sign-in page load.

Push-notification MFA needs one more detail. A Microsoft Authenticator push travels outside this list, so a device that only has the company Wi-Fi does not receive the notification. The 6-digit code in the app itself works without internet and solves it — it is explained in the user guide. Do not try to allow push in the walled garden: its addresses are not stable.

2. Firewall — the portal has to reach your controller

The portal runs on our infrastructure and talks to your UniFi controller through its API, to authorize each device that signed in. It is the only connection that goes from us to you.

Tested versions. UniFi Network 10.0, 10.4 and 10.6 on a controller installed on a server, and 10.5 on UniFi OS Server. UniFi OS hardware consoles (Dream Machine, Cloud Gateway, Cloud Key) use the same API as UniFi OS Server, but have not been tested on a device yet. If yours is one of them, talk to Winserv before you subscribe.

One portal serves one controller site. If your controller has several sites (branches, buildings), the portal works on the site chosen at sign-up; on the others, sign-in and vouchers do not grant access. More than one site? Talk to Winserv before you subscribe.

The controller has to be published to the internet on that port, with a valid certificate, and have an account dedicated to the portal. Create it in Settings → Admins → Add New Site Admin with the Site Administrator role, with permission only on the site the portal serves — a super administrator or the controller's owner account is neither needed nor wanted.

Do not use the "Hotspot" role on the admins page. It creates an administrator tied to a Ubiquiti account and sends an e-mail invitation; that account authenticates in Ubiquiti's cloud, not on the controller, so the local API refuses its login. Verified on controller 10.4.57, where the per-site roles available are only Site Administrator and View Only — and "View Only" cannot authorize a guest.

What the account does, and nothing more: it authorizes and unauthorizes guests on the site (cmd/stamgr); it reads the list of sites once, at sign-up, to find your site's internal identifier; it reads which network a device is on when someone redeems a voucher (stat/sta), so a voucher only works on the guest network; and it reads the hotspot settings (rest/setting/guest_access) when you open your portal's checklist, to tell you what is still missing. No controller setting is changed.

3. Controller — three options on the hotspot page

In Settings → WiFi → Guest Hotspot → Landing Page Settings:

1. External Portal Server = 5.161.45.166. This field accepts an IP address only — a name does not work in it.
2. Domain = YOUR-PORTAL.winserv-auth.com (the exact address is on your portal's checklist page). This is what makes the AP send the user to the name rather than the IP. Without it the certificate does not match and the browser refuses the connection.
3. Secure Portal on. It sends the device straight to HTTPS, without a first plain-text round trip on an open network.

The first two look redundant and are not: one says where the connection goes, the other which name the browser sees. Swapping them is the most common mistake on this page.

4. Two networks: employees and visitors (optional)

To keep the employee network apart from the visitor network: two Wi-Fi networks in UniFi, both with Hotspot (captive portal) and each on its own network/VLAN. Both use the same portal — UniFi allows one portal per site. In the portal's console (/admin → Networks), enter the name of each: the corporate one shows only the Microsoft sign-in; the visitor one, only the voucher.

Your firewall is what keeps visitors off the internal network, not UniFi. With a gateway that is not Ubiquiti's (a FortiGate, for example), the Hotspot's Post-Authorization Restrictions list does not block access after sign-in — we measured it: with the three private ranges in the list, a signed-in device opened another device on the local network. The list looks like protection and is not — do not rely on it. So:

1. On the firewall, on the visitor VLAN: block the internal networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and allow only the internet. On the corporate VLAN, apply the company's policy.
2. Check both sides: from a device on the corporate network, signed in, an internal system opens; from a device on the visitor network, it does not.

UniFi gateway (UDM, USG)? We have not measured that case, and the list is probably enforced — which cuts both ways: it protects visitors, but on a Hotspot network it can also stop employees from reaching the printer and internal systems. Run the same two-sided test before opening the network.

One network for everyone? It works — the page shows the Microsoft sign-in and the voucher together — but employees and visitors share one VLAN and the firewall cannot tell them apart: with vouchers on, a visitor reaches what an employee reaches on the internal network. If there is a printer, a server or an internal system to protect, use two networks; or keep one network for employees only, with vouchers turned off in the console.

Client Device Isolation (on each Wi-Fi network's page, under Security) — stops devices on the same wireless network from seeing each other:

1. Visitor network: on. One visitor should not reach another visitor's phone.
2. Corporate network: off if employees use a printer, screen mirroring (AirPlay, Chromecast) or device-to-device sharing over Wi-Fi; on if they do not — it is safer.

It does not control access to the internal wired network — that is the firewall, above. The corporate network can stay open, with no password: whoever gets in has passed Microsoft, and a visitor who tries a voucher on it is disconnected within a minute.

TVs, air conditioning and other devices with no sign-in screen cannot go through a captive portal. Put them on a third network, with a password, on their own VLAN and without Hotspot. Each AP broadcasts up to 4 networks per band (8 with Wireless Meshing off), so employees, visitors and devices fit with room to spare.

DNS, if your network uses its own resolver

The hosts in the table above must resolve from the guest Wi-Fi network, before authentication. Networks with a restricted internal DNS are usually where this breaks — and the symptom looks like "the portal is down".