Come funziona un Captive Portal? Approfondimento Tecnico

Un approfondimento tecnico completo sull'architettura dei captive portal, che spiega l'intercettazione DNS, il reindirizzamento HTTP, i walled garden e l'autenticazione RADIUS per i professionisti IT.

📖 7 min di lettura📝 1,564 parole🔧 2 esempi❓ 3 domande📚 8 termini chiave

🎧 Ascolta questa guida

Visualizza trascrizione

How Does a Captive Portal Work? A Technical Deep Dive
A Purple WiFi Intelligence Briefing

[INTRODUCTION — approximately 1 minute]

Welcome to the Purple Technical Briefing series. I'm your host, and today we're going deep on captive portals — specifically, how they actually work under the hood. Not the marketing version. The real version: DNS interception, HTTP redirects, walled garden configuration, RADIUS authentication, and session lifecycle management.

If you're an IT manager, network architect, or CTO responsible for guest WiFi at a hotel, retail estate, stadium, or public-sector venue, this is the briefing you need before you sign off on your next deployment. We'll cover the full technical stack, the common failure modes, and where platforms like Purple fit into the picture.

Let's get into it.

[TECHNICAL DEEP-DIVE — approximately 5 minutes]

So, how does a captive portal work? At its most fundamental level, a captive portal is a network access control mechanism that intercepts a guest device's internet traffic and redirects it to an authentication or registration page before granting full network access. Simple concept. Complex implementation.

Let's walk through the full sequence, step by step.

Step one: Association and DHCP. When a guest device connects to your SSID — your guest WiFi network — the access point assigns it an IP address via DHCP, just as you'd expect. At this point, the device has a valid IP address and a default gateway, but it cannot reach the internet. The network is in a pre-authenticated state. The device is associated, but not yet authorised.

Step two: DNS interception. Here's where it gets interesting. When the guest device tries to resolve any domain name — let's say it's trying to reach google.com — the DNS query is intercepted by the captive portal system. The DNS server in the walled garden responds with the IP address of the captive portal server, not the actual IP of google.com. This is sometimes called DNS spoofing, though in this context it's entirely intentional and controlled. Every DNS query, for any domain, returns the same answer: the portal's IP address.

Step three: HTTP redirect. The guest device's browser then attempts to connect to what it thinks is google.com, but it's actually connecting to the captive portal server. The portal server issues an HTTP 302 redirect — a standard redirect response — pointing the browser to the portal's login or registration page. Modern operating systems, including iOS, Android, Windows, and macOS, have built-in captive portal detection mechanisms. They periodically probe known URLs — Apple uses captive.apple.com, Microsoft uses msftconnecttest.com — and when they detect a redirect rather than the expected response, they automatically launch the captive portal browser window. This is the little pop-up you see on your phone when you connect to airport WiFi.

Step four: The walled garden. While the guest is in this pre-authenticated state, the network enforces what's called a walled garden — a set of IP addresses and domains that are accessible without authentication. This typically includes the captive portal server itself, any CDN resources the portal page needs to load, and potentially partner domains. For example, a hotel might whitelist their loyalty programme's domain so returning members can authenticate via their existing account. The walled garden is configured at the access controller or firewall level, using ACLs — access control lists — that permit traffic to whitelisted destinations while blocking everything else.

Step five: Authentication and RADIUS. When the guest submits their credentials — whether that's a social login, an email address, a voucher code, or a terms-of-service acceptance — the captive portal server processes that submission and communicates with a RADIUS server. RADIUS stands for Remote Authentication Dial-In User Service, and it's the industry-standard AAA protocol — Authentication, Authorisation, and Accounting. The portal server sends a RADIUS Access-Request packet containing the user's credentials. The RADIUS server validates those credentials against its user database or an external identity provider, and responds with either an Access-Accept or an Access-Reject. If accepted, the RADIUS server can also return authorisation attributes — things like session timeout, bandwidth limits, and VLAN assignment — as RADIUS attributes in the Access-Accept packet.

