Configurare e testare Captive Portal su Sophos Firewall

Il Captive Portal autentica gli utenti già connessi a una rete LAN o Wi-Fi. Sophos Firewall può quindi associare il loro traffico a un’identità e applicare regole a utenti o gruppi specifici.

L’interazione tra i componenti è importante: il portale crea l’associazione dell’utente, ma non consente di per sé l’accesso a Internet. Serve anche una regola firewall adeguata. DNS, routing, NAT e segmentazione della rete devono funzionare in modo indipendente.

L’intera procedura si riduce a sei passaggi:

1. Verificare la fonte di autenticazione e il gruppo autorizzato.
2. Consentire Captive Portal per la zona client in Administration > Device access.
3. Se si utilizza un server DNS esterno, creare una regola DNS limitata senza riferimento all’utente.
4. Creare una regola utente con Match known users e Use web authentication for unknown users.
5. Definire HTTPS, pagina di destinazione e logout in Authentication > Web authentication.
6. Verificare il login sulla porta 8090, l’utente in Live users e la Rule ID in Log Viewer.

Cosa fa Captive Portal e cosa non fa

Captive Portal è adatto a dispositivi BYOD, client non gestiti o reti in cui non è disponibile il rilevamento trasparente degli utenti. L’utente apre una pagina web, viene reindirizzato al login e quindi viene associato sul firewall al proprio IP di origine. Il firewall può usare questa identità come criterio di corrispondenza.

Altri portali e metodi di autenticazione risolvono esigenze diverse:

• Un Wireless Hotspot è pensato per l’accesso guest con voucher, password giornaliera o condizioni di utilizzo. La procedura completa è descritta in Configurare Sophos Firewall Hotspot.
• Un Guest user è un account locale temporaneo per Captive Portal. Creare e gestire in sicurezza gli utenti guest spiega gruppo, validità, consegna delle credenziali, registrazione autonoma e pulizia.
• Il VPN Portal fa parte di Remote Access. Captive Portal non crea un tunnel VPN e non deve essere usato come portale di login pubblico.
• STAS, AD SSO o SATC identificano gli utenti senza login nel browser, quando possibile. Captive Portal può fungere da alternativa per i dispositivi che il rilevamento trasparente non riconosce.
• Per il login Microsoft si applica la procedura separata Captive Portal con Microsoft Entra ID SSO.

La panoramica dei portali Sophos aiuta a distinguere User Portal, VPN Portal, WebAdmin e Captive Portal.

⚠️ Captive Portal non sostituisce la segmentazione. Una rete BYOD o guest rimane in una zona o VLAN dedicata e accede solo alle destinazioni e ai servizi necessari. Il login migliora l’associazione degli utenti, ma non rende automaticamente sicura una rete troppo permissiva.

Requisiti ed esempio

Prima della configurazione devono essere chiari i seguenti punti:

• Funziona una fonte di autenticazione locale o esterna. Con Active Directory, la connessione al server e il gruppo sono già stati verificati; Collegare Active Directory a Sophos Firewall spiega la configurazione.
• Sono noti la zona client, la rete di origine e il gruppo utenti autorizzato.
• Il client riceve un indirizzo IP, un gateway e server DNS corretti.
• Per il nome del portale di produzione esistono un record DNS e un certificato accettato dai client.
• Una regola MASQ/SNAT esistente e il routing coprono il traffico Internet che verrà successivamente consentito.
• Per il collaudo sono disponibili un utente autorizzato e uno non autorizzato.

L’esempio utilizza:

• Zona client: LAN
• Rete client: 10.30.40.0/24
• Oggetto di rete: BYOD_10.30.40.0_24
• IP del firewall nella zona client: 10.30.40.1
• Gruppo utenti: BYOD_Internet
• Nome della regola: LAN-BYOD-to-WAN-Captive
• Server DNS interno: 10.20.0.53
• Nome del portale: login.example.com

Questi valori non vanno copiati senza verificarli. Zona e rete devono corrispondere all’interfaccia client reale, 10.30.40.1 va sostituito con il relativo IP del firewall e il gruppo deve provenire dalla fonte di autenticazione utilizzata. Dalla rete client, il nome del portale deve risolvere esattamente a questo indirizzo raggiungibile del firewall.

Configurare Captive Portal passo per passo

1. Selezionare il metodo di autenticazione

In Authentication > Services, Firewall authentication methods definisce le fonti interrogate dal firewall durante il login. Può essere il database locale o un server AD, LDAP o RADIUS già configurato. Creare e testare utenti locali normali descrive gruppo, password, Local, Sign-in Restriction e ciclo di vita di questo modello. L’ordine è importante: se sono presenti più server, SFOS li verifica dall’alto verso il basso.

