Risoluzione dei problemi di reindirizzamento del portale captive: come risolvere i problemi di connessione della rete WiFi per ospiti WiFi

Quando la rete WiFi per ospiti mostra lo stato di connesso ma senza Internet, significa che il dispositivo si è associato alla rete, ma il reindirizzamento al portale captive non ha funzionato. Le cause più comuni sono il blocco della verifica del sistema operativo, l'assenza di voci nel walled garden o problemi al DNS. Altre cause possono essere l'esaurimento del pool DHCP o un messaggio di Access-Accept RADIUS che non raggiunge mai il gateway. Ognuno di questi problemi può essere risolto tramite configurazione.

Come si presenta l'errore "WiFi per ospiti connessa ma senza Internet"?

Il dispositivo si connette al nome della rete (SSID) e mostra un segnale eccellente, ma non carica alcuna pagina. Ogni piattaforma segnala l'errore in modo diverso:

• iOS mostra l'indicazione "Nessuna connessione Internet" sotto il nome della rete.
• Android mostra "Connesso, senza Internet" oppure la richiesta "Accedi alla rete" che non porta a nulla.
• Windows contrassegna la rete come "Senza Internet".

L'utente vede un'icona WiFi attiva ma il browser non risponde, attribuendo quindi il disservizio alla struttura.

Un unico sintomo può nascondere diversi tipi di guasto. In genere si riscontra uno di questi comportamenti:

• La pagina di login non viene mai visualizzata su alcun dispositivo.
• La pagina di login appare sugli iPhone ma non sui dispositivi Android, o viceversa.
• Il browser mostra un avviso di sicurezza o di certificato al posto della pagina di login.
• L'utente compila il modulo, visualizza un messaggio di conferma, ma continua a non avere accesso a Internet.
• Tutto funziona regolarmente nei momenti di basso traffico, ma il servizio si blocca nelle ore di punta.

Ogni comportamento indica un problema a un livello diverso della rete. È opportuno iniziare analizzando il tipo di errore, anziché riavviare gli access point.

Come funziona il rilevamento del portale captive

Un portale captive è la pagina web mostrata da un gateway prima di concedere l'accesso a Internet. Il gateway può essere un controller, un firewall o un access point, a seconda dell'architettura di rete.

Tutti i principali sistemi operativi verificano la presenza di un portale captive non appena si connettono a una rete. Inviano una richiesta HTTP standard a un indirizzo noto e confrontano la risposta con quella attesa. Ogni risultato ha un significato specifico:

• La risposta corrisponde. Il dispositivo presuppone di avere accesso libero a Internet.
• Il gateway restituisce un reindirizzamento HTTP 302. Il dispositivo rileva la presenza di un portale captive. Apre quindi una finestra del browser semplificata, spesso chiamata assistente di rete captive, e carica la pagina di login.
• La richiesta non riceve alcuna risposta. Il dispositivo segnala l'assenza di connessione a Internet e non apre alcuna pagina.

La documentazione Microsoft indica che il Network Connectivity Status Indicator (NCSI) effettua anche la risoluzione DNS di dns.msftncsi.com per la verifica di rete. Di conseguenza, un laptop Windows può segnalare l'assenza di Internet se il DNS prima dell'autenticazione è bloccato, anche se il traffico HTTP funziona correttamente.

Quali sono le cause principali del mancato reindirizzamento al portale captive?

Le cause principali sono riconducibili a sette fattori, distribuiti su diversi livelli, dall'indirizzamento fino all'autenticazione.

Il probe del sistema operativo è bloccato

La lista di controllo degli accessi (ACL) di pre-autenticazione del gateway scarta il probe anziché reindirizzarlo. Il dispositivo non riceve alcuna risposta e deduce che non c'è connessione a Internet, senza quindi aprire mai il portale.

Un servizio di filtraggio DNS che blocca gli hostname dei probe produce lo stesso effetto. Questa è la causa più comune per cui un portale non viene mai mostrato.

HTTPS e HSTS interrompono l'intercettazione

