TP-Link Omada: guest captive portal and an external server

Omada is the usual choice once there are more than two access points: a shopping centre, a hotel, a large restaurant with several rooms. The portal is configured centrally, which is exactly why it is easy to configure it at the wrong level.

Where things live

Everything runs through the Omada Controller — hardware, software or cloud. Access points decide nothing on their own: they receive configuration from the controller. Portal settings sit in the authentication section and apply to selected SSIDs, not to the whole network. The first common mistake is configuring the portal and forgetting to tick the guest SSID.

What you need before you start

• Admin access to Omada Controller. The controller can be hardware, software or cloud — the menu path is the same in all three
• Access points already adopted into the controller and showing Connected. Until a point is in the controller, portal settings will not reach it
• The external portal address and the key used to sign requests
• The addresses for the allow list: the portal and the SMS gateway
• The VLAN id for the guest network, matching what is configured on the switch

That last point is the most common way to lose time on a large site. If the VLAN exists in the controller but is not allowed on the switch ports, guests will associate with the network and never get an address.

Step 1. The guest network

Create a separate guest SSID and a separate network with its own VLAN. Enable guest mode: it blocks access from the guest segment to internal subnets. Without it the access point will happily let a guest reach the till if they share a network — see the separate write-up.

Step 2. Authentication type

• no authentication — just a page with an "I agree" button; confirms nothing;
• simple password — the shared password that does not solve identification;
• vouchers and local users — convenient in a hotel where reception hands out a voucher;
• external RADIUS — confirmation and session accounting on your side;
• external portal — your server serves the login page and confirms the number by SMS or a digital ID.

For a venue in Kazakhstan the working combination is an external portal plus RADIUS: the first handles identity and the look of the page, the second the session accounting that becomes the log.

Step 3. Connecting the external portal

The portal profile takes the login page address, the RADIUS address and the shared secret. Enable accounting: without it authorization works but no session records exist. Keep the interim update interval short, otherwise a long session reaches the log only when the guest disconnects.

Step 4. Allowed addresses

Before authorization the guest can only reach the allow list. Add the portal domains, its API and the SMS gateway. Skip this and the login page never loads: from outside it looks like "Wi-Fi works, internet does not".

How to confirm it works

1. Connect to the guest SSID 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 session shows up both in the portal log and in the controller's client list
5. Repeat the check on an access point at the far end of the site: the portal is bound to the SSID but applied through the controller, and a point that has lost contact with it behaves differently

If the login page never appears

• The portal is not bound to the SSID. The most common cause: the profile exists but the guest SSID is not selected in it
• Testing over https. A secure connection cannot be intercepted without a certificate warning; test with an http page
• Access points have not applied the configuration. After changes the points go through a provisioning cycle; until it finishes some run the old config
• The VLAN does not reach the controller. If the guest VLAN is not trunked on the switch, RADIUS requests simply never leave

Which controller to choose

The choice affects guest authorization less than people expect, but there is a difference.

• Hardware — a box in the rack that depends on nobody else's servers. Convenient where there is no in-house administrator: install it and forget it
• Software — installed on a server or a virtual machine. Cheaper to start with and more flexible, but someone has to watch updates and backups
• Cloud — managed over the internet with no hardware of your own. The question that matters here is what happens when the link drops: guests already connected keep working, while new authorizations will not go through while it is unreachable

For a single venue the difference is barely felt. For a network of sites the deciding factor is not price but where you want the combined client list and reports to live.

Larger sites

In malls and hotels analytics usually joins the portal straight away: how many visitors, how many are new, how they move between zones. That sits on top — see Wi-Fi radar for malls and the shopping centre scenario. The identification requirement is the same for one access point and for a hundred: what the law requires.