What is a captive portal?

The short version

Picture a bakery at eight in the morning. A guest takes a table by the window, opens their phone, and taps the network called Bakery Guest. The phone connects to the access point straight away, but the network does not yet let it reach the internet. It is captive: it can reach the login page and very little else.

The guest types an email, ticks the WiFi terms, and taps the button. A second later the news app refreshes. Between the tap and the refresh, the login page told the network that this phone may now pass. That handshake is the whole point of a captive portal.

The guest only ever sees the page. Everything else happens between their phone, the access point, the controller that manages the access points, and the server that hosts the page.

How the login page appears

1. The phone checks whether it is online

As soon as a phone or laptop joins a network, it quietly asks a known address for a known answer. The architecture document for captive portals published by the IETF, RFC 8952, describes this as a canary request: if the answer comes back different from the one expected, the device concludes that something on the network is in the way. That is why the login window opens by itself, without the guest opening a browser.

2. The network redirects it

On a guest network running TP-Link Omada or Ubiquiti UniFi, the controller holds every new device in a waiting state. Its check gets a redirect instead of the expected answer, and the redirect points at the portal page. A short allow list, called the walled garden, lets the phone load that one page and nothing else. For VoqadoWiFi the list holds just two entries: www.voqadowifi.com and voqadowifi.com.

3. The guest signs in on the portal page

The phone opens the page in a small login window. On a VoqadoWiFi venue using the explicit consent form (the default for new venues) that page carries the venue’s name and colours, asks for an email and a first name, and shows two separate boxes: one to accept the WiFi terms and one, unticked, that reads “Email me offers and news from” the venue. The guest can accept the terms without ticking the second box and still get online.

4. The portal calls back to the controller

When the guest taps the button, the portal server sends an authorisation request to the venue’s controller for that specific device. On Omada this uses the token the controller included in the redirect; on UniFi it is an authorise guest call with the controller credentials the venue connected during setup.

5. The network opens up

The controller moves the device out of the waiting state, the access point starts passing its traffic to the internet, and the login window closes or shows a success message. The session lasts as long as the venue set in the controller.

Internal and external portals

There are two places the login page can live, and the difference decides what a venue can do with it.

Internal portal

The page is served by the controller or the access point itself, from a template inside the networking software. It is fine for a password screen or a simple terms page. It is not built to keep a guest list, record consent wording, or send a review request after the visit, because it is a page inside networking software rather than an application.

External portal

The controller redirects the guest to a page hosted somewhere else on the internet, and that page tells the controller when to let the guest on. VoqadoWiFi works this way. The venue keeps its own access points and controller, pastes the portal address into the controller, and the login page, guest list and consent records live in VoqadoWiFi.

Only two network vendors work: TP-Link Omada and Ubiquiti UniFi. There is no VoqadoWiFi router or access point. If you already run either, the Omada setup guide and the UniFi setup guide walk through the controller screens.

What a venue portal can do

• Decide who gets online. Nobody passes until they accept the terms or sign in, so the venue always has a record of who used the network.
• Show the WiFi terms. The terms checkbox is stored separately and is never treated as permission to send marketing.
• Ask a few questions. Email and first name, with last name, phone and birthday as options the venue can switch on. An optional age gate can run before the form.
• Record consent properly. Each choice is saved with the exact wording the guest saw, the version of that wording, the time and where it was given.
• Recognise a returning device. Within the auto login period, 30 days unless the venue changes it, a recognised device goes straight back online without the form.

What a venue portal cannot do

This is where people worry, and most of the worry is misplaced. A captive portal is a gate, not a camera.

It cannot read secure pages

Banking apps, email, messaging and nearly every website now use HTTPS, which encrypts the content between the phone and the site. A venue network carries that traffic but cannot read what is inside it. The network can still see some technical details, such as which addresses a device connects to and how much data moves, which is true of any network you join, at home or at a hotel.

VoqadoWiFi is not in the path after login

Once the controller has authorised the device, traffic flows from the access point to the venue’s own internet connection. VoqadoWiFi sees what the guest typed on the login page and the fact that they connected. It does not sit between the guest and the websites they visit.

It cannot reach into your accounts

VoqadoWiFi has no social login, so there is no Google, Facebook or Apple sign in and no profile data pulled from a social account. The venue gets what the guest typed into the form, and nothing more.

It cannot rewrite a secure address

If a guest types an https address before signing in, the network cannot redirect it cleanly, because the reply would not come from the site the phone asked for. RFC 8952 notes that the phone’s own check is usually sent without TLS for exactly this reason. The result is a certificate warning, which is the browser doing its job, not a sign the portal is broken.

Why some phones do not show the login

Picture a regular at the counter saying the WiFi is broken. Usually the network is fine and one of these is true:

• The phone is already signed in from an earlier visit, so its check succeeds and there is nothing to show.
• The automatic login window has been switched off for that network in the phone’s WiFi settings.
• The guest closed the login window, so the phone stays joined with no internet and no prompt.
• The walled garden contains extra entries that let the phone’s check through, so the phone believes it is online.
• The portal domain is missing from the walled garden, so the window opens blank and closes.

For a guest, forgetting the network and joining again fixes most of these. Opening a plain http address in the browser also forces the redirect. The troubleshooting pages cover each symptom on Omada and UniFi, starting with the login not showing on iPhone.

Where the standards are going

The redirect trick works, but it relies on intercepting a request the phone did not mean for the portal. The IETF has published a cleaner route. RFC 8910 defines DHCP and router advertisement options that tell a device, at the moment it joins, that it is behind a captive portal and where to ask about it. RFC 8908 defines that place to ask: a small API answered over HTTPS, which reports whether the device is captive and gives the address of the login page.

Support depends on the phone, the network software and how the venue configures it, so for now the redirect remains how most guest networks behave. We checked these documents on 7 October 2026 at rfc-editor.org.

Questions

Keep reading