L'HTTP Strict Transport Security (HSTS), definito nell'RFC 6797, impone ai browser di raggiungere un dominio esclusivamente tramite HTTPS. I browser includono un elenco precaricato di domini HSTS, tra cui quelli di Google e della maggior parte degli istituti bancari. Quando un visitatore digita google.com, il browser effettua l'upgrade a HTTPS prima ancora che la richiesta lasci il dispositivo.

Il gateway non può reindirizzare tale richiesta senza presentare un certificato per google.com, di cui non dispone. Il browser mostra quindi un errore di sicurezza bloccante che impedisce il proseguimento.

La soluzione consiste nel reindirizzare solo i probe HTTP in chiaro indicati nella tabella precedente, creati appositamente per questo scopo. Non intercettare mai il traffico HTTPS per il reindirizzamento al portale.

Il walled garden è troppo restrittivo

Il walled garden è l'elenco di domini e indirizzi IP che un dispositivo può raggiungere prima di autenticarsi. Se manca una voce, la pagina di login si carica solo parzialmente oppure la fase di accesso ha esito negativo. Le omissioni più frequenti riguardano:

• Endpoint dei provider di identità per l'accesso tramite social network o single sign-on, come Microsoft Entra ID, Okta o Google Workspace.
• Domini della rete di distribuzione dei contenuti (CDN) che erogano font, script e fogli di stile della pagina di login.
• Domini dei gestori di pagamento, qualora l'accesso sia a pagamento.
• Gli endpoint per il portale captive e per il server RADIUS di Purple, elencati nella guida di integrazione di Purple relativa all'hardware in uso.

Il DNS riscontra un errore prima dell'autenticazione

Il dispositivo deve risolvere l'hostname del portale prima di poter caricare la pagina. Il reindirizzamento non punta a nulla in due casi:

• Il gateway blocca il DNS nello stato di pre-autenticazione.
• Il server DHCP assegna un server DNS non raggiungibile dal dispositivo.

Android introduce un'ulteriore complicazione. Se un visitatore ha impostato un hostname DNS privato specifico, Android richiede il DNS over TLS sulla porta 853. In modalità automatica, utilizza invece il DNS ordinario come soluzione di riserva.

Il pool DHCP è esaurito

Quando il pool di indirizzi si esaurisce, un nuovo dispositivo si associa all'access point ma non riceve alcun indirizzo IP. Windows assegna quindi a se stesso un indirizzo link-local 169.254.x.x, e gli altri sistemi mostrano uno stato analogo di auto-assegnazione.

In mancanza di un indirizzo valido, il dispositivo non può inviare alcun probe. Risulta connesso, ma non ha accesso a Internet. Questo è il tipico problema che si verifica nelle ore di punta in stadi, centri congressi e snodi di trasporto.

Il server RADIUS non invia il messaggio di Access-Accept

Il protocollo RADIUS (Remote Authentication Dial-In User Service) trasmette la decisione di autenticazione dal server dedicato al gateway. Il server risponde con Access-Accept o Access-Reject, come definito nell'RFC 2865. Il gateway abilita quindi l'accesso oppure lo mantiene bloccato.

Un visitatore che completa il modulo ma rimane offline indica quasi sempre che il gateway non ha ricevuto il messaggio di Access-Accept. Le tre cause più comuni sono:

• Un segreto condiviso non corrispondente.
• Un firewall che blocca la porta UDP 1812 (autenticazione) o UDP 1813 (accounting). Le specifiche RFC 2865 e RFC 2866 definiscono queste porte.
• L'indirizzo del server errato sul controller.

Il certificato del portale è scaduto

La pagina di login viene erogata tramite HTTPS. Se il relativo certificato TLS scade, qualsiasi browser moderno blocca la pagina mostrando un avviso di sicurezza. Il reindirizzamento funziona perfettamente, ma il visitatore non riesce comunque ad accedere.

Come individuare la causa del problema?

Procedere risalendo lo stack nell'ordine indicato. Ogni verifica consente di escludere un livello, pertanto è necessario fermarsi al primo errore riscontrato.

