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:

Verificare la fonte di autenticazione e il gruppo autorizzato.
Consentire Captive Portal per la zona client in Administration > Device access.
Se si utilizza un server DNS esterno, creare una regola DNS limitata senza riferimento all’utente.
Creare una regola utente con Match known users e Use web authentication for unknown users.
Definire HTTPS, pagina di destinazione e logout in Authentication > Web authentication.
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.

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.

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

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.

Per una configurazione di produzione sono importanti queste decisioni:

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 è più adatto se la sessione deve terminare dopo un periodo definito di inattività.
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.

Salvare con Apply.

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. Utilizzare l’URL FQDN per convalidare il nome del certificato e la catena di attendibilità.

Le impostazioni si trovano in Administration > Admin and user settings > Admin console and end-user interaction. In Redirect users, selezionare Firewall’s configured hostname o A different hostname; per l’esempio inserire login.example.com. In Certificate, scegliere il certificato che copre il nome. Questa selezione interessa anche altri portali locali. Prima di modificarla, verificare WebAdmin, User Portal e VPN Portal.

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.

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

Verificare che il client abbia un indirizzo di 10.30.40.0/24, il gateway previsto e il server DNS corretto.
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.
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.
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.
In Current activities > Live users, verificare nome utente, IP client e tipo di autenticazione.
Testare un sito consentito e, deliberatamente, una destinazione o un servizio non consentito.
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.
Con un utente esterno a BYOD_Internet, verificare che il login non conceda accesso tramite questa regola.
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; 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.

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.

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, la finestra del portale aperta, Sleep, cambi di rete e inattività. 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.

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

Sophos Firewall Captive Portal funziona senza Active Directory?

Sì. Captive Portal può autenticare gli utenti anche con il database locale, LDAP o RADIUS. La fonte deve essere selezionata in Firewall authentication methods e gli utenti o gruppi devono corrispondere alla successiva regola firewall.

Captive Portal deve essere raggiungibile da Internet?

No. Captive Portal è destinato agli utenti già presenti in una rete interna, BYOD o Wi-Fi. Per l’accesso esterno sono previsti VPN Portal e una configurazione Remote Access adeguata. In Device Access, consentire Captive Portal solo per le zone client che ne hanno realmente bisogno.