Step six: MAC authorisation and session activation. Once the RADIUS server returns an Access-Accept, the captive portal system instructs the access controller to authorise the guest device's MAC address. From this point, the device's traffic is no longer intercepted. The walled garden is lifted for that specific MAC address, and the device has full internet access — subject to any bandwidth or time limits specified in the RADIUS attributes. The RADIUS server also starts an Accounting session, recording the session start time, the device's MAC address, and the assigned IP. This accounting data is critical for compliance, particularly under GDPR and the EU's data retention requirements for public WiFi operators.

Step seven: Session lifecycle and expiry. Sessions don't last forever. The RADIUS Access-Accept typically includes a Session-Timeout attribute, which defines the maximum session duration. When that timer expires, the access controller sends a RADIUS Disconnect-Request, the MAC address is de-authorised, and the device is returned to the pre-authenticated state. The guest will need to re-authenticate. Some deployments use MAC address caching to remember returning devices, allowing them to bypass the portal for a configurable period — typically 24 hours or 30 days — which significantly improves the returning guest experience.

Now, a word on HTTPS and the modern challenge. As HTTPS adoption has become near-universal, the traditional HTTP interception model has become more complex. Browsers now enforce HSTS — HTTP Strict Transport Security — which means they refuse to connect to HTTPS sites over plain HTTP. This is why captive portal detection relies on specific HTTP probe URLs rather than intercepting arbitrary HTTPS traffic. If your portal is intercepting HTTPS traffic and presenting a self-signed certificate, you will generate browser security warnings — which is a terrible user experience and a potential compliance issue. The correct approach is to ensure your portal operates on a properly signed domain with a valid TLS certificate, and that your captive portal detection relies on the OS-native probe mechanism rather than HTTPS interception.

[IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes]

Right, let's talk about what actually goes wrong in production deployments, and how to avoid it.

The most common failure mode is walled garden misconfiguration. If your portal page loads external resources — JavaScript libraries, fonts, images from a CDN — and those CDN domains aren't in your walled garden, the portal page will fail to render correctly for unauthenticated users. Always audit every external resource your portal page loads and ensure those domains are whitelisted. This is particularly important if you're using a third-party portal platform like Purple, where the portal page may be served from a cloud CDN.

The second common issue is iOS Captive Network Assistant conflicts. Apple's CNA — the pop-up browser that iOS uses for captive portal authentication — has significant limitations. It doesn't support all JavaScript features, it doesn't persist cookies in the same way as Safari, and it has strict timeout behaviour. If your portal relies on complex JavaScript flows or OAuth redirects, you may find that iOS users have a degraded experience. The solution is to design your portal with CNA limitations in mind, or to implement a redirect to the device's native browser after the initial detection.

Third: RADIUS timeout and failover. In high-density environments — a stadium with 50,000 concurrent sessions, for example — your RADIUS infrastructure needs to be sized accordingly. A RADIUS server that's overwhelmed will cause authentication timeouts, which manifest to the end user as a portal that appears to hang. Implement RADIUS redundancy with primary and secondary servers, and configure appropriate retry and timeout values on your access controllers.

Fourth: GDPR and data retention compliance. Under GDPR, if you're collecting personal data at the portal — email addresses, social login data — you need a lawful basis, a privacy notice, and a data retention policy. The ICO in the UK and equivalent authorities across the EU take WiFi data collection seriously. Platforms like Purple handle this at the platform level, providing built-in consent management, data subject access request tooling, and configurable retention policies. But you need to ensure your portal configuration actually enforces those policies — don't assume it's handled automatically without verifying.

[RAPID-FIRE Q&A — approximately 1 minute]

Let me run through some questions I get asked regularly.

"Can a captive portal work with WPA3?" Yes. WPA3 handles the wireless encryption layer independently of the captive portal authentication layer. You can run a captive portal on a WPA3-protected SSID. The portal handles network access control; WPA3 handles over-the-air encryption.