1. Il dispositivo dispone di un indirizzo IP valido? Eseguire ipconfig /all su Windows oppure verificare i dettagli della rete su uno smartphone. Un indirizzo 169.254.x.x o l'assenza totale di un indirizzo indicano un problema con il DHCP. Verificare l'utilizzo del pool sul server DHCP: un valore superiore al 90% indica che il pool è prossimo all'esaurimento.
2. La risoluzione DNS funziona correttamente? Da un dispositivo attestato sulla LAN virtuale guest (VLAN), un segmento di rete logicamente separato, verificare l'hostname del portale. Se la risoluzione fallisce, il DNS prima dell'autenticazione è bloccato oppure il server DNS assegnato dal DHCP è errato.
3. La sonda riceve un errore 302? Eseguire una cattura dei pacchetti sulla VLAN guest o navigare verso uno degli URL di test HTTP. Dovrebbe essere visualizzata la richiesta di test, seguita da un codice HTTP 302 che reindirizza al portale. Se la richiesta di test non riceve alcuna risposta, la ACL la sta scartando. L'assenza totale della richiesta indica che il dispositivo considera la connessione già attiva, spesso a causa di uno stato memorizzato in cache. Dissociare la rete e riconnettersi.
4. La pagina di login si carica completamente? Aprire gli strumenti per sviluppatori del browser (F12) e monitorare la scheda Rete. Le richieste bloccate verso domini terzi indicano lacune nel walled garden.
5. Il gateway riceve il messaggio di Access-Accept? Verificare i log RADIUS del controller. Un accesso riuscito è seguito da un Accounting-Request con stato Start. Se dopo il login non viene registrato alcun record di accounting, il percorso RADIUS è interrotto.

Confrontare quindi quanto rilevato con la seguente tabella.

Scenario reale: un centro congressi da 1.500 posti negli orari di punta

Situazione. Un centro congressi gestiva la rete per i partecipanti su una singola sottorete /24 con un lease DHCP di otto ore. I discorsi di apertura del mattino si sono svolti senza problemi. Dopo pranzo, i partecipanti arrivati per le sessioni pomeridiane hanno visualizzato il messaggio "connesso, senza internet". L'help desk lo ha trattato come un guasto del portale e ha riavviato il controller due volte.

Azione intrapresa. La fase 1 della diagnosi ha rilevato che i nuovi dispositivi mantenevano indirizzi 169.254.x.x. Una /24 offre 254 indirizzi utilizzabili e il lease di otto ore manteneva riservato ogni indirizzo del mattino. Il team ha spostato la VLAN dei partecipanti su una /21 e ha ridotto il lease a 30 minuti.

Risultato. Gli indirizzi utilizzabili sono saliti da 254 a 2.046, circa otto volte la capacità precedente. Un indirizzo lasciato libero da un partecipante che se ne va torna ora nel pool entro 30 minuti, anziché otto ore. La risoluzione ha richiesto una sola finestra di modifica e nessun nuovo hardware.

Scenario reale: un hotel da 200 camere in cui gli ospiti Android non riuscivano ad accedere

Situazione. Dopo la riprogettazione della pagina di login, un hotel da 200 camere ha ricevuto reclami alla reception da parte degli ospiti Android. La maggior parte di loro sceglieva l'opzione di accesso con Google. Il portale appariva, ma il pulsante non eseguiva alcuna azione.

Azione intrapresa. Il responsabile IT ha testato il flusso su un iPhone, uno smartphone Android e un laptop Windows. Gli strumenti per sviluppatori sul laptop hanno mostrato richieste bloccate verso una rete di distribuzione dei font e verso i domini di accesso di Google. La riprogettazione li aveva aggiunti entrambi. Il team li ha aggiunti al walled garden.

Risultato. L'accesso tramite Google è stato completato su tutti e tre i dispositivi di test al primo riesame. La risoluzione ha richiesto due voci nel walled garden e nessuna modifica all'hardware.

Scenario reale: una rete di 40 punti vendita dopo l'aggiornamento del firewall

