Vai al contenuto principale
Italiano

Login al Captive Portal: Risoluzione dei problemi e guida esplicativa

Questa guida fornisce un riferimento tecnico completo per comprendere, implementare e risolvere i problemi dei sistemi di login al captive portal in ambienti WiFi aziendali per ospiti. Spiega gli esatti meccanismi di reindirizzamento HTTP e di dirottamento DNS utilizzati dai moderni captive portal, descrive in dettaglio come l'HSTS e i browser HTTPS sicuri possano bloccare i reindirizzamenti locali e fornisce una checklist di risoluzione dei problemi chiara e pratica che copre sia le soluzioni lato client (disattivazione delle VPN, disattivazione della randomizzazione MAC, utilizzo di NeverSSL) sia le risoluzioni lato operatore (configurazione del walled garden, ottimizzazione del tempo di lease DHCP, verifica dell'intercettazione DNS). I gestori delle sedi, i responsabili IT e gli architetti di rete troveranno questa guida essenziale per ridurre al minimo i ticket di supporto degli ospiti e massimizzare il ROI della loro infrastruttura wireless.

📖 3 minuti di lettura📝 605 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast
TITLE: Captive Portal Login — Troubleshooting and Explainer FORMAT: Purple Technical Briefing Podcast VOICE: UK English Male — Senior Solutions Architect tone DURATION: Approximately 8 minutes --- [SECTION 1: Introduction & Context — 0:00 to 1:15] Hello, and welcome to this technical briefing from Purple. I'm your host, and today we are tackling one of the most common, yet frustrating challenges in enterprise wireless networking: the captive portal login failure. We've all been there. You connect to a guest WiFi network at a hotel, a retail store, or an airport, and nothing happens. The login page doesn't appear, your internet connection is dead, and you're left staring at a blank screen or a cryptic security warning. For venue operations directors and IT managers, this isn't just a minor technical glitch. It's a direct threat to customer satisfaction, a driver of support tickets, and a barrier to capturing the valuable guest analytics that justify your wireless infrastructure ROI. In this podcast, we're going to look under the hood of modern captive portals. We'll explain exactly how the HTTP redirect mechanism works, why secure web standards like HSTS can sometimes block it, and we'll arm you with a practical troubleshooting checklist for both your guests and your IT teams. Let's dive in. --- [SECTION 2: Technical Deep-Dive — 1:15 to 6:15] To understand why a captive portal fails to load, we first have to understand how a device detects it in the first place. When your smartphone or laptop associates with an open guest SSID and receives an IP address via DHCP, the operating system doesn't wait for you to open a browser. In the background, a system service immediately fires off an unencrypted HTTP GET request to a specific, vendor-controlled canary URL. For Apple devices, it queries captive.apple.com/hotspot-detect.html and looks for the word Success. Google devices query a gstatic generate-204 URL, expecting a 204 No Content status code. Windows devices query a Microsoft connect test text file. If the network has open internet access, these probes succeed, and the OS stays quiet. But on a guest network, the wireless gateway or controller intercepts this HTTP probe. Instead of letting it reach the public internet, the gateway returns an HTTP 302 or 303 redirect pointing to the secure FQDN of the captive portal splash page. The operating system detects this unexpected redirect, realizes it is behind a captive portal, and immediately pops up a specialized, sandboxed browser window — often called the Captive Portal Assistant — to display the login page. Now, this redirect mechanism worked beautifully for years. But then came the HTTPS revolution and a critical standard called HSTS, or HTTP Strict Transport Security. HSTS is a security policy that forces browsers to only communicate with websites using secure, encrypted HTTPS connections. If a guest connects to your WiFi and their browser or an app attempts to contact an HSTS-enabled domain — like Google, Facebook, or their banking portal — the browser strictly enforces SSL/TLS certificate validation. If your wireless gateway tries to hijack that HTTPS request and redirect it to the captive portal, it has to present an SSL certificate. Because the gateway's certificate doesn't match the requested domain name, the browser detects a man-in-the-middle attack. It displays a massive, non-bypassable security warning and blocks the redirect entirely. The user gets a broken page, and the captive portal never loads. To solve this, modern networks must ensure that the initial unencrypted HTTP probes sent by the operating systems are exempt from HTTPS interception, allowing them to redirect cleanly to the portal's secure domain. Furthermore, we are seeing the adoption of RFC 8910, which defines a standardized Captive Portal API. This allows the DHCP server to directly inform the client device of the captive portal's URL, bypassing the need for DNS hijacking or HTTP redirection entirely. --- [SECTION 3: Implementation Recommendations & Pitfalls — 6:15 to 8:15] So, how do we implement a robust captive portal that avoids these pitfalls? First, let's talk about the Walled Garden, or the pre-authentication Access Control List. This is the list of external domains that unauthenticated guests are allowed to access. If your walled garden is misconfigured, the captive portal page simply won't load. You must include not only the FQDN of your splash page — such as Purple's cloud servers — but also the domains of any social identity providers like Google, Apple, or Facebook if you offer social logins. Because these providers constantly update their authentication domains and CDN IP ranges, using a wireless controller that supports wildcard domain snooping is an absolute must. Second, optimize your DHCP and DNS. In busy venues like shopping malls or stadiums, IP address exhaustion is a silent killer. If your guest DHCP lease time is set to the default 24 hours, you will run out of IP addresses rapidly. Set guest lease times to between 15 and 30 minutes. Also, ensure your DNS servers are highly responsive and that pre-authenticated users are permitted to make DNS queries. If they can't resolve the canary URLs, the portal detection sequence fails before it even starts. And finally, consider transitioning to profile-based authentication like OpenRoaming. Under our Purple Connect license, Purple acts as a free identity provider for OpenRoaming. This allows returning guests to automatically and securely connect to your WiFi at Layer 2, completely bypassing the captive portal after their first visit. It delivers a seamless, cellular-like experience while maintaining top-tier security. --- [SECTION 4: Rapid-Fire Q&A — 8:15 to 9:15] Let's run through a quick, rapid-fire Q&A based on the most common questions we get from venue operations teams. Question one: Why is my guest WiFi login page not appearing automatically? This is almost always caused by an active VPN on the guest's device, or because they are using a custom, secure DNS setting like DNS-over-HTTPS. Both of these prevent the local gateway from intercepting the initial HTTP probe. Question two: How can a guest manually force the captive portal page to load? Instruct them to open a standard browser window and type in http://neverssl.com. Because this site is designed to never use SSL, the gateway can easily intercept the request and trigger the redirect. Question three: Why does a guest have to log in again every time they walk away for a few minutes? This is due to MAC address randomization, a default privacy feature on modern iOS and Android devices. It presents a new MAC address to the network, breaking session persistence. Instruct them to disable Private Address for your guest SSID. --- [SECTION 5: Summary & Next Steps — 9:15 to 10:00] To summarize, a reliable guest WiFi experience is built on a deep understanding of captive portal mechanics. By optimizing your walled garden, managing your DHCP scopes, and educating your front-of-house staff on simple client-side fixes like disabling VPNs and using NeverSSL, you can drastically reduce support tickets and keep your guests connected. For enterprise-grade reliability, Purple's cloud-managed captive portal platform provides robust, cross-device compatibility out of the box, ensuring your redirection mechanism works flawlessly every time. Thank you for listening to this Purple technical briefing. For more guides and resources, visit our website at purple.ai. Until next time, keep your networks secure and your guests connected.