"Do captive portals work on 5G devices?" Yes, with caveats. Devices that support 5G Passpoint or OpenRoaming may bypass the captive portal entirely if they have a valid Passpoint credential. This is by design — Passpoint is intended to provide seamless authentication. If you want to enforce portal authentication for all devices, ensure your SSID is not advertising Passpoint support unless you intend it.

"What's the difference between a captive portal and 802.1X?" 802.1X is a port-based network access control standard that authenticates devices before they're granted any network access at the Layer 2 level. Captive portals operate at Layer 3 and above — the device gets an IP address first, then is redirected. 802.1X is typically used for corporate networks with managed devices; captive portals are used for guest networks with unmanaged devices.

[SUMMARY AND NEXT STEPS — approximately 1 minute]

To summarise: a captive portal works through a coordinated sequence of DNS interception, HTTP redirection, walled garden enforcement, RADIUS authentication, and MAC-based session management. Each component needs to be correctly configured for the system to work reliably at scale.

For IT teams evaluating or deploying guest WiFi, the key decisions are: cloud-hosted versus on-premises portal infrastructure, RADIUS architecture and redundancy, walled garden configuration management, and compliance tooling for GDPR and data retention.

Purple's guest WiFi platform handles all of these layers — from the captive portal server and RADIUS integration through to analytics, marketing automation, and compliance management — across more than 80,000 venues globally. If you're planning a deployment or evaluating your current setup, the Purple team can provide a technical architecture review.

Links to the full written guide, architecture diagrams, and implementation checklists are in the show notes. Thanks for listening.

Punti chiave

✓Captive portals operate at Layer 3, intercepting DNS and HTTP traffic to redirect unauthenticated users to a login page.
✓The 'Walled Garden' is a critical pre-authentication whitelist; misconfiguring it breaks portal rendering and third-party logins.
✓Never attempt to intercept HTTPS traffic; rely on OS-native Captive Network Assistant (CNA) probes.
✓RADIUS provides the backbone for Authentication, Authorisation (bandwidth limits, session timeouts), and Accounting (compliance logs).
✓Cloud-hosted portal and RADIUS infrastructure provides superior scalability and centralised management compared to on-premises servers.
✓MAC address caching enables seamless roaming for returning guests by bypassing the portal via MAB (MAC Authentication Bypass).
✓Modern platforms like Purple integrate captive portal functionality with OpenRoaming/Passpoint for secure, cellular-like connectivity.

Riepilogo Esecutivo

Per i responsabili IT e gli architetti di rete che implementano Guest WiFi pubblico o aziendale, il captive portal è il confine critico tra un dispositivo non autenticato e l'infrastruttura di rete. Questa guida fornisce un approfondimento tecnico su come funziona un captive portal—eliminando lo strato di marketing per esaminare i meccanismi sottostanti di intercettazione DNS, reindirizzamento HTTP, configurazione del walled garden e autenticazione RADIUS.

Sia che si stia progettando un'implementazione ad alta densità per uno stadio, una rete distribuita per Retail , o una soluzione conforme per Healthcare , comprendere il ciclo di vita della sessione e le dipendenze architetturali è essenziale. Un portal mal configurato porta a esperienze utente degradate, avvisi di sicurezza del browser e potenziali fallimenti di conformità. Questa guida di riferimento delinea l'architettura tecnica, le migliori pratiche di implementazione e le modalità di errore comuni per garantire che la vostra implementazione sia sicura, scalabile e conforme agli standard moderni come WPA3 e Passpoint.

Approfondimento Tecnico

Nella sua essenza, un captive portal è un meccanismo di controllo dell'accesso alla rete di Livello 3. Intercetta il traffico da un dispositivo associato ma non autenticato, reindirizzando l'utente a un'interfaccia di autenticazione prima di concedere l'accesso completo alla rete.

Il processo si basa su una sequenza coordinata di servizi di rete:

1. Associazione e Assegnazione IP Quando un dispositivo ospite si connette all'SSID, l'access point wireless o il controller collega la connessione a una VLAN specifica. Il server DHCP locale assegna un indirizzo IP, una subnet mask e un gateway predefinito. In questa fase, il dispositivo è connesso al Livello 2 ma si trova in uno stato di "pre-autenticazione" al Livello 3. Tutto il traffico in uscita è soggetto a liste di controllo degli accessi (ACL) rigorose imposte dal network access server (NAS), tipicamente il wireless LAN controller (WLC) o il firewall di bordo.

2. Intercettazione DNS (DNS Spoofing) Per attivare il captive portal, la rete deve intercettare le richieste web iniziali dell'utente. Quando il dispositivo tenta di risolvere un nome di dominio (ad esempio, www.example.com), la query DNS viene intercettata dal NAS o da un server DNS dedicato all'interno del walled garden. Invece di restituire l'indirizzo IP pubblico effettivo per il dominio richiesto, il server DNS restituisce l'indirizzo IP del server captive portal.

3. Reindirizzamento HTTP Quando il browser del client tenta una connessione HTTP all'indirizzo IP spoofato, il server captive portal risponde con un reindirizzamento HTTP 302 (Found) o HTTP 303 (See Other). Questo istruisce il browser a navigare all'URL effettivo della pagina di login del captive portal.

I sistemi operativi moderni impiegano meccanismi di Captive Network Assistant (CNA) per rilevare questo automaticamente. Dopo essersi connesso a una rete, il sistema operativo invia una richiesta HTTP GET a un URL di prova noto (ad esempio, captive.apple.com per iOS/macOS, msftconnecttest.com per Windows). Se il sistema operativo riceve un reindirizzamento HTTP invece del previsto 200 OK o di un payload HTML specifico, presume la presenza di un captive portal e avvia automaticamente un pseudo-browser per visualizzare la pagina del portal.

4. Il Walled Garden Durante lo stato di pre-autenticazione, l'utente deve essere in grado di caricare la pagina del portal e le sue risorse associate. Il "walled garden" è una whitelist di indirizzi IP, subnet e domini configurati sul NAS. Il traffico destinato a queste posizioni in whitelist è consentito, mentre tutto il resto del traffico viene bloccato. Un walled garden correttamente configurato deve includere:

L'indirizzo IP del server captive portal.
Content Delivery Networks (CDN) che ospitano CSS, JavaScript e risorse immagine per la pagina del portal.
Provider di identità (ad esempio, Facebook, Google) se il social login è abilitato.
Gateway di pagamento se il portal richiede accesso a pagamento.

5. Autenticazione e RADIUS Una volta che l'utente invia le proprie credenziali o accetta i termini di servizio, il server captive portal agisce come client RADIUS. Costruisce un pacchetto RADIUS Access-Request contenente i dettagli dell'utente e lo invia al server RADIUS (Remote Authentication Dial-In User Service).

Il server RADIUS convalida la richiesta rispetto al suo database. In caso di successo, restituisce un pacchetto Access-Accept. Fondamentalmente, questo pacchetto può includere Attributi Specifici del Fornitore (VSA) che definiscono i parametri della sessione, come Session-Timeout (durata massima della connessione), Idle-Timeout e limiti di velocità della larghezza di banda.

6. Attivazione e Contabilizzazione della Sessione Alla ricezione dell' Access-Accept, il server captive portal istruisce il NAS ad autorizzare l'indirizzo MAC del client. Le restrizioni del walled garden vengono rimosse e al dispositivo viene concesso l'accesso completo a internet. Contemporaneamente, il NAS invia un pacchetto RADIUS Accounting-Request (Start) al server RADIUS per iniziare a tracciare la sessione a fini di analisi e conformità.

Guida all'Implementazione

L'implementazione di un captive portal robusto richiede un'attenta coordinazione tra l'infrastruttura wireless e la piattaforma del portal. Per i responsabili IT che valutano Guest WiFi Providers: What to Look for When Choosing a WiFi Platform , considerate i seguenti approcci architetturali:

Cloud-Hosted vs. On-Premises Modern enterprise deployments hefavoriscono fortemente l'infrastruttura di portale e RADIUS ospitata nel cloud. Piattaforme come Purple forniscono un'architettura RADIUS distribuita globalmente, eliminando la necessità di server AAA on-premises. Il WLC locale punta semplicemente le sue richieste di autenticazione e accounting RADIUS agli endpoint del provider cloud. Questo approccio si scala senza problemi e centralizza la gestione su più siti, il che è particolarmente vantaggioso per gli ambienti distribuiti di Hospitality e retail.

Configurazione del Walled Garden La causa più frequente dei problemi di rendering del portale è un walled garden incompleto. Le moderne pagine web si basano fortemente su risorse esterne. Se un font o una libreria JavaScript ospitata su una CDN di terze parti viene bloccata, il portale potrebbe bloccarsi o essere visualizzato in modo errato all'interno del browser CNA del sistema operativo.

Raccomandazione: Utilizzare voci di walled garden basate su dominio dove supportato dal WLC (es. *.purple.ai). Se il tuo hardware supporta solo walled garden basati su IP, devi mantenere un elenco aggiornato delle sottoreti IP del provider del portale.

Gestione dell'intercettazione HTTPS Storicamente, i Captive Portal intercettavano tutto il traffico sulla porta 80 (HTTP) e sulla porta 443 (HTTPS). Tuttavia, con l'adozione diffusa di HTTP Strict Transport Security (HSTS), l'intercettazione del traffico HTTPS fa sì che i browser visualizzino gravi avvisi di sicurezza, poiché il certificato SSL del portale non corrisponderà al dominio richiesto.