Situazione. Un rivenditore ha sostituito i firewall in 40 negozi durante un fine settimana. Lunedì, gli acquirenti in ogni negozio aggiornato potevano completare il modulo di login ma rimanevano offline. I negozi non ancora aggiornati funzionavano normalmente.

Azione intrapresa. La fase 5 non ha rilevato record di accounting dai negozi aggiornati. Il nuovo modello di firewall negava il traffico UDP in uscita per impostazione predefinita, bloccando le porte 1812 e 1813. Il team ha aggiunto regole esplicite in uscita al modello e lo ha distribuito a tutti i 40 negozi.

Risultato. I record di accounting sono ricomparsi da ogni negozio dopo la distribuzione. Poiché solo i negozi aggiornati presentavano l'errore, la dinamica indicava direttamente il modello e non il WiFi.

Come risolvere il problema su ciascun sistema operativo e controller?

La risoluzione sul controller segue lo stesso schema su ogni piattaforma. Le correzioni sui sistemi operativi riguardano principalmente la conoscenza del comportamento di ciascuno di essi.

Sul controller

Purple viene eseguito come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Lo schema di risoluzione è lo stesso su tutti e otto:

1. Indirizzare il WiFi per ospiti SSID al portale captive esterno indicato nella guida all'integrazione di Purple e disabilitare qualsiasi splash page locale.
2. Reindirizzare il traffico HTTP non autenticato, comprese le verifiche di connessione (probe), a tale URL. Non modificare il traffico HTTPS.
3. Consentire DNS e DHCP prima dell'autenticazione.
4. Aggiungere le voci del walled garden: endpoint di Purple, endpoint del provider di identità e domini delle risorse della pagina di accesso.
5. Inserire gli indirizzi server RADIUS e il segreto condiviso dalla dashboard di Purple. Quindi confermare che il firewall consenta il traffico UDP 1812 e 1813 in uscita.

I nomi dei menu variano in base al produttore e alla versione del firmware, pertanto si consiglia di seguire la guida all'integrazione di Purple relativa alla propria piattaforma. La documentazione della community di Fortinet sul flusso del portale captive di FortiGate è un utile riferimento lato produttore per la sequenza di reindirizzamento.

Su iOS e macOS

Se l'assistente per le reti con portale captive non si apre, dissociarsi dalla rete nelle Impostazioni e riconnettersi. Ciò forzerà una nuova verifica di connessione.

Le versioni recenti di iOS e macOS supportano anche la funzione Captive Portal API. Essa consente alla rete di pubblicizzare il proprio portale tramite l'opzione DHCP 114, definita in RFC 8910, riducendo la dipendenza dall'intercettazione. Se l'assistente si apre ma rimane vuoto, verificare i domini delle risorse nel walled garden.

Su Android

Android mostra la notifica "Accedi alla rete" quando rileva un portale. Se la notifica non appare, confermare che il gateway reindirizzi connectivitycheck.gstatic.com anziché scartarlo.

Se un visitatore visualizza il messaggio "Impossibile accedere al server DNS privato", nel suo telefono è impostato un nome host DNS privato restrittivo. Sono disponibili due opzioni:

• Consentire DNS over TLS sulla porta 853 prima dell'autenticazione.
• Chiedere al visitatore di impostare il DNS privato su automatico.

Su Windows

Windows si basa sulla verifica HTTP di NCSI e sul relativo controllo DNS. Se il portale non si apre automaticamente, navigare su un qualsiasi sito HTTP non protetto per attivare manualmente il reindirizzamento. La presenza persistente del messaggio "Nessun accesso a Internet" dopo l'accesso indica solitamente che il gateway sta ancora reindirizzando la verifica. In tal caso, il gateway non ha applicato il messaggio Access-Accept.

Nel browser

Istruire il personale di prima linea a indirizzare i visitatori verso un indirizzo HTTP, mai verso un dominio HSTS come google.com. Firefox esegue una propria verifica su detectportal.firefox.com, pertanto è necessario includere tale host nei test di reindirizzamento.

Come evitare che i problemi di reindirizzamento del WiFi per ospiti WiFi si ripetano?