📚 Part of our core series: La guida definitiva ai Captive Portal →

header_image.png

Executive Summary

Per le moderne strutture aziendali, le reti wireless per gli ospiti non sono più un semplice servizio di cortesia; rappresentano un punto di contatto fondamentale per il coinvolgimento dei clienti, l'intelligence operativa e il posizionamento del brand. Tuttavia, il valore aziendale di queste reti dipende interamente dall'affidabilità dell'esperienza di connessione iniziale. Quando un ospite si connette a una rete e la pagina di login al captive portal non viene visualizzata, la struttura subisce immediatamente un aumento degli attriti nel front-of-house, un'impennata dei ticket di supporto e la perdita di opportunità di acquisizione dati.

Alla base di questi problemi c'è una tensione fondamentale tra gli standard web sicuri e le tecniche di intercettazione a livello di rete storicamente utilizzate dai captive portal. I moderni browser web e sistemi operativi sono progettati per rilevare e bloccare il reindirizzamento non autorizzato del traffico per proteggere gli utenti dagli attacchi man-in-the-middle (MitM). Comprendendo le precise sequenze di reindirizzamento HTTP e DNS, l'impatto di protocolli sicuri come l'HTTP Strict Transport Security (HSTS) e le impostazioni lato client che disturbano questi meccanismi, le organizzazioni IT possono implementare configurazioni robuste che garantiscono un onboarding senza interruzioni.

Questa guida descrive in dettaglio come la piattaforma Guest WiFi gestita in cloud di Purple affronti queste sfide per offrire un reindirizzamento ad alta disponibilità su tutti i sistemi operativi consumer, riducendo al minimo i costi di supporto della struttura e massimizzando il ritorno sugli investimenti nell'infrastruttura wireless. Sia che l'installazione avvenga in ambienti del settore Hospitality , Retail , Healthcare o Transport , i principi e le checklist di questa guida si applicano universalmente.

Approfondimento tecnico

Per risolvere efficacemente i problemi del captive portal, gli amministratori di rete devono comprendere l'esatta sequenza di eventi che si verifica quando un dispositivo client si connette a una rete wireless per ospiti aperta o con chiave precondivisa (PSK). I moderni sistemi operativi — inclusi Apple iOS/macOS, Google Android, Microsoft Windows e le distribuzioni Linux — non attendono che l'utente apra un browser per verificare la connettività Internet. Invece, eseguono un meccanismo di probing attivo automatizzato immediatamente dopo aver completato le fasi di associazione e DHCP.

La sequenza di rilevamento del Captive Portal

Il processo di connessione e verifica segue una sequenza altamente strutturata:

Passaggio Azione Descrizione tecnica Indicatore di successo previsto
1 Associazione Il client si associa all'SSID Guest al Livello 2. Scambio di frame di associazione 802.11 riuscito.
2 Assegnazione IP Il server DHCP assegna un indirizzo IP, una subnet mask, un gateway e un server DNS locale. Pacchetto DHCP ACK ricevuto dal client.
3 Probing attivo Il servizio in background del sistema operativo invia una richiesta HTTP GET non crittografata a un URL canary specifico del fornitore. HTTP 200 OK (Apple/Windows) o HTTP 204 No Content (Google).
4 Intercettazione e reindirizzamento Il gateway/controller wireless intercetta il probe HTTP e restituisce un reindirizzamento HTTP 302/303 che punta al portale. Reindirizzamento HTTP 302 al FQDN del captive portal.
5 Rendering del portale Il motore del browser del Captive Portal Assistant (CPA) si apre e mostra la splash page. Rendering riuscito dell'interfaccia di login. 
+--------+             +------------+             +------------+             +-------------------+
| Client |             | AP/Gateway |             | Server DNS |             | IP Captive Portal |
+--------+             +------------+             +------------+             +-------------------+
    |                        |                          |                              |
    |--- 1. Richiesta DHCP ->|                          |                              |
    |<-- 2. DHCP Ack --------|                          |                              |
    | (IP e DNS assegnati)   |                          |                              |
    |--- 3. Query DNS ------->|------------------------->|                              |
    |    (URL canary)        |                          |                              |
    |<-- 4. Risposta DNS ----|<-------------------------|                              |
    |    (IP risolto)        |                          |                              |
    |--- 5. HTTP GET ------->|                          |                              |
    |    (URL canary)        |                          |                              |
    |<-- 6. HTTP 302 --------|                          |                              |
    | (Reindirizz. a portale)|                          |                              |
    |--- 7. Query DNS ------->|------------------------->|                              |
    |    (FQDN portale)      |                          |                              |
    |<-- 8. Risposta DNS ----|<-------------------------|                              |
    |    (IP portale)        |                          |                              |
    |--- 9. HTTP/S GET ------>-------------------------------------------------------->|
    | (Mostra splash page)   |                          |                              |
    |<-- 10. Mostra pagina <-----------------------------------------------------------|