Raccomandazione: Non intercettare mai il traffico HTTPS. Affidarsi interamente ai meccanismi CNA nativi del sistema operativo (che sondano tramite HTTP) o istruire esplicitamente gli utenti a navigare verso un URL HTTP noto (es. http://neverssl.com) per attivare il reindirizzamento.

Best Practice

1. Caching degli indirizzi MAC per un roaming senza interruzioni Per migliorare l'esperienza utente, implementare il caching degli indirizzi MAC. Quando un utente si autentica con successo, il server RADIUS registra il suo indirizzo MAC. Se l'utente si disconnette e ritorna entro un periodo specificato (es. 30 giorni), il WLC invia una richiesta di MAC authentication bypass (MAB) al server RADIUS. Il server riconosce l'indirizzo MAC e restituisce immediatamente un Access-Accept, garantendo l'accesso alla rete senza richiedere all'utente di interagire nuovamente con il portale.

2. Progettazione per il Captive Network Assistant (CNA) I pseudo-browser lanciati da iOS e Android per visualizzare i Captive Portal hanno funzionalità limitate rispetto ai browser completi. Spesso non supportano i pop-up, hanno rigidi vincoli di timeout e gestiscono i cookie in modo diverso.

Raccomandazione: Mantenere l'interfaccia utente del portale leggera. Evitare framework JavaScript complessi o risorse multimediali pesanti che potrebbero causare il timeout del CNA. Se sono richieste interazioni complesse (come download di app), utilizzare prima il portale per autorizzare il dispositivo, quindi reindirizzare l'utente al suo browser nativo.

3. Integrazione con OpenRoaming e Passpoint Mentre i Captive Portal rimangono essenziali per l'acquisizione dei dati e l'accettazione dei termini, l'industria si sta muovendo verso standard di autenticazione senza interruzioni come Passpoint (Hotspot 2.0). Purple agisce come un provider di identità gratuito per servizi come OpenRoaming sotto la licenza Connect. I dispositivi configurati con un profilo OpenRoaming possono autenticarsi in modo sicuro al Livello 2 (tramite 802.1X/EAP) senza interagire con un Captive Portal, fornendo un'esperienza di roaming simile a quella cellulare. La tua infrastruttura dovrebbe supportare entrambi i meccanismi contemporaneamente.

Risoluzione dei Problemi e Mitigazione del Rischio

Sintomo: La pagina del portale non appare automaticamente sui dispositivi mobili.

Causa Radice: Il walled garden è configurato in modo errato, consentendo alle richieste di sonda CNA del sistema operativo di raggiungere direttamente internet. Se il sistema operativo riceve un 200 OK da captive.apple.com, presume di avere pieno accesso a internet e non avvierà il portale.
Mitigazione: Assicurarsi che i domini di sonda CNA non siano nella whitelist del walled garden. Devono essere intercettati e reindirizzati al server del portale.

Sintomo: Gli utenti visualizzano un avviso di certificato SSL/TLS.

Causa Radice: Il WLC sta tentando di intercettare il traffico HTTPS e sta presentando il certificato SSL del portale invece del certificato per il dominio richiesto dall'utente.
Mitigazione: Disabilitare il reindirizzamento HTTPS sul WLC.

Sintomo: Il login social (es. Facebook, Google) non si carica o non si autentica.

Causa Radice: I domini richiesti per il flusso OAuth del provider di identità mancano dal walled garden.
Mitigazione: Verificare la configurazione del walled garden rispetto alla documentazione attuale del provider di identità. Si noti che questi intervalli IP e domini cambiano frequentemente.

ROI e Impatto Commerciale

Un Captive Portal non è solo una necessità tecnica; è una risorsa strategica. Sostituendo le chiavi pre-condivise (PSK) generiche con un portale gestito, le organizzazioni ottengono:

Acquisizione Dati e Marketing Automation: L'integrazione del portale con una piattaforma di WiFi Analytics consente alle sedi di raccogliere dati di prima parte verificati (email, dati demografici) in cambio dell'accesso. Questi dati alimentano i sistemi CRM e le campagne di marketing mirate.
Conformità e Mitigazione del Rischio: Gli operatori di WiFi pubblico sono soggetti a leggi sulla conservazione dei dati e responsabilità per violazione del copyright. Un Captive Portal con accounting RADIUS fornisce un registro verificabile di quale dispositivo (indirizzo MAC) ha detenuto quale indirizzo IP in un momento specifico, proteggendo la sede da responsabilità.
Gestione della Larghezza di Banda: Applicando attributi RADIUS come Filter-Id o WISPr-Bandwidth-Max-Down, l'IT può impedire ai singoli utenti di monopolizzare la connessione WAN, garantendo un'esperienza coerente per tutti gli ospiti e proteggendo il traffico critico di back-office. Ciò è particolarmente rilevante quando si valutano I Vantaggi Chiave dell'SD WAN per le Aziende Moderne .

Termini chiave e definizioni

Walled Garden

An access control list (ACL) applied to unauthenticated users, permitting traffic only to specific IP addresses or domains required to load the captive portal.

Crucial for allowing access to CDNs, payment gateways, and social login APIs before the user is fully authorised.

RADIUS (Remote Authentication Dial-In User Service)

The industry-standard networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) management.

The captive portal server uses RADIUS to tell the wireless controller whether a user is allowed on the network and what restrictions apply.

Captive Network Assistant (CNA)

A pseudo-browser built into modern operating systems (iOS, Android, Windows) designed specifically to detect and display captive portals.

CNAs have limited functionality compared to full browsers; portals must be designed to accommodate their constraints.

MAC Authentication Bypass (MAB)

A process where the network uses a device's MAC address as its identity to authenticate against a RADIUS server without user interaction.

Used to implement 'MAC Caching', allowing returning guests to connect seamlessly without seeing the portal again.

DNS Interception / Spoofing

The process where the network intercepts a user's DNS query and returns the IP address of the captive portal server instead of the actual destination.

This is the primary mechanism used to force the user's web traffic to the portal page.

HTTP 302 Redirect

An HTTP response status code indicating that the requested resource has been temporarily moved to a different URI.