Per l’esempio, il gruppo BYOD_Internet deve esistere sul firewall. Con Active Directory va prima importato. Solo allora può essere selezionato nella regola utente e associato in modo univoco durante il test.

Una connessione al server riuscita non è sufficiente. Un login reale al portale verificherà in seguito che password, gruppo e regola utente funzionino insieme.

2. Consentire Captive Portal per la zona di origine

In Administration > Device access, nella riga Captive portal, attivare solo le zone da cui gli utenti devono effettivamente autenticarsi. Nell’esempio è LAN. Salvare con Apply.

Device Access controlla l’accesso a un servizio locale del firewall. Una normale regola LAN-to-WAN non sostituisce questa autorizzazione. Captive Portal non dovrebbe neppure essere attivato preventivamente per WAN o per zone interne non interessate. Device Access e Local Service ACL spiega anche l’eccezione del Web Proxy, che può rendere raggiungibili i portali locali nonostante una tabella delle zone più restrittiva.

Se i client usano il firewall come resolver DNS, nella stessa matrice deve essere consentito anche DNS per la loro zona. Con un server DNS separato serve invece la seguente regola di transito.

3. Consentire DNS prima del login

Il browser può aprire login.example.com o il sito richiesto solo se DNS funziona prima dell’autenticazione. Se il server DNS non si trova sul firewall, creare una regola in Rules and policies > Firewall rules > Add firewall rule > New firewall rule:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: zona del server DNS
• Destination networks: oggetto host per 10.20.0.53
• Services: DNS
• Log firewall traffic: attivare per il collaudo

Questa regola non ha condizioni utente, perché il client non è ancora autenticato. Consente solo DNS verso il resolver previsto, non traffico arbitrario prima del login. Se l’ambiente usa più server DNS, aggiungere esplicitamente i relativi oggetti host.

Posizionare la regola DNS in modo che il resolver sia raggiungibile prima del login. Nell’esempio si trova subito prima della regola utente e sopra qualsiasi regola più generica che bloccherebbe o elaborerebbe diversamente il DNS di questa rete. Salvare con Save.

Sopra la tabella delle regole, selezionare il protocollo pertinente, IPv4 o IPv6. Se i client raggiungono il resolver solo tramite IPv4, è sufficiente la regola DNS IPv4. Se usano DNS anche tramite IPv6, creare una regola IPv6 altrettanto limitata con gli oggetti rete e host IPv6 appropriati.

4. Creare la regola utente

Creare ora la vera regola di accesso:

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: le destinazioni Internet necessarie o Any
• Services: solo i servizi necessari
• Match known users: attivato
• Use web authentication for unknown users: attivato
• Users or groups: BYOD_Internet
• Log firewall traffic: attivato

Anche qui, selezionare IPv4 o IPv6 sopra la tabella delle regole. In una rete dual-stack, creare una regola utente separata con gli oggetti rete appropriati per ogni famiglia di protocolli effettivamente consentita; una regola IPv4 non copre IPv6.

Match known users rende l’identità un criterio di corrispondenza. Use web authentication for unknown users invia al login una richiesta web corrispondente di un utente non ancora autenticato. Il gruppo stabilisce chi può usare la regola dopo il login.

Per Services, Any è appropriato solo se il gruppo deve realmente avere pieno accesso client a Internet. Per un accesso più ristretto, selezionare consapevolmente HTTP, HTTPS e gli altri protocolli necessari. Il traffico non web non può mostrare una pagina di login; l’utente deve prima autenticarsi con un browser o tramite l’URL diretta del portale.

La regola deve trovarsi sopra una regola Allow generica basata su IP. Altrimenti la regola precedente elabora il traffico e la regola utente non viene mai raggiunta. Dopo averne verificato la posizione, salvare con Save. Pianificare correttamente le regole firewall spiega la valutazione di base.

5. Definire HTTPS, reindirizzamento e logout

Authentication > Web authentication non attiva la raggiungibilità del portale, ma ne configura il comportamento.

Captive Portal accetta al massimo 50 caratteri sia per il nome utente sia per la password. Questo limite va testato con un account reale prima del rollout, soprattutto con directory esterne e nomi utente generati automaticamente.

Per una configurazione di produzione sono importanti queste decisioni:

• Show user portal link mostra nella pagina Captive Portal un collegamento allo User Portal. Attivarlo solo se gli utenti hanno realmente bisogno del portale e questo deve essere raggiungibile dalla loro zona.
• Lasciare disattivato Use insecure HTTP instead of HTTPS. HTTP trasmette le credenziali senza cifratura e non funziona con Entra ID SSO.
• Show web page after sign-in può reindirizzare l’utente alla pagina originariamente richiesta o a una pagina interna definita.
• Open web page: In new browser window lascia aperta la pagina Captive Portal per logout e keepalive. Se viene sostituita la stessa scheda, il logout risulta meno visibile.
• When captive portal page is closed or redirected disconnette l’utente quando il firewall non riceve più keepalive. Questo può avvenire anche dopo Sleep o un cambio di rete.
• When user is inactive valuta un intervallo di tempo e la quantità di dati trasferiti al suo interno. SFOS disconnette un utente il cui traffico resta sotto la soglia configurata. Scegliere intervallo e quantità in modo che il normale traffico in background non mantenga attive all’infinito le sessioni obsolete.
• Never richiede un logout manuale e può mantenere più a lungo associazioni obsolete tra utente e IP.

Non esiste un timeout universale. Sessioni più brevi sono importanti sui dispositivi condivisi e quando cambiano gli utenti; sui dispositivi personali l’autenticazione può essere meno invasiva. Testare ogni scelta con Sleep, cambio di Wi-Fi e logout manuale. Queste opzioni locali non si applicano a Entra ID SSO.

Inoltre, Authentication > Services > Global settings > Maximum session timeout limita la durata totale degli utenti autenticati. SFOS verifica l’autorizzazione ogni tre minuti; anche Access Policies, Surfing Quota e il limite di trasferimento dati possono terminare una sessione. Questo valore globale non riguarda solo Captive Portal: verificare gli altri metodi di autenticazione prima di modificarlo.

Salvare con Apply.

La Device Console contiene anche valori globali per le versioni TLS minime di Captive Portal, X-Frame-Options e una stringa di cifratura condivisa con Web Proxy. Verificare in sicurezza le impostazioni HTTP Proxy spiega perché questi valori non sono una lista generale di tuning e come testare e annullare una modifica con prove del portale e del proxy.

In Captive portal appearance è possibile personalizzare logo, testi e colori. Se si utilizza Custom HTML al posto del layout predefinito, devono rimanere funzionanti il segnaposto <div id="__loginbox"></div> e il blocco request-url specificato da Sophos con il relativo script di reindirizzamento. HTML, CSS o JavaScript personalizzati vanno quindi testati prima con Preview e poi con un account pilota. Un portale graficamente corretto non è un successo se il template interrompe login, reindirizzamento o logout; Reset to default consente di annullare la personalizzazione.

<div id="__loginbox"></div>
<div id="request-url" style="display:none;">{url}</div>
<script>
var redirect_url = document.getElementById("request-url").innerHTML;
</script>

La parte script deve trovarsi immediatamente prima di </body>.

6. Verificare il nome e il certificato del portale

L’URL diretta di diagnosi è:

https://<Firewall-IP>:8090

Nell’esempio, aprire prima https://10.30.40.1:8090. In produzione, https://login.example.com:8090 è più comprensibile se il nome risolve al firewall ed è incluso nel certificato.

L’apertura dell’URL con l’IP dimostra che il portale è raggiungibile. Tuttavia, se il certificato selezionato copre solo login.example.com, il browser mostrerà normalmente un avviso di mancata corrispondenza del nome per https://10.30.40.1:8090. Non inserire credenziali dopo aver ignorato questo avviso. Utilizzare l’URL FQDN per convalidare il nome del certificato e la catena di attendibilità.

Aprire Administration > Admin and user settings. Prima della modifica, annotare il valore attuale di Redirect users e il Certificate selezionato. In Admin console and end-user interaction, sotto Redirect users, selezionare quindi Firewall’s configured hostname o A different hostname; per l’esempio inserire login.example.com. In Certificate, scegliere il certificato che copre il nome. Usare Check settings per provare il reindirizzamento prima del rollout. Questa selezione interessa anche altri portali locali. Dopo la modifica, verificare WebAdmin, User Portal e VPN Portal.

Se uno di questi test fallisce, riselezionare il valore di reindirizzamento annotato e il certificato precedente, quindi salvare con Apply. Provare quindi di nuovo il reindirizzamento e i portali.

Un certificato pubblicamente attendibile evita avvisi sui dispositivi non gestiti. Con una CA interna o firmata dal firewall, la CA deve essere installata come attendibile su tutti i client. Gestire i certificati su Sophos Firewall spiega nome, catena completa e assegnazione sicura.

Testare completamente login e regola utente

Il collaudo inizia con un client senza sessione esistente. Se necessario, in Current activities > Live users è possibile disconnettere una vecchia sessione di test.