captive_portal_redirect_flow.png

Ogni sistema operativo utilizza un set distinto di URL canary e risposte previste per determinare lo stato della rete. Apple (iOS/macOS) interroga http://captive.apple.com/hotspot-detect.html aspettandosi un documento HTML contenente solo la parola Success sia nel titolo e corpo. Google (Android/ChromeOS) interroga http://connectivitycheck.gstatic.com/generate_204 aspettandosi un codice di stato HTTP 204 No Content con un corpo vuoto. Microsoft (Windows 10/11) interroga http://www.msftconnecttest.com/connecttest.txt aspettandosi una risposta in testo normale pari a Microsoft Connect Test.

Se il dispositivo riceve la risposta prevista, deduce che la rete ha un accesso a Internet diretto e senza ostacoli. Se la risposta viene modificata — ad esempio ricevendo un reindirizzamento HTTP 302 — il Captive Portal Assistant (CPA) del sistema operativo avvia immediatamente una finestra del browser dedicata e isolata (sandbox) per visualizzare la destinazione del reindirizzamento: la pagina di login del Captive Portal.

Il conflitto di reindirizzamento HSTS e HTTPS

Il metodo storico di reindirizzamento del Captive Portal si basa sul dirottamento DNS (DNS hijacking) o sull'intercettazione HTTP. Quando un utente non autenticato tenta di navigare su un qualsiasi sito web, il gateway intercetta il traffico sulla porta TCP 80 (HTTP) o sulla porta 443 (HTTPS) e risponde per conto del server di destinazione, inserendo un reindirizzamento HTTP 302. Sebbene questo funzionasse perfettamente in un'era di navigazione web HTTP non crittografata, introduce gravi sfide operative e di sicurezza nei moderni ambienti dominati dall'HTTPS.

L'ostacolo principale è l'HTTP Strict Transport Security (HSTS), un meccanismo di policy di sicurezza web specificato in RFC 6797. L'HSTS costringe i browser web a interagire con i siti web utilizzando solo connessioni HTTPS sicure. Quando un browser tenta di connettersi a un dominio abilitato HSTS — come Google, Facebook o portali bancari — vieta rigorosamente qualsiasi comunicazione non crittografata e impone una convalida rigorosa del certificato SSL/TLS.

Se un gateway Captive Portal tenta di intercettare una richiesta HTTPS verso un dominio HSTS, deve presentare al client il proprio certificato SSL o un certificato contraffatto. Poiché il certificato del gateway non corrisponde al nome di dominio richiesto, il browser del client rileva un attacco man-in-the-middle e mostra un avviso di sicurezza non ignorabile (ad es. NET::ERR_CERT_COMMON_NAME_INVALID o La connessione non è privata). Il browser blocca completamente il reindirizzamento, impedendo il caricamento della pagina del Captive Portal e lasciando l'utente con una connessione interrotta.

Per mitigare questo problema, le moderne reti wireless aziendali utilizzano due meccanismi avanzati. In primo luogo, l'esenzione delle sonde del sistema operativo (OS probes) garantisce che le sonde HTTP non crittografate inviate dai sistemi operativi non siano mai soggette a intercettazione HTTPS; il gateway deve consentire il reindirizzamento della sonda HTTP non crittografata utilizzando una risposta HTTP 302 standard verso il nome di dominio completo (FQDN) sicuro del Captive Portal. In secondo luogo, l'RFC 8910 (Captive Portal API) definisce un meccanismo in cui le opzioni DHCP (Opzione 114) o i Router Advertisement IPv6 informano il dispositivo client dell'URL esatto dell'endpoint dell'API del Captive Portal. Invece di affidarsi al dirottamento DNS a forza bruta o al reindirizzamento HTTP, i dispositivi client compatibili interrogano direttamente questa API per ottenere l'URL del portale e lo stato della rete, aggirando completamente il conflitto HSTS.

Guida all'implementazione

La distribuzione di un Captive Portal affidabile richiede un'attenta coordinazione tra l'infrastruttura wireless fisica (Access Point, Controller, Gateway) e la piattaforma del portale basata su cloud. Questa sezione fornisce una guida all'implementazione passo-passo e indipendente dal fornitore per garantire una solida compatibilità di reindirizzamento sulle reti aziendali, facendo riferimento alle configurazioni standard presenti nei controller di Cisco, Aruba e Ruckus. Per l'architettura di controllo degli accessi correlata, consulta la guida su Come implementare l'autenticazione 802.1X con Cloud RADIUS .

Passaggio 1: Configurazione del Walled Garden (ACL)

Un Walled Garden o Access Control List (ACL) definisce gli specifici domini esterni, indirizzi IP o sottoreti a cui un dispositivo ospite non autenticato è autorizzato ad accedere prima di effettuare l'accesso. Se il walled garden è configurato in modo errato, il dispositivo client non sarà in grado di risolvere o caricare le risorse del Captive Portal, con conseguente schermata vuota o errore di timeout.

Per garantire un funzionamento ottimale con la piattaforma di Purple, il walled garden deve includere i seguenti componenti. I FQDN del portale sono i nomi di dominio completi dei server che ospitano la splash page (ad es. *.purple.ai o varianti regionali). Gli Identity Provider (IdP) devono essere inclusi se il portale supporta il social login — il walled garden deve includere l'elenco completo dei domini utilizzati da questi provider per l'autenticazione OAuth. Devono essere incluse anche le Content Delivery Network (CDN) che ospitano CSS, JavaScript, font o immagini utilizzati nella splash page.