La maggior parte degli incidenti ricorrenti deriva da modifiche successive e non dall'installazione originale. Un aggiornamento del firmware, un nuovo modello di firewall, il restyling della pagina di accesso o un certificato in scadenza possono sfuggire ai test. È opportuno integrare questi controlli nel proprio processo di gestione delle modifiche:

• Eseguire test su tre piattaforme dopo ogni modifica. Utilizzare un iPhone, uno smartphone Android e un laptop Windows. Se una piattaforma non funziona mentre le altre superano il test, verificare prima di tutto eventuali mancanze nel walled garden.
• Dimensionare per i picchi, non per la media. Calcolare il numero massimo di dispositivi contemporanei e aggiungere un margine di sicurezza. Le reti per visitatori occasionali utilizzano comunemente lease compresi tra 15 e 30 minuti.
• Impostare le sessioni in base alla visita. Le strutture ricettive e i punti vendita al dettaglio impostano comunemente sessioni di 24 ore, in modo che l'ospite effettui l'accesso una sola volta per soggiorno o visita.
• Monitorare quotidianamente i volumi di accesso. I report di WiFi Analytics di Purple mostrano gli accessi per struttura. Un calo improvviso in una sede avvisa di un guasto al server RADIUS o al walled garden, spesso prima che i visitatori si lamentino.
• Sottoporre i certificati e i secret condivisi al controllo delle modifiche. Annotare nel calendario la data di scadenza del certificato del portale. Archiviare il secret condiviso RADIUS in un luogo in cui i team responsabili del firewall e del controller possano entrambi verificarlo.
• Segmentare il traffico degli ospiti. Inserire gli ospiti su una VLAN dedicata. Lo standard PCI DSS considera la segmentazione il modo migliore per mantenere la rete ospiti fuori dall'ambito dell'ambiente dei dati dei titolari di carta.
• Pianificare la randomizzazione degli indirizzi MAC. Le ultime versioni di iOS e Android utilizzano un indirizzo MAC casuale per ciascuna rete e alcune modalità lo ruotano nel tempo. Il caching della sessione basato sull'indirizzo MAC chiederà quindi ai visitatori che ritornano di effettuare nuovamente l'accesso.
• Raccogliere il consenso in modo corretto. Il regolamento GDPR richiede un consenso informato e affermativo per i dati di marketing. Le opzioni di opt-in a scelta consapevole di Purple presentano una scelta separata per ciascuna finalità.

Rimuovere i visitatori che ritornano dal portale captive

La soluzione più duratura rimuove completamente il reindirizzamento per le visite ripetute.

• Passpoint è la certificazione di settore basata sulle specifiche Hotspot 2.0. Consente a un dispositivo di accedere a una rete automaticamente utilizzando un profilo memorizzato.
• OpenRoaming, gestito dalla Wireless Broadband Alliance, federa i provider di identità. Le credenziali esistenti di un visitatore funzionano quindi in tutte le strutture partecipanti.

Entrambi utilizzano lo standard IEEE 802.1X, il canale standard per il controllo dell'accesso alla rete basato su porte, evitando così problemi di malfunzionamento del portale.

Il ruolo di Purple

Purple Guest WiFi funziona come un overlay cloud indipendente dall'hardware, consentendo di risolvere i problemi di reindirizzamento tramite configurazione, senza acquistare nuovo hardware. Purple serve oltre 80.000 strutture attive in più di 90 paesi e supporta 500 milioni di utenti e accessi all'anno. La piattaforma garantisce un uptime del 99,999% ed è certificata ISO 27001, Cyber Essentials e B Corp. È inoltre conforme alle normative GDPR e CCPA.

Quando un portale non funziona, la causa è quasi sempre locale: una regola di probe, una voce walled garden, un pool DHCP o una regola del firewall.

I pattern si ripetono nei vari settori:

• Gli hotel riscontrano errori di reindirizzamento durante i picchi di check-in.
• Le attività del settore Retail li riscontrano a seguito di modifiche al firewall a livello dell'intera infrastruttura.
• Treni e stazioni devono gestire la pressione sul DHCP quando i passeggeri salgono a bordo a ondate.
• Le strutture Sanitarie necessitano di un WiFi per pazienti e visitatori che funzioni senza richiedere l'intervento del personale clinico per chiamate di supporto.

