UniFi: guest authorization portal and an external server

UniFi is one of the most common choices in Kazakh hotels and multi-site venues, yet there is almost nothing written about setting up guest authorization on it under local requirements. Here is where the portal lives in the controller, how to point it at an external server, and what to check when the login page never appears.

What you need before you start

• Admin access to UniFi Network for the site. The controller may sit on a dedicated appliance, on the gateway, or be self-hosted on a server — the path to the settings is the same in all three
• Access points adopted into the controller and showing as connected. Portal settings are applied through the controller; a point outside it never learns about them
• The external portal address and the key used to sign requests
• The list of addresses open before authorization: the portal and the SMS gateway
• A phone with mobile data switched off for testing

Menu labels in UniFi move between versions more often than with any other vendor on this list: what sits under guest access in one build moves into the wireless network settings in the next. Follow what a setting does, not the caption on a screenshot from someone else's guide.

Where the portal lives

In UniFi the portal is a function of the controller, not of the access point. The point only intercepts traffic and asks the controller what to do with this client. Two consequences follow.

First, until a point is adopted, portal settings will not reach it. Second, if the controller becomes unreachable, guests already authorized keep working while new authorizations do not go through. On a site whose controller lives in the cloud, that is worth keeping in mind when choosing the uplink.

Step 1. The guest network

Create a separate wireless network for guests and mark it as a guest network. That flag is not cosmetic: it turns on isolation from internal subnets and makes the portal settings available. A network without it behaves like any other — and the guest ends up on the same network as the till.

Give the guest network its own VLAN, matching what is configured on the switch. On a site with several access points this is the most common way to lose time: the VLAN exists in the controller but is not allowed on the ports, so guests associate with the network and never get an address.

Step 2. Turning the portal on

The guest access settings are where the authorization method is chosen. UniFi offers several: a page with an agree button, a shared password, built-in vouchers, an external authorization server and RADIUS.

The first two do not meet the identification requirement. An "I agree" button says nothing about who was on the network, and a shared password says the same thing for everyone. Built-in vouchers suit places where a staff member hands the slip over — a hotel front desk, for instance. Signing in by SMS or with a digital ID needs an external server.

Step 3. The external portal

The settings take the address of the login page. From there UniFi works like this: when a guest tries to reach the internet, the access point redirects them to that address and passes the device MAC, the access point MAC, the network name and the address the guest was trying to open. The portal shows the form, confirms the number and tells the controller this device may go online.

A word on https. UniFi can intercept secure connections, but that requires a certificate the guest's phone trusts; without one the browser shows a warning instead of the login page. It is simpler not to intercept https at all: phones open the portal over plain http by themselves when they check whether the network works.

Step 4. Access before authorization

Until the guest signs in, everything is closed except the allow list. That list holds the portal address and the gateway the SMS messages go through. If the portal lives on a domain, add both the domain and the addresses it resolves to: the device resolves the name first, and with DNS closed it never reaches the login page.

How to confirm it works

1. Connect to the guest network with mobile data switched off
2. Check the phone received an address from the guest subnet, not the operational one
3. Open any site over http — the login page should appear
4. Sign in and confirm the device shows as authorized in the controller's client list, and the session appears in the portal log
5. From the same phone, try to open the address of a till or a camera: there should be no access

If the login page never appears

• The network is not marked as a guest network. The most common cause: portal settings simply do not apply to a regular one
• You are testing over https. Open something over http — that is where interception works
• The portal is not on the allow list. The guest cannot reach the page they are being sent to
• The access point lost the controller. Check its status: a point without the controller still broadcasts the network but performs no authorization
• The phone remembers an old session. Forget the network on the device and reconnect

What goes into the log

The controller keeps a client list and connection history, but that is network data: MAC address, access point, time. It does not answer who the person was — the portal does, by tying the device to a confirmed number. Each session stores the number, the start and end time, the MAC and the access point; the log exports from the dashboard.

That also settles what happens when the controller is replaced or the site is moved to another account: the history stays on the portal side. Which fields are worth keeping, and for how long, is covered in Wi-Fi log retention.

When UniFi is the right choice

UniFi fits sites with more than one access point where a single client list matters: hotels, multi-site venues, business centres. For one room with a single point it is overkill — Keenetic or MikroTik is simpler there. The authorization portal itself is the same for any hardware; only what it connects to changes. A comparison by requirement is in what a router needs to support.