Molti controller moderni supportano i nomi di dominio con caratteri jolly (ad es. *.purple.ai) nelle loro configurazioni di walled garden. Il controller esegue lo snoop dinamico delle query DNS dei client non autenticati; quando un client interroga un dominio corrispondente al carattere jolly, il controller aggiunge temporaneamente l'indirizzo IP restituito alla allowlist di pre-autenticazione del client. Per i controller legacy che supportano solo indirizzi IP statici, gli amministratori devono configurare un proxy DNS locale o aggiornare regolarmente i blocchi IP statici associati al portale cloud.

Passaggio 2: Ottimizzazione di DHCP e DNS

Poiché il rilevamento del Captive Portal dipende fortemente dall'handshake di rete iniziale, le configurazioni DHCP e DNS devono essere ottimizzate per ambienti ad alta densità e di passaggio. In luoghi ad alta affluenza come centri commerciali, snodi di transito o stadi, l'esaurimento degli indirizzi IP è una causa comune di malfunzionamento del Captive Portal. Se il tempo di lease DHCP è impostato su un valore troppo lungo (ad es. 24 ore), il pool di IP si esaurirà rapidamente, impedendo ai nuovi ospiti di ottenere un indirizzo IP. Per le reti ospiti, il tempo di lease DHCP deve essere configurato tra 15 e 30 minuti (da 900 a 1800 secondi).

Ai client ospiti deve essere assegnato un server DNS affidabile e veloce, in grado di risolvere sia i domini pubblici sia l'FQDN locale del Captive Portal. Si raccomanda vivamente di utilizzare resolver DNS pubblici di livello aziendale come Cloudflare 1.1.1.1 o Google 8.8.8.8, oo un forwarder DNS locale ad alte prestazioni. Aspetto fondamentale, il gateway wireless deve consentire ai client non autenticati di eseguire la risoluzione DNS. Se una regola del firewall blocca il traffico sulla porta 53 (UDP/TCP) per gli utenti pre-autenticati, il sistema operativo del client non sarà in grado di risolvere gli URL canary e l'assistente del Captive Portal non si avvierà mai.

Step 3: Gestione dei certificati SSL/TLS

Quando un dispositivo ospite viene reindirizzato al Captive Portal, il browser stabilisce una connessione HTTPS sicura con l'FQDN del portale. Per evitare schermate di avviso sui certificati, il Captive Portal deve essere protetto con un certificato SSL/TLS valido e pubblicamente attendibile. I certificati autofirmati verranno immediatamente bloccati dai moderni sistemi operativi mobili, impedendo all'assistente del Captive Portal di caricare la pagina. Se il meccanismo di reindirizzamento richiede che il client comunichi con l'IP del gateway locale (ad esempio, per l'associazione locale MAC-to-IP), il gateway deve disporre di un certificato valido corrispondente al suo FQDN locale, e questo FQDN deve essere risolvibile dal DNS ospite.

Best Practice

Per mantenere una rete wireless per gli ospiti ad alte prestazioni che riduca al minimo i ticket di supporto e massimplichi la soddisfazione degli utenti, gli operatori di rete dovrebbero attenersi ai seguenti standard di settore e best practice.

1. Ottimizzare le regole del Walled Garden per i Social Login

Quando si utilizzano le opzioni di social login per acquisire i profili utente, il walled garden deve essere gestito meticolosamente. Le piattaforme di social media aggiornano frequentemente i loro sottodomini di autenticazione e gli intervalli IP delle CDN. Se un solo dominio richiesto manca dal walled garden, il popup del social login non si caricherà o rimarrà bloccato a tempo indeterminato.

Provider Domini Walled Garden essenziali
Google accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, lh3.googleusercontent.com
Facebook facebook.com, *.facebook.com, *.fbcdn.net, m.facebook.com
Apple appleid.apple.com, appleid.cdn-apple.com, gsa.apple.com

2. Transizione all'autenticazione basata su profilo e a OpenRoaming

Sebbene i Captive Portal siano eccellenti per l'acquisizione iniziale dei dati e l'accettazione dei termini di servizio, ripetere il processo di accesso a ogni visita introduce attrito per l'utente. Le moderne reti aziendali stanno passando sempre più all'autenticazione basata su profilo e alle tecnologie Passpoint (Hotspot 2.0), come OpenRoaming.

Sotto la licenza Purple Connect , Purple funge da identity provider gratuito per i servizi OpenRoaming. Passpoint consente a un ospite di installare un profilo sicuro sul proprio dispositivo durante la prima visita. Nelle visite successive a qualsiasi sede aderente in tutto il mondo, il dispositivo si associa automaticamente e in modo sicuro alla rete a livello Layer 2 utilizzando l'autenticazione WPA3-Enterprise e 802.1X, bypassando completamente il Captive Portal. Ciò offre un'esperienza di roaming fluida, simile a quella cellulare, mantenendo al contempo una trasmissione dati sicura e crittografata. Per una guida dettagliata all'implementazione, consulta Come implementare l'autenticazione 802.1X con Cloud RADIUS .

3. Garantire la conformità con i quadri normativi

Le distribuzioni WiFi per gli ospiti devono essere progettate nel rigoroso rispetto degli standard globali di sicurezza e privacy dei dati. Per la conformità GDPR / CCPA, il Captive Portal deve presentare termini di servizio e informative sulla privacy chiari e inequivocabili. Il consenso per le comunicazioni di marketing deve essere fornito attivamente tramite opt-in (non preselezionato) e gli utenti devono disporre di un meccanismo semplice per richiedere la cancellazione dei dati. Per la conformità PCI DSS, se la rete ospiti coesiste sulla stessa infrastruttura fisica dei sistemi Point of Sale (POS) della sede, deve essere applicata una rigorosa segmentazione logica. La VLAN ospiti deve essere completamente isolata dalle VLAN di produzione e delle carte di pagamento utilizzando regole firewall e ACL. Per la sicurezza wireless, implementa la modalità di transizione WPA3 per consentire ai dispositivi più vecchi di connettersi utilizzando WPA2-Personal, mentre i dispositivi più recenti beneficiano della maggiore sicurezza di WPA3, inclusi i Protected Management Frames (PMF).