Domande frequenti

Purple è compatibile con gli access point che già possediamo?

Sì. Purple è indipendente dall'hardware e funziona come un overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. È possibile mantenere gli access point e i controller esistenti. Sarà sufficiente puntare la rete SSID per ospiti al portale captive di Purple, aggiungere le voci walled garden e i dettagli RADIUS presenti nella guida all'integrazione di Purple, e quindi eseguire un test. Non occorre sostituire l'infrastruttura.

È necessario un nuovo hardware per risolvere il problema del WiFi per ospiti connesso ma senza internet?

No. Nella quasi totalità dei casi il problema è legato alla configurazione: un probe bloccato, una lacuna nel walled garden, il DNS di pre-autenticazione, un pool DHCP esaurito o una regola del firewall RADIUS. È possibile risolvere ciascun problema sul controller, sul firewall o sul server DHCP già in uso. L'hardware diventa un problema solo quando la densità degli access point non è in grado di gestire il numero massimo di dispositivi, come evidenziato da una site survey.

Che cosa comporta il passaggio della nostra rete WiFi per ospiti a Purple?

Il passaggio a Purple è un progetto di configurazione, non un progetto di installazione. Su ciascun controller occorre impostare la rete SSID per ospiti sul portale esterno di Purple e aggiungere le impostazioni di walled garden e RADIUS. Successivamente, occorre confermare le regole del firewall per UDP 1812 e 1813. Quindi, si crea la pagina di login e le opzioni di consenso in Purple e si testa su iOS, Android e Windows. Per le strutture multisito è possibile definire modelli di configurazione dei controller.

Un portale captive è conforme al GDPR?

Sì, a condizione che il consenso sia informato, specifico e liberamente espresso. Il GDPR richiede una scelta affermativa distinta per ogni finalità, come l'invio di e-mail di marketing, ed esclude le caselle preselezionate. Le opzioni di opt-in a scelta consapevole di Purple presentano ciascuna scelta separatamente. Purple possiede la certificazione ISO 27001, la certificazione Cyber Essentials ed è conforme al GDPR e a CCPA. Ciò garantisce al Data Protection Officer il rispetto degli standard richiesti.

I visitatori che ritornano possono ignorare la pagina di login?

Sì. Passpoint e OpenRoaming consentono a un dispositivo di connettersi automaticamente utilizzando un profilo memorizzato o un'identità federata. Entrambi utilizzano l'autenticazione IEEE 802.1X con crittografia WPA2 o WPA3-Enterprise, evitando così eventuali errori di reindirizzamento al portale captive nelle visite successive. Molte strutture utilizzano entrambe le soluzioni: un portale captive per i visitatori al primo accesso e la acquisizione dati, e OpenRoaming per ospiti che ritornano, passeggeri e studenti.

Come si fa a sapere quando i login iniziano a fallire?

Monitorare i volumi di accesso per sede. I report di analisi WiFi di Purple indicano i login per ciascun sito, consentendo di evidenziare un calo improvviso in una sede rispetto all'andamento normale e alle altre strutture. Tale calo segnala di solito un errore di RADIUS, walled garden o DHCP introdotto da una modifica recente. Individuarlo nella dashboard è più rapido rispetto all'attesa che le segnalazioni della reception raggiungano il reparto IT.

È preferibile utilizzare un portale captive o una password WiFi condivisa?

È consigliabile utilizzare un portale captive se si desidera raccogliere dati di prima parte e il relativo consenso, mentre è opportuno scegliere una password condivisa solo se nessuno di questi elementi è necessario. Una chiave precondivisa cifra il traffico con WPA2 o WPA3-Personal. Tuttavia, non fornisce alcuna informazione sulle persone che si sono connesse e la password tende a diffondersi. Un portale captive raccoglie i dati di prima parte con il consenso dell'utente, mentre Passpoint o OpenRoaming aggiungono un accesso cifrato e automatico per le visite successive.