1. Verificare che il client abbia un indirizzo di 10.30.40.0/24, il gateway previsto e il server DNS corretto.
2. Aprire direttamente https://10.30.40.1:8090 o l’URL FQDN preparata. L’URL con l’IP verifica la raggiungibilità del portale indipendentemente dal reindirizzamento automatico, ma può generare un avviso di mancata corrispondenza se il certificato copre solo login.example.com. Utilizzare l’URL FQDN per convalidare il certificato.
3. Senza una sessione esistente, aprire una normale pagina HTTP e verificare il reindirizzamento a Captive Portal. Una pagina HTTPS con comportamento HSTS memorizzato non è un test affidabile.
4. Accedere con un utente autorizzato. Se Sophos MFA locale è attivo, il token OTP deve essere prima registrato nello User Portal. Attivare MFA per Sophos Firewall spiega la configurazione.
5. In Current activities > Live users, verificare nome utente, IP client e tipo di autenticazione.
6. Testare un sito consentito e, deliberatamente, una destinazione o un servizio non consentito.
7. In Log Viewer, filtrare per l’IP client. La voce deve mostrare l’utente atteso e la Rule ID di LAN-BYOD-to-WAN-Captive.
8. Con un utente esterno a BYOD_Internet, verificare che il login non conceda accesso tramite questa regola.
9. Attivare logout, Sleep o un cambio di rete e verificare quando l’utente scompare da Live users.

In una rete dual-stack, eseguire il test separatamente per IPv4 e IPv6. SFOS gestisce le due associazioni utente separatamente ed entrambe le varianti richiedono regole firewall appropriate; un test IPv4 riuscito non dimostra quindi il funzionamento di IPv6.

Circoscrivere gli errori comuni

Il portale non appare

Aprire prima l’URL diretta sulla porta 8090. Se non è raggiungibile, verificare la zona di origine e Captive portal in Device Access, l’IP client, l’associazione delle zone, DNS e il FQDN del portale.

Se l’URL diretta funziona ma il login automatico no, spesso una regola più generale elabora prima il traffico oppure manca Use web authentication for unknown users. Inoltre, solo una richiesta web corrispondente può attivare il login; le applicazioni non web non mostrano Captive Portal.

Il login viene rifiutato

In Authentication > Services, verificare la fonte e l’ordine di autenticazione. Quindi controllare la connessione al server, la password, il gruppo, la quota e, con MFA locale, la registrazione OTP completata. Gli orari ricorrenti consentiti o bloccati vengono controllati separatamente con Access Time per utenti e gruppi. La procedura per Surfing Quota e Network Traffic Quota mostra se invece è stato esaurito il tempo Internet o il volume di dati consumato.

Se l’errore non è chiaramente riconducibile al portale, Risolvere sistematicamente gli errori di autenticazione su Sophos Firewall separa raggiungibilità, selezione del servizio, Live Users, Main Group e successivo percorso del traffico.

Per i login classici è rilevante access_server.log. oauth_sso_captive.log serve solo per Microsoft Entra ID SSO. Service Log di Sophos Firewall spiega come leggere i file senza riavviare prematuramente i servizi.

Login riuscito, ma nessun accesso

Un login riuscito conferma solo l’autenticazione. Anche zona client, rete di origine, gruppo, destinazioni, servizi, posizione della regola, NAT e routing devono corrispondere. Log Viewer mostra quale Rule ID elabora realmente il traffico. Perché una regola Sophos Firewall non corrisponde offre una verifica sistematica.

L’utente viene disconnesso inaspettatamente

Verificare l’opzione di sign-out e le relative soglie di tempo e dati, la finestra del portale aperta, Sleep, cambi di rete e inattività. Controllare inoltre Maximum session timeout in Authentication > Services > Global settings, insieme ad Access Time, Surfing Quota e Network Traffic Quota. Con When captive portal page is closed or redirected, l’associazione termina quando cessano i keepalive; ciò potrebbe non essere visibile al momento della chiusura della finestra.

Il login appare solo dopo circa due minuti

Se nella stessa rete si usa STAS, la fase di apprendimento può ritardare il reindirizzamento. Verificare prima lo stato STAS e i client non autenticati. La procedura generale non modifica per questo un valore CLI globale; l’articolo STAS spiega la relazione.

Più utenti condividono lo stesso IP di origine

Captive Portal associa generalmente l’identità utente a un IP client. Gli indirizzi inseriti in Multi-user hosts per Per-Connection AD SSO tramite Direct Web Proxy non possono quindi usare Captive Portal. Per-Connection AD SSO per host multiutente spiega la procedura appropriata e la regola separata senza Match known users per il traffico restante.

Domande frequenti