Risoluzione dei problemi e mitigazione dei rischi

Quando vengono segnalati problemi con la rete wireless degli ospiti, il personale operativo e di reception della sede necessita di una sequenza diagnostica chiara e strutturata per identificare e risolvere la causa principale. I malfunzionamenti del Captive Portal rientrano in genere in due categorie: configurazioni errate lato client e problemi infrastrutturali lato operatore.

troubleshooting_checklist.png

Checklist diagnostica e di risoluzione lato client

Per il personale di reception che assiste gli ospiti, seguire questi passaggi in ordine.

1. Disabilitare le VPN attive. Le reti private virtuali (VPN) stabiliscono un tunnel crittografato dal dispositivo client direttamente a un server remoto. Poiché il client VPN tenta di crittografare e instradare tutto il traffico immediatamente dopo la connessione alla rete, bypassa le regole di hijack DNS e di reindirizzamento HTTP del gateway locale. L'ospite deve disabilitare temporaneamente la propria VPN per completare l'accesso al Captive Portal, dopodiché la VPN può essere riattivata in sicurezza.

2. Disattivare gli indirizzi MAC privati/casuali. I moderni sistemi operativi (iOS 14+ e Android 10+) abilitano per impostazione predefinita l'indirizzo Wi-Fi privato o la randomizzazione del MAC per impedire il tracciamento. Sebbene vantaggiosa per la privacy, questa funzione fa sì che il dispositivo presenti un indirizzo MAC diverso alla rete nelle connessioni successive o dopo un breve periodo di inattività. Ciò interrompe la persistenza della sessione basata su MAC, costringendo l'ospite a ripetere continuamente l'autenticazione. Istruisci l'ospite a disabilitare l'opzione Indirizzo privato per l'SSID della sede nelle impostazioni wireless del proprio dispositivo.

3. Bypassare il DNS sicuro (DoH/DoT). Se l'ospite ha configurato un server DNS personalizzato o utilizza DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT) nelle impostazioni del browser, quest'ultimo rifiuterà di accettare le risposte DNS reindirizzate del gateway locale. L'utente deve disabilitare temporaneamente il DNS sicuro in le impostazioni del browser o svuotare la cache DNS del dispositivo per consentire il funzionamento del reindirizzamento locale.

4. Forzare una connessione HTTP non crittografata (NeverSSL). Se l'assistente del Captive Portal non si avvia automaticamente, il browser dell'ospite potrebbe essere bloccato nel tentativo di caricare una pagina HTTPS. Istruire l'ospite ad aprire una finestra standard del browser e navigare su http://neverssl.com. Poiché questo sito web è esplicitamente progettato per non utilizzare mai SSL/TLS, il gateway può intercettare la richiesta HTTP e inserire correttamente il reindirizzamento HTTP 302 alla schermata di accesso a Internet per gli ospiti.

5. Dissociare e riconnettersi alla rete. Se una sessione di autenticazione precedente è stata interrotta in modo anomalo, il dispositivo client potrebbe conservare dati obsoleti nella cache DHCP o ARP. Dissociare la rete nelle impostazioni wireless e riconnettersi forza un handshake DHCP pulito e riavvia la sequenza di rilevamento del Captive Portal.

Risoluzione dei problemi dell'infrastruttura lato operatore

Per gli amministratori di rete che indicano problemi sistemici in cui più ospiti segnalano errori del portale, è necessario eseguire i seguenti controlli. Monitorare l'utilizzo del pool DHCP controllando lo scope DHCP sul gateway o router locale; se il pool è utilizzato al 100%, ridurre il tempo di lease a 5-10 minutes per recuperare rapidamente gli indirizzi IP degli ospiti che si sono allontanati. Verificare le regole di reindirizzamento DNS eseguendo un'acquisizione di pacchetti (PCAP) sull'interfaccia del gateway per confermare che i client non autenticati inviino correttamente le query DNS alla porta 53 e ricevano risposte. Verificare la latenza del Walled Garden per garantire che il walled garden sia ottimizzato e che la risoluzione DNS per i domini del walled garden venga memorizzata correttamente nella cache del controller. Infine, controllare la scadenza del certificato per assicurarsi che il certificato SSL/TLS installato sul controller wireless o sul gateway sia valido, non scaduto e firmato da un'Autorità di Certificazione (CA) attendibile.

ROI e impatto sul business

Investire in una solida piattaforma Captive Portal gestita in cloud come Purple genera ritorni finanziari e operativi misurabili per le grandi strutture. Risolvendo sistematicamente i problemi di accesso al Captive Portal, le organizzazioni influiscono direttamente sia sui ricavi che sui profitti.

Riduzione dei costi di supporto e dell'attrito per gli ospiti

Nelle strutture ricettive e nei punti vendita, il personale di contatto spende spesso tempo prezioso per risolvere i problemi di connettività WiFi degli ospiti. Un tasso elevato di errori del Captive Portal comporta una maggiore frustrazione degli ospiti e recensioni online negative, un volume elevato di ticket di supporto a bassa complessità inoltrati al team IT e inefficienze operative dovute alla distrazione del personale dalle proprie mansioni principali. Implementando il solido meccanismo di reindirizzamento di Purple, compatibile con diverse piattaforme, le strutture registrano in genere una riduzione dal 50% al 70% dei reclami di supporto relativi al WiFi.

Massimizzare l'acquisizione dei dati e il ROI del marketing

Un Captive Portal è il gateway principale per acquisire preziosi dati dei clienti di prima parte, inclusi indirizzi e-mail, numeri di telefono e profili social. Quando un Captive Portal non si carica, la struttura perde l'opportunità di registrare quell'ospite. Con un portale funzionante, le strutture possono raggiungere tassi di opt-in superiori al 60% per le comunicazioni di marketing, ampliando rapidamente il proprio database CRM dei clienti. Integrando l'autenticazione degli ospiti con WiFi Analytics , i gestori delle strutture ottengono informazioni approfondite sul comportamento dei visitatori, inclusi i tempi di permanenza, i tassi di ritorno e i flussi di passaggio nelle diverse zone.