Used by the portal server to redirect the intercepted HTTP request to the actual login page URL.

Vendor-Specific Attributes (VSAs)

Custom parameters included in a RADIUS message that allow vendors to support features not defined in the base RADIUS standard.

Used to pass specific policies, like bandwidth limits or VLAN assignments, from the portal platform to the specific brand of wireless controller.

Passpoint (Hotspot 2.0)

A standard that enables mobile devices to automatically discover and authenticate to Wi-Fi networks securely without user interaction.

The modern alternative to captive portals for seamless roaming; platforms like Purple act as identity providers for Passpoint networks.

Casi di studio

A 500-room hotel is upgrading its guest WiFi. They want returning guests to connect seamlessly without seeing the portal again for 30 days, but they require a daily bandwidth limit of 10Mbps per device.

Configure the WLC to use external RADIUS authentication pointing to the cloud provider. 2. Enable MAC Address Caching on the RADIUS server with a 30-day retention policy. 3. Configure the portal profile to assign a RADIUS Vendor-Specific Attribute (VSA) for bandwidth limiting (e.g., WISPr-Bandwidth-Max-Down = 10000000) in the Access-Accept packet.

Note di implementazione: This approach balances user experience with network protection. By using MAC caching, the initial captive portal interaction is preserved for terms acceptance, while subsequent connections rely on seamless MAB (MAC Authentication Bypass) at Layer 2. The bandwidth VSA ensures the WLC enforces the limit dynamically.

A retail chain deploys a new captive portal featuring a Facebook login option. Users report that when they click the Facebook button, the page hangs indefinitely inside the captive portal pop-up.

The WLC's walled garden configuration is incomplete. The network administrator must add Facebook's required OAuth domains (e.g., graph.facebook.com, connect.facebook.net) and IP subnets to the pre-authentication ACL.

Note di implementazione: This is the most common failure mode in modern portal deployments. Because the device is in a pre-authenticated state, any traffic to domains not explicitly whitelisted in the walled garden is dropped. The CNA browser simply times out waiting for the Facebook API response.

Analisi degli scenari

Q1. You are deploying a captive portal at a stadium. The portal requires users to watch a 15-second video hosted on YouTube before gaining access. Users are reporting that the portal loads, but the video frame is blank. What is the most likely architectural cause?

💡 Suggerimento:Consider the state of the device before it is fully authenticated and what resources it needs to access.

Mostra l'approccio consigliato

The walled garden configuration is incomplete. The network administrator must add YouTube's video delivery domains and CDNs to the walled garden ACL. Without this, the unauthenticated device cannot reach the YouTube servers to stream the video content, even though the main portal page (hosted elsewhere) loads successfully.

Q2. A client insists on intercepting all HTTPS traffic to force users to the captive portal, arguing that users rarely type 'http://' anymore. Why is this a bad idea, and what is the standard alternative?

💡 Suggerimento:Think about how modern browsers handle SSL/TLS certificates and HSTS.

Mostra l'approccio consigliato

Intercepting HTTPS traffic requires the wireless controller to present a certificate for the requested domain (e.g., google.com). Since the controller does not possess Google's private key, the browser will flag the connection as insecure and display a severe certificate warning, breaking the user experience. The standard alternative is to rely on the Operating System's built-in Captive Network Assistant (CNA), which automatically probes known HTTP URLs in the background specifically to trigger the redirect gracefully.

Q3. A venue wants to limit guest WiFi sessions to 2 hours. How is this enforced technically within the captive portal architecture?

💡 Suggerimento:Which component is responsible for Authorisation and passing policy parameters to the network hardware?

Mostra l'approccio consigliato

This is enforced via RADIUS. When the captive portal server successfully authenticates the user, it receives an Access-Accept packet from the RADIUS server. This packet includes a 'Session-Timeout' attribute set to 7200 seconds (2 hours). The wireless controller reads this attribute, applies the timer to the user's session, and automatically disconnects the device when the timer expires.