Sbloccare opportunità di Retail Media e monetizzazione

Per le strutture su larga scala come centri commerciali, stadi e centri espositivi, il Captive Portal rappresenta uno spazio digitale di pregio. Utilizzando la splash page e le schermate di reindirizzamento post-accesso, i gestori possono accedere al mercato in rapida crescita dei Retail Media. Mostrate annunci pubblicitari altamente mirati e basati sulla posizione agli ospiti nell'esatto momento in cui si connettono, oppure vendete pacchetti di sponsorizzazione ai brand, trasformando un tradizionale centro di costo IT in una risorsa in grado di generare ricavi diretti.

Riferimenti

[1] Collaboratori di Wikipedia. "Captive Portal." Wikipedia, l'enciclopedia libera. https://en.wikipedia.org/wiki/Captive_portal

[2] IETF RFC 6797. "HTTP Strict Transport Security (HSTS)." Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc6797

[3] IETF RFC 8910. "Captive-Portal Identification in DHCP and Router Advertisements." Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc8910

[4] Wireless Broadband Alliance. "OpenRoaming." WBA. https://wballiance.com/openroaming/

[5] NeverSSL. "NeverSSL: Helping you get online." NeverSSL. http://neverssl.com/

Definizioni chiave

Captive Portal

A web page presented to newly connected users of a guest network before they are granted broader internet access. The portal typically requires authentication (email, social login, or voucher code), acceptance of terms of service, or both. It is the primary mechanism for guest data capture in enterprise WiFi deployments.

IT teams encounter captive portals as the first point of failure in guest WiFi complaints. Understanding the portal's technical architecture is essential for diagnosing why the login page fails to appear.

DNS Hijacking

A technique used by captive portal gateways where the local DNS server returns the IP address of the captive portal server in response to all DNS queries from unauthenticated clients, regardless of the actual domain being queried. This forces the client's browser to connect to the portal rather than the intended destination.

DNS hijacking is the core mechanism behind most captive portal redirect implementations. It is effective for HTTP traffic but is blocked by DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) configurations on client devices.

HTTP Strict Transport Security (HSTS)

A web security policy mechanism (RFC 6797) that instructs browsers to only communicate with a website using HTTPS, and to refuse any HTTP connections or connections with invalid SSL certificates. Once a browser has received an HSTS header from a domain, it enforces this policy for a specified duration (max-age), even if the user manually types an HTTP URL.

HSTS is the primary reason why captive portal redirects fail on modern devices. When a gateway attempts to intercept an HTTPS request to an HSTS-enabled domain, the browser detects the certificate mismatch and blocks the redirect, preventing the portal from loading.

Captive Portal Assistant (CPA)

A sandboxed, lightweight browser process built into modern operating systems (Apple's CNA, Android's CPA, Windows' NCSI) that automatically launches when the OS detects it is behind a captive portal. The CPA renders the splash page in a restricted environment that prevents the portal from accessing device credentials or persistent storage.

The CPA is what causes the login page to pop up automatically on most devices. If the CPA fails to launch (e.g., due to a VPN or DoH), the guest must manually navigate to the portal URL.

Walled Garden

A pre-authentication Access Control List (ACL) that defines the specific external domains, IP addresses, or subnets that unauthenticated guest devices are permitted to access before completing the captive portal login. Resources outside the walled garden are blocked until authentication is complete.

An incorrectly configured walled garden is one of the most common causes of captive portal failures, particularly for social login flows that require access to multiple third-party OAuth domains.

MAC Address Randomization

A privacy feature in modern mobile operating systems (iOS 14+, Android 10+) that causes the device to present a randomly generated MAC address to each WiFi network it connects to, rather than its hardware-assigned MAC address. The randomized address may also change periodically while connected.

MAC randomization breaks captive portal session persistence because the gateway uses the MAC address to track authenticated clients. When the MAC changes, the gateway treats the device as a new, unauthenticated client, forcing re-authentication.

RFC 8910 (Captive Portal API)

An IETF standard that defines a mechanism for networks to inform client devices of the presence and URL of a captive portal using DHCP Option 114 (for IPv4) or IPv6 Router Advertisement options. Compatible devices query the advertised API endpoint directly to determine their network status and obtain the portal URL, eliminating the need for DNS hijacking.

RFC 8910 is the modern, standards-compliant alternative to DNS hijacking for captive portal detection. It resolves the HSTS conflict by communicating the portal URL at the network layer rather than attempting to intercept HTTP/HTTPS traffic.

DNS-over-HTTPS (DoH)

A protocol that encrypts DNS queries by sending them over an HTTPS connection to a trusted resolver (such as Cloudflare 1.1.1.1 or Google 8.8.8.8), rather than sending them as plaintext UDP packets to the network-assigned DNS server. This prevents the local gateway from intercepting or hijacking DNS responses.

DoH is increasingly enabled by default in modern browsers (Chrome, Firefox, Edge) and operating systems. When DoH is active, the captive portal's DNS hijacking mechanism is bypassed, and the guest internet login screen will not appear automatically.

NeverSSL

A public utility website (http://neverssl.com) explicitly designed to never use SSL/TLS encryption. It serves as a reliable manual trigger for captive portal redirects because the gateway can always intercept its unencrypted HTTP request and inject a 302 redirect to the portal login page.

NeverSSL is the recommended manual workaround when a guest's device fails to automatically display the captive portal login page. Front-of-house staff should be trained to direct guests to this URL as a first-line resolution step.

OpenRoaming (Passpoint/Hotspot 2.0)

A global WiFi roaming standard developed by the Wireless Broadband Alliance (WBA) that allows devices to automatically and securely authenticate to participating WiFi networks using a pre-installed credential profile, without requiring manual captive portal interaction. Authentication uses WPA3-Enterprise and 802.1X protocols.

OpenRoaming is the long-term evolution beyond captive portals for enterprise guest WiFi. Under Purple's Connect license, Purple acts as a free identity provider for OpenRoaming, enabling returning guests to bypass the captive portal entirely on subsequent visits.

Esempi pratici

A 350-room city-centre hotel has deployed a Purple-powered guest WiFi network across all floors and public areas. The front desk is receiving 15-20 complaints per day from guests whose captive portal login page is not loading. The hotel uses Cisco Catalyst 9800 wireless controllers and a Cisco ISR 4331 router. Initial investigation shows the issue is most common on iPhones running iOS 17 and Android 13 devices. How should the network architect diagnose and resolve this?

Begin with a structured four-layer diagnostic. Layer 1 (DHCP): Log into the Cisco ISR 4331 and run show ip dhcp pool and show ip dhcp binding. Check the total number of active bindings against the pool size. If utilization exceeds 85%, the pool is near exhaustion. Reduce the lease time from the default 1 day to 1800 seconds (30 minutes) using ip dhcp pool GUEST_WIFI and lease 0 0 30. Layer 2 (DNS): On the Catalyst 9800, verify that the pre-authentication ACL (used for the captive portal SSID) permits UDP and TCP port 53 traffic to the assigned DNS servers. Run a packet capture on the guest VLAN interface to confirm DNS queries are being answered. Layer 3 (Walled Garden): Navigate to the Catalyst 9800 GUI under Configuration > Tags & Profiles > Policy. Inspect the URL Filter list associated with the guest SSID. Confirm that *.purple.ai, accounts.google.com, *.facebook.com, appleid.apple.com, and all associated CDN domains are included. Enable DNS snooping on the URL filter to allow wildcard domain resolution. Layer 4 (iOS-Specific): iOS 17 devices use captive.apple.com/hotspot-detect.html as their probe URL. Confirm the Catalyst 9800 is intercepting this HTTP request and returning an HTTP 302 redirect to the Purple portal FQDN (e.g., https://portal.purple.ai). Verify the Purple portal certificate is valid and not self-signed. If the redirect is going to the controller's local IP instead of the cloud portal FQDN, update the external redirect URL in the SSID configuration.

Commento dell'esaminatore: This scenario is representative of the most common enterprise captive portal failure pattern: a combination of DHCP exhaustion in a high-density environment and an incomplete walled garden. The four-layer diagnostic approach is critical because symptoms are often identical across failure modes — the login page simply does not appear. Jumping straight to walled garden fixes without checking DHCP first is a common mistake that wastes significant time. The iOS-specific check is important because Apple's Captive Portal Assistant is stricter than Android's; it will refuse to render a portal page if the redirect target uses a self-signed certificate or if the portal FQDN is not resolvable via the assigned DNS server. An alternative approach for this deployment would be to enable RFC 8910 DHCP Option 114 on the ISR 4331, which would allow iOS 16+ and Android 12+ devices to detect the portal via the DHCP-advertised API URL, bypassing the DNS hijacking mechanism entirely and resolving the HSTS conflict at the root.

A national retail chain with 120 stores has deployed guest WiFi using Aruba Instant APs managed via Aruba Central. The marketing team reports that the 'Login with Google' social login option on the captive portal is failing for approximately 30% of guests. The plain email login option works correctly. The issue appears intermittently and is more common in stores that recently had their Aruba firmware updated. How should the network and IT team investigate this?

The intermittent failure of social login while email login succeeds is a classic walled garden domain coverage issue, likely exacerbated by a firmware update that reset or altered the pre-authentication ACL. Proceed as follows. Step 1 — Reproduce and Capture: At an affected store, connect a test device to the guest SSID and attempt a Google login. Open the browser developer tools (F12 > Network tab) before clicking 'Login with Google'. Note any failed requests — these will show as red entries with status codes such as ERR_CONNECTION_REFUSED or ERR_NAME_NOT_RESOLVED. These failed domains are the missing walled garden entries. Step 2 — Audit Aruba Central Walled Garden: Log into Aruba Central and navigate to the SSID configuration for the guest network. Review the Walled Garden / Whitelist entries. Google's OAuth flow requires at minimum: accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, www.gstatic.com, lh3.googleusercontent.com, and oauth2.googleapis.com. After a firmware update, Aruba Central may have reverted to a template-based configuration that omitted some of these entries. Step 3 — Enable DNS Snooping: In Aruba Central, enable DNS-based whitelisting for the guest SSID. This allows the AP to dynamically resolve and whitelist IP addresses returned for domains matching the configured wildcard patterns (e.g., *.google.com, *.gstatic.com). This is more resilient than static IP whitelisting as Google's CDN IPs change frequently. Step 4 — Validate and Roll Out: Test the fix at the pilot store, confirm Google login success rate reaches 95%+, then push the updated configuration to all 120 stores via Aruba Central's group policy deployment.

Commento dell'esaminatore: This scenario highlights a critical operational risk in large-scale enterprise deployments: firmware updates silently resetting security or access control configurations. The key diagnostic insight is that email login works but social login fails — this immediately narrows the root cause to the walled garden rather than DHCP, DNS, or certificate issues. The use of browser developer tools to identify missing domains is a practical, low-cost technique that front-line IT staff can use without needing packet capture equipment. The recommendation to use DNS snooping with wildcard patterns rather than static IP whitelisting is the correct long-term solution for cloud-based social identity providers, as their IP ranges are not static and are documented only as broad CIDR blocks. For a broader discussion of network access control in retail environments, see the [10 Best Network Access Control (NAC) Solutions for 2026](/blog/best-network-access-control) guide.

Domande di esercitazione

Q1. A conference centre hosting a 2,000-delegate event reports that 40% of attendees cannot get the guest WiFi login page to appear on their devices. The event started 30 minutes ago. The wireless infrastructure uses Ruckus SmartZone controllers. What is the most likely root cause, and what is the fastest resolution?

Suggerimento: Consider the scale of the event (2,000 simultaneous connections) and the time elapsed since the event started. Think about which network resource is most likely to be exhausted in the first 30 minutes of a high-density event.

Visualizza risposta modello

The most likely root cause is DHCP pool exhaustion. With 2,000 delegates attempting to connect simultaneously within 30 minutes, the DHCP address pool for the guest VLAN has almost certainly been depleted, particularly if the lease time was set to the default 8 or 24 hours. Delegates who cannot obtain an IP address will see no login page because the captive portal detection sequence cannot begin without a valid IP assignment. The fastest resolution is to log into the Ruckus SmartZone controller, navigate to the DHCP server configuration for the guest VLAN, and reduce the lease time to 5-10 minutes to force rapid reclamation of addresses from delegates who have already left or disconnected. Additionally, check whether the DHCP pool size is sufficient for the expected concurrent user count — a pool of 254 addresses (/24 subnet) is insufficient for 2,000 delegates. Expand the pool to a /22 or /21 subnet (1,022 or 2,046 addresses) if possible. As a secondary check, verify that the pre-authentication ACL on the SmartZone permits DNS queries (port 53) from unauthenticated clients, as high-volume DNS traffic can sometimes trigger rate-limiting rules.

Q2. A hotel IT manager receives a complaint from a guest staying in room 412. The guest says the WiFi login page appeared briefly, they entered their email address and accepted the terms, but they are now being asked to log in again every 10-15 minutes. Other guests on the same floor are not reporting this issue. The guest is using an iPhone 15 running iOS 17. What is the most likely cause and resolution?

Suggerimento: The issue is specific to a single device and involves repeated re-authentication at short intervals. Consider what iOS 17 does by default with MAC addresses on WiFi networks, and how the hotel's wireless gateway tracks authenticated sessions.

Visualizza risposta modello

The most likely cause is MAC address randomization. iOS 14 and later enable Private Wi-Fi Address by default, which causes the iPhone to present a randomly generated MAC address to each network. In iOS 17, the randomized MAC may rotate periodically (approximately every 24 hours) or upon each new network association. The hotel's wireless gateway tracks authenticated guest sessions by MAC address; when the MAC address changes, the gateway treats the device as a new, unauthenticated client and blocks internet access, triggering the captive portal again. The resolution for the guest is to disable Private Address for the hotel's SSID: go to Settings > Wi-Fi, tap the (i) icon next to the hotel SSID, and toggle off Private Wi-Fi Address. The device will reconnect with its hardware MAC address, and the session will persist without repeated re-authentication. As a longer-term operator-side mitigation, the hotel should consider implementing session persistence based on IP address (in addition to MAC) or transitioning to OpenRoaming/Passpoint for returning guests, which eliminates the captive portal re-authentication issue entirely.

Q3. A retail chain's IT team has configured a new captive portal using Purple. The walled garden has been set up with the portal domain and the main social login provider domains. During testing, the portal page loads correctly and the email login option works, but when a tester clicks 'Login with Google', a Google sign-in popup appears briefly and then closes without completing authentication. The tester is using a Samsung Galaxy S23 running Android 13 with Chrome browser. What should the IT team investigate?

Suggerimento: The Google popup appears but closes without completing — this means the initial OAuth redirect to Google is working, but something is failing during the authentication callback or token exchange. Consider what domains are involved in the full Google OAuth 2.0 flow beyond just accounts.google.com.

Visualizza risposta modello

The symptom — the Google popup appearing but closing without completing — indicates that the initial OAuth redirect to Google is succeeding (accounts.google.com is in the walled garden), but one or more of the subsequent OAuth callback or token exchange domains are being blocked. The Google OAuth 2.0 flow for web applications involves multiple domains beyond accounts.google.com. The IT team should open Chrome DevTools on the test device (or use a desktop browser to simulate the flow), click Login with Google, and observe the Network tab for any failed requests. Common missing domains include: oauth2.googleapis.com (token endpoint), www.googleapis.com (API calls), ssl.gstatic.com and fonts.gstatic.com (Google's CDN for the sign-in page assets), and lh3.googleusercontent.com (profile picture loading, which can cause the popup to hang). Add all identified missing domains to the walled garden in the Aruba/Cisco/Ruckus controller configuration, using wildcard patterns (*.googleapis.com, *.gstatic.com) where the controller supports DNS snooping. Re-test after each addition to isolate the specific blocking domain. Once the full Google OAuth flow completes successfully, validate the fix on both Android and iOS devices before rolling out to production.

Continua a leggere questa serie

Captive Portal vs Splash Page

Questa guida autorevole analizza la distinzione fondamentale tra Captive Portal e splash page nelle reti WiFi per gli ospiti. Chiarisce come il meccanismo di intercettazione di rete sottostante funzioni in sinergia con l'interfaccia visiva per gli ospiti, aiutando i responsabili IT e i gestori delle strutture a prendere decisioni architetturali e di acquisto informate.

Leggi la guida →

Come configurare un hotspot WiFi per la tua attività

Questa guida autorevole fornisce a leader IT, architetti di rete e direttori delle operazioni di sede un modello pratico e indipendente dal fornitore per l'implementazione di hotspot WiFi per ospiti sicuri, conformi e che migliorano il business. Copre decisioni architetturali critiche — dalla segmentazione VLAN e configurazione del Captive Portal alla conformità GDPR e alla modellazione del traffico — e dimostra come trasformare l'infrastruttura di rete da un centro di costo a una piattaforma di analisi che genera entrate utilizzando le capacità di Guest WiFi e analisi di Purple.

Leggi la guida →

Purple vs Cisco Spaces (DNA Spaces): Quando scegliere ciascuno

Questa guida di riferimento tecnico fornisce un confronto completo tra Purple e Cisco Spaces (precedentemente DNA Spaces) per le implementazioni di captive portal aziendali e WiFi per ospiti. Valuta le differenze architetturali, la profondità dell'automazione del marketing e la questione critica del vendor lock-in hardware per aiutare i leader IT a prendere decisioni informate sull'infrastruttura.

Leggi la guida →