Configurare l'accesso remoto SSL VPN su Sophos Firewall

L’accesso remoto SSL VPN si configura su Sophos Firewall in Remote access VPN > SSL VPN. Per garantire un accesso sicuro, devono essere coerenti sei componenti:

Assegnare utenti o gruppi a una policy SSL VPN.
Configurare a livello globale protocollo, certificato, gateway, intervallo di indirizzi e DNS.
Scegliere consapevolmente Split Tunnel o Use as default gateway.
Consentire il traffico dalla zona VPN con regole firewall restrittive.
Proteggere VPN Portal, autenticazione, MFA e Device Access.
Distribuire un profilo .ovpn aggiornato o, su Windows, un file di provisioning .pro, quindi verificare sia gli accessi consentiti sia quelli negati.

⚠️ SSL VPN è un punto di ingresso accessibile pubblicamente. MFA e password complesse non sostituiscono gruppi di utenti limitati, Local Service ACLs, regole firewall, profili aggiornati, log e revisioni periodiche.

Questo articolo tratta la configurazione del firewall. L’installazione è descritta separatamente per Windows, macOS, iPhone e iPad, Android e Linux. Per la scelta preliminare tra SSL VPN, IPsec e ZTNA, consultare Sophos Connect o SSL VPN.

Preparare i requisiti e gli oggetti

Prima della configurazione devono essere definiti l’accesso pubblico, gli utenti autorizzati e le destinazioni interne:

una versione SFOS attuale e un client Sophos Connect aggiornato;
un FQDN pubblico o un indirizzo IP pubblico;
certificati per il tunnel SSL VPN e VPN Portal;
utenti o gruppi e server di autenticazione;
un metodo MFA per il portale e il tunnel;
un intervallo di indirizzi SSL VPN che non si sovrapponga ad altre reti;
reti interne di destinazione, server DNS e dominio di ricerca;
la scelta tra Split Tunnel e Full Tunnel;
un processo per distribuire i profili e aggiornare i client.

Le destinazioni interne vengono prima create come host o oggetti di rete:

Hosts and services > IP host

L’esempio seguente utilizza:

LAN_Server: 10.10.10.0/24 per i server interni;
LAN_Client: 10.10.20.0/24, se gli utenti remoti necessitano effettivamente di questa rete client;
DNS_Internal: 10.10.10.10 per il DNS interno o il domain controller;
SSLVPN_Users: gruppo di utenti per Policy members.

Non si devono consentire intere reti interne quando sono sufficienti singoli server o sottoreti. Anche i server DNS richiedono un oggetto chiaramente definito, in modo che il routing e la regola firewall siano successivamente comprensibili.

Configurare le impostazioni globali SSL VPN

Le impostazioni globali si applicano a tutte le policy di accesso remoto SSL VPN e fanno parte della configurazione .ovpn:

Remote access VPN > SSL VPN > SSL VPN global settings

Questi valori vengono utilizzati anche per le connessioni SSL Site-to-Site tra due Sophos Firewall. Quando si modifica la porta, il protocollo, il certificato o Override hostname, occorre quindi verificare sia i profili Remote Access sia i tunnel SSL Site-to-Site esistenti e ridistribuirne le configurazioni.

Prima di modificare i valori globali del profilo, documentare Protocol, Port, Override hostname, SSL server certificate, i valori di lease e DNS e la configurazione dei peer SSL Site-to-Site interessati. Includere nel piano di fallback anche gli eventuali NAT o port forwarding a monte. Se il test di accettazione non riesce, ripristinare questi valori e la configurazione Site-to-Site precedente, quindi ripetere con il vecchio profilo i test del portale, del tunnel e degli accessi consentiti e negati.

Protocollo, certificati, gateway e porta

SSL VPN supporta TCP e UDP. In genere UDP è la scelta iniziale più efficiente; TCP può essere utilizzato come alternativa verificata quando reti esterne bloccano UDP. La scelta deve essere provata su reti reali di hotel, operatori mobili o ospiti.

La porta predefinita di SSL VPN è 8443, mentre VPN Portal utilizza per impostazione predefinita 443. Per ogni servizio accessibile pubblicamente, una combinazione univoca di IP WAN, porta e protocollo è la soluzione più chiara.

Sophos utilizza due certificati distinti:

Il SSL server certificate selezionato nelle impostazioni globali SSL VPN viene utilizzato dal server SSL VPN.
Il certificato HTTPS di VPN Portal viene selezionato in Administration > Admin and user settings.

Entrambi i certificati devono corrispondere al rispettivo FQDN pubblico utilizzato. Per i certificati emessi da una CA esterna deve essere disponibile anche la catena di certificati necessaria.

Override hostname determina il FQDN o l’indirizzo IP pubblico nel profilo client. È particolarmente importante in presenza di NAT a monte, più interfacce WAN o DDNS. Se il campo rimane vuoto, il profilo può contenere più indirizzi di interfaccia. Sophos Connect assegna la priorità ai gateway DDNS e prova le altre voci in ordine inverso; un FQDN univoco è quindi più semplice da verificare e gestire.

VPN Portal e SSL VPN possono tecnicamente condividere la stessa porta e lo stesso protocollo. In questo caso, tuttavia, le impostazioni di Login Security non funzionano come previsto e VPN Portal diventa accessibile dalle zone abilitate per SSL VPN. WAF deve differire da VPN Portal per IP WAN o porta e da SSL VPN per IP WAN, porta o protocollo. Sophos Firewall WAF descrive ulteriori dipendenze WAF.

Intervallo di indirizzi e DNS

L’intervallo di indirizzi IPv4 deve essere privato e non deve sovrapporsi a reti interne, VPN site-to-site, route statiche, altri pool di accesso remoto o reti domestiche comuni. Sono particolarmente frequenti 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24 e 10.0.1.0/24.

La documentazione di SFOS 22 si contraddice sul prefisso consentito per i pool IPv4 più piccoli. La guida del campo indica /24 come limite e afferma che non è possibile selezionare sottoreti /25 o più piccole, mentre la FAQ attuale descrive anche sottoreti più piccole distribuite internamente tra più istanze OpenVPN. Fa quindi fede la versione SFOS in uso: verificare quale prefisso offre l’interfaccia e poi controllare il numero effettivo di lease disponibili.

Secondo la FAQ Sophos, il numero di istanze SSL VPN simultanee dipende dalle CPU del modello di firewall. Ogni istanza crea un’interfaccia tun0 e necessita di una propria subnet per routing e distribuzione interna. SFOS suddivide il pool configurato; queste risorse vengono consumate prima dell’assegnazione dei lease ai client. Come esempio illustrativo, la FAQ cita 192.168.0.0/27, otto istanze simultanee e un solo IP ancora assegnabile. Non è una capacità universale né una rete di esempio consigliata: verificare i lease reali sul build e modello di destinazione; il conflitto tra guida del campo e FAQ descritto sopra rimane.

SFOS 23: L’intervallo IPv4 selezionabile dipende dal modello di firewall; i modelli più grandi supportano subnet con più indirizzi IP. La guida di SFOS 23 indica /24 come la subnet più piccola selezionabile. È un limite di selezione legato al modello, non una garanzia di un determinato numero di lease per i client. La suddivisione interna in base alle CPU spiega il consumo di indirizzi, ma non gli intervalli selezionabili supportati. Questo non risolve il conflitto di SFOS 22 né trasforma l’illustrazione /27 in una raccomandazione di configurazione.

Prima di modificare l’intervallo, documentare il build SFOS, il modello, l’intervallo precedente e le assegnazioni statiche, conservando i valori precedenti per il rollback. Selezionare nell’interfaccia solo un intervallo supportato dal modello di destinazione, mantenere gli indirizzi statici degli utenti nell’intervallo statico risultante e controllare i lease effettivamente disponibili. Riconnettere quindi un utente pilota e verificare lease, DNS e destinazioni consentite e bloccate. Se il collaudo fallisce, ripristinare valori e assegnazioni precedenti e ripetere i test. Se build, interfaccia, guida o FAQ sono in contraddizione, fermare il rollout di capacità che ne dipende fino al chiarimento con il supporto; non forzare una maschera.

API XML SFOS 23 – stato 551: La riga di stato grezza per Configure SSLVPN Tunnel Access rimanda all’identificatore di runtime non risolto Message.SSLVPNInvalidLeaseIPv4Mask. Non consente di dedurre un testo del messaggio confermato, una causa di rifiuto accertata o un nuovo intervallo di maschere supportato. Se l’API restituisce 551, conservare la risposta completa e le impostazioni precedenti. Prima di qualsiasi modifica, verificare StartIP, SubnetMask e la selezione del pool supportata dal build installato e dal modello, usando la guida approvata per quell’ambiente o rivolgendosi a Sophos Support; non forzare una maschera.

Dopo una correzione supportata, verificare la risposta dell’API, le impostazioni effettivamente salvate sul firewall di destinazione e il lease di un utente pilota riconnesso. Conservare i valori e le assegnazioni precedenti per il rollback descritto sopra. Se la diagnosi o il testo del messaggio restano rilevanti per l’approvazione e non chiariti, mantenere il deployment in sospeso.

Un pool piccolo non è una misura di controllo degli accessi, che devono essere limitati tramite la policy e le regole firewall. Nelle regole si utilizzano gli host di sistema ##ALL_SSLVPN_RW e, per IPv6, ##ALL_SSLVPN_RW6.

I server DNS interni vengono inseriti in IPv4 DNS. Domain name contiene il dominio di ricerca che viene aggiunto ai nomi host brevi. Con Split Tunnel, il server DNS o la sua rete deve inoltre essere incluso in Permitted network resources e risultare raggiungibile tramite una regola firewall dalla zona VPN. Con Full Tunnel non serve la route specifica di Split Tunnel, ma la regola firewall rimane necessaria.

Se il firewall stesso funge da resolver DNS, inserire il suo indirizzo appropriato in IPv4 DNS. Inoltre, consentire DNS per la zona VPN in Administration > Device access. Un test mediante indirizzo IP e uno separato mediante nome host permettono di distinguere un problema di routing da un problema DNS.

IP statici, sessioni simultanee e tempi

Gli indirizzi IP SSL VPN statici sono possibili per casi speciali giustificati, come un’autorizzazione legacy basata su IP, e devono rientrare nel pool configurato. Un utente con un indirizzo IP SSL VPN statico non può tuttavia stabilire più sessioni di accesso remoto simultanee.

Indipendentemente da ciò, Simultaneous logins, in Authentication > Services o direttamente nell’utente locale, limita gli accessi simultanei. Il valore globale si applica solo agli utenti creati successivamente.

Key lifetime controlla il momento del rekey e non rappresenta un timeout di inattività o una durata massima della sessione. Le connessioni inattive vengono gestite tramite le impostazioni globali di inattività e, facoltativamente, mediante Disconnect idle clients nella policy. In caso di disconnessioni impreviste, questi valori, l’assegnazione di IP statici, gli accessi simultanei e i log devono essere verificati separatamente.

Disconnect dead peer after è un valore globale espresso in secondi e chiude le connessioni dei client che non rispondono. I valori predefiniti sono 180 secondi per TCP e 100 secondi per UDP; per UDP SFOS accetta valori da 60 a 110. Disconnect idle peer after, invece, è espresso in minuti e chiude le sessioni effettivamente inattive. Prima di aumentare un valore, utilizzare sslvpn.log, il log del client e i dati sulla perdita di pacchetti per stabilire quale timer intervenga realmente.

L’Override global timeout di una policy può solo ridurre il valore globale di inattività. Se il valore della policy è superiore, continua ad applicarsi il valore globale. Una vecchia pagina di troubleshooting Sophos consiglia un valore superiore nella policy per singoli utenti, ma l’attuale guida ai campi di SFOS 22 lo contraddice esplicitamente. Per consentire sessioni più lunghe, non aumentare inutilmente il valore nella policy; adeguare il valore globale dopo averne valutato l’impatto e ripetere il test con lo stesso gruppo di utenti.

Creare la policy SSL VPN

La policy viene creata manualmente o tramite l’assistente:

Remote access VPN > SSL VPN

Sophos consiglia l’assistente soprattutto per la prima policy SSL VPN. Mostra le impostazioni globali solo per la verifica e non consente di modificarle. Applica i server e i metodi di autenticazione selezionati, configura Device Access per VPN Portal e SSL VPN e crea la policy e la regola firewall. Al primo utilizzo crea il gruppo di regole Automatic VPN rules all’inizio della tabella delle regole e abilita la nuova regola. Le regole create successivamente dall’assistente vengono inserite alla fine di questo gruppo. Dopo ogni esecuzione, verificarne la posizione e la Rule ID che corrisponde effettivamente. Negli ambienti esistenti, Configure manually è spesso più trasparente:

Selezionare Add > Configure manually.
Inserire, ad esempio, SSLVPN-Remote-Users in Name.
Selezionare il gruppo SSLVPN_Users in Policy members.
Definire Split Tunnel o Use as default gateway.
Con Split Tunnel, selezionare LAN_Server e DNS_Internal come Permitted network resources. Utilizzare qui oggetti di rete o host, non interfacce: la selezione di un’interfaccia non garantisce l’accesso alla relativa sottorete.
Configurare facoltativamente Disconnect idle clients e Override global timeout.
Salvare e verificare la configurazione con un normale membro del gruppo di destinazione.

Gli utenti e i gruppi guest non possono essere utilizzati come Policy members. Se un utente o un gruppo è già incluso in una policy SSL VPN precedente, SFOS rimuove tale assegnazione dalla policy precedente. Le sovrapposizioni devono quindi essere controllate prima del salvataggio.

Un Override global timeout specifico della policy si applica solo se è inferiore al valore globale di inattività. Un valore superiore non sostituisce il limite globale.

Split Tunnel o Full Tunnel

Con Split Tunnel vengono instradate tramite la VPN solo le reti IPv4 e IPv6 e le destinazioni FQDN supportate selezionate in Permitted network resources. Le destinazioni FQDN sono supportate solo per IPv4. Il restante traffico Internet rimane locale. Ciò riduce il carico del firewall e la latenza, ma richiede una pianificazione precisa delle risorse e del DNS.

Quando cambia l’indirizzo IP di una destinazione FQDN consentita, i tunnel esistenti non vengono aggiornati automaticamente. Gli utenti interessati devono disconnettersi e riconnettersi.

Con Full Tunnel si attiva Use as default gateway. Tutto il traffico dell’utente passa quindi attraverso il firewall. Permitted network resources non viene applicato come limite di accesso. Le destinazioni e i servizi interni devono essere limitati mediante regole firewall; l’accesso IPv4 a Internet richiede inoltre una regola SNAT/MASQ adeguata.

Full Tunnel consente un controllo centralizzato di web, DNS e log, ma aumenta il consumo di banda, il carico del firewall e l’impegno per privacy e supporto. Deve quindi essere testato con applicazioni reali e utenti simultanei.

Regole firewall, Device Access e autenticazione

Regole firewall e DNS

La creazione del tunnel non consente ancora l’accesso alle risorse interne. A tale scopo viene creata una regola:

Rules and policies > Firewall rules

Esempio per Split Tunnel:

Rule name: VPN_SSLVPN_to_Internal_Servers
Action: Accept
Source zone: VPN
Source networks and devices: ##ALL_SSLVPN_RW
Destination zones: LAN
Destination networks: LAN_Server, DNS_Internal
Services: solo i servizi applicativi necessari e DNS
Log firewall traffic: attivato

La regola deve trovarsi al di sopra di regole VPN più ampie. Un test negativo verso una destinazione non consentita mostra se una regola generale posizionata più in basso concede involontariamente l’accesso.

Per IPv4 Full Tunnel si aggiungono una regola da VPN a WAN e una regola SNAT/MASQ adeguata. IPv6 richiede invece un routing IPv6 pianificato e regole firewall IPv6 dedicate. In caso di accesso mancante sono utili Log Viewer, Rule ID e la guida per testare le regole firewall.

VPN Portal, Device Access e MFA

Il portale, i servizi locali e l’autenticazione vengono verificati in sezioni distinte:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

Sono necessari almeno:

SSL VPN nelle zone dalle quali deve essere possibile stabilire il tunnel;
VPN Portal solo nelle zone effettivamente necessarie;
DNS nella zona VPN solo se il firewall funge da resolver;
i VPN portal authentication methods appropriati;
i SSL VPN authentication methods appropriati;
MFA per il portale e il tunnel.

Quando un metodo di autenticazione contiene più server, SFOS li interroga nell’ordine visualizzato. Per ogni metodo è possibile selezionare al massimo 20 server. In presenza di nomi utente identici o di un meccanismo di fallback, verificare quale server elabora effettivamente la richiesta.

Le normali regole firewall non controllano questi servizi locali. Reti di origine più ristrette, singoli indirizzi IP o paesi vengono configurati mediante Local Service ACL Exception Rules. Il processo di protezione completo è descritto in Device Access e Local Service ACL.

Il web proxy del firewall costituisce un caso particolare: le richieste HTTP e HTTPS che lo attraversano vengono considerate interne per i servizi locali. Gli utenti con accesso al proxy possono quindi raggiungere VPN Portal anche se non è abilitato per la loro zona di origine. Quando si utilizza il proxy, verificare separatamente questa raggiungibilità anziché affidarsi soltanto alla matrice delle zone in Device Access.

I Third-party Threat Feeds possono bloccare anche l’accesso diretto al sistema e ai servizi VPN. In questo modo è possibile bloccare ulteriormente fonti indesiderate note; Threat Feeds su Sophos Firewall ne descrive configurazione e limiti.

VPN portal authentication methods controlla l’accesso al portale e il download del profilo, mentre SSL VPN authentication methods controlla l’accesso al tunnel. WebAdmin è un’interfaccia di amministrazione separata e non deve essere abilitata dalla zona WAN per utilizzare SSL VPN.

SSO in base alla versione SFOS: In SFOS 22, configurare Microsoft Entra ID con Server type: Microsoft Entra ID SSO. In SFOS 23, aprire Authentication > Servers > Add, selezionare Server type: OpenID Connect e poi IdP vendor: Microsoft Entra ID o IdP vendor: Google Workspace. La configurazione di applicazione, server, Redirect URIs e gruppi è descritta rispettivamente in Microsoft Entra ID SSO per Sophos Connect e Google Workspace OIDC su Sophos Firewall. Queste varianti non confermano la disponibilità GA di un build.

Prima di scaricare il profilo, selezionare lo stesso server IdP configurato in Authentication > Services per VPN portal authentication methods e SSL VPN authentication methods, quindi fare clic su Apply per ogni servizio; in SFOS 22 si tratta dello stesso server Entra. Confrontare la Redirect URI completa presso il provider scelto, inclusi FQDN, porta e percorso, e verificare gli endpoint di accesso necessari. Un SSO riuscito non sostituisce appartenenza ai gruppi, Policy members o regole firewall restrittive. Prima del passaggio, conservare assegnazioni dei servizi, ordine dei server e profili funzionanti. Dopo modifiche SSO, scaricare e importare nuovamente la configurazione attuale e testare con un normale utente pilota portale, tunnel, MFA dell’IdP, DNS e destinazioni consentite e bloccate. In caso di errore, ripristinare le assegnazioni, l’ordine e i profili corrispondenti documentati e ripetere gli stessi test; non rimuovere l’accesso precedente prima del collaudo riuscito.

Per l’OTP nativo di SFOS, selezionare gli utenti o i gruppi di destinazione in Authentication > Multi-factor authentication e abilitare sia VPN portal sia SSL VPN remote access in Require MFA for. Con Generate OTP token with next sign-in, l’utente deve prima scansionare il codice QR in VPN Portal; solo dopo può iniziare il test del tunnel.

VPN Portal non supporta l’autenticazione RADIUS con Challenge MFA. Anche Sophos Connect non supporta un challenge OTP, ma invia insieme password e OTP; sono supportati i metodi Call e Push. Il metodo scelto deve essere testato con un normale utente pilota. Per ulteriori informazioni, consultare MFA per Sophos Firewall.

Distribuire e aggiornare il profilo client

Se cambiano valori globali rilevanti per il profilo, come protocollo, porta, interfaccia, certificato del server o Override hostname, scaricare nuovamente il file .ovpn corrente dal VPN Portal, distribuirlo in modo protetto e, in caso di distribuzione manuale, importarlo nuovamente nel client. Update policy non è il primo passo in questo caso e non sostituisce la nuova importazione manuale. L’utilizzo documentato riguarda una connessione sottoposta a provisioning tramite .pro: dopo una modifica della porta SSL VPN o del protocollo, eseguire Update policy su tale connessione; questo percorso di provisioning recupera automaticamente le ulteriori modifiche alla configurazione. In caso di modifiche, ad esempio alla porta, al gateway, al certificato del server o al protocollo, potrebbe essere necessario effettuare nuovamente l’accesso. Un aggiornamento del software Sophos Connect non sostituisce un profilo obsoleto. Conservare in modo sicuro il profilo noto come funzionante e i relativi valori globali del firewall per il rollback; prima della distribuzione su larga scala, verificare la nuova importazione con un normale utente pilota controllando gateway/porta, autenticazione/MFA, rotte, DNS e destinazioni consentite e bloccate. Se il collaudo non riesce, ripristinare insieme i vecchi valori e il relativo profilo noto come funzionante, quindi ripetere le stesse verifiche.

Dopo una modifica di Override hostname o della porta, occorre verificare nel client che il profilo appena importato utilizzi effettivamente il nuovo nome del gateway e la nuova porta.

Dopo modifiche a Policy members, Permitted network resources o all’indirizzo IP di una destinazione FQDN, normalmente è invece sufficiente disconnettersi e riconnettersi. Le reti consentite non sono memorizzate staticamente nel file .ovpn; SFOS aggiunge le risorse specifiche dell’utente quando viene stabilito il tunnel. Queste modifiche non richiedono quindi un nuovo download del file .ovpn.

.pro recupera IPsec (.scx) e le configurazioni SSL VPN autorizzate per l’utente (.ovpn) dal VPN Portal, oltre alle modifiche successive; non è un profilo di tunnel. Sono supportati client Windows compatibili e Sophos Connect per macOS da 2.1, non il client macOS 2.0 o precedente. Il provisioning IPsec richiede Sophos Connect 2.1 o successivo. Sul client macOS 2.0 restano necessari import diretti e aggiornamenti manuali controllati.

Se cambiano il gateway di provisioning o vpn_portal_port, anche il file .pro deve essere adattato e ridistribuito. Il campo precedente user_portal_port viene accettato solo per compatibilità. Durante il primo provisioning con OTP o un altro metodo MFA, l’accesso può essere richiesto due volte: prima per scaricare i profili e poi per stabilire il tunnel.

Se il file .pro fornisce solo una connessione IPsec o nessuna configurazione SSL VPN, occorre controllare innanzitutto Policy members, l’appartenenza al gruppo, la raggiungibilità di VPN Portal e l’autenticazione.

Per il provisioning SSO con .pro su Windows con Sophos Connect 2.4 o successivo, SFOS 22 descrive Entra ID; SFOS 23 supporta i provider di identità OIDC compatibili con questo flusso, non qualsiasi provider. In Authentication > Services, VPN Portal, IPsec VPN e SSL VPN devono utilizzare lo stesso server IdP configurato. gateway contiene solo il FQDN o l’indirizzo IP del firewall indicato nella sezione Redirect URI di quel server, non l’URI di callback completo; la porta del portale si imposta separatamente in vpn_portal_port. Per SSO, macOS con Sophos Connect 2.1 o successivo resta qui limitato a Entra ID, senza estensione a OIDC in generale; rimane necessaria la conferma del supporto prima del rollout indicata sotto. Il seguente articolo sul provisioning spiega i prerequisiti specifici del provider e della versione.

Provisioning di Sophos Connect con .pro e GPO descrive la struttura JSON completa, i campi MFA, la selezione dei gateway e la distribuzione tramite GPO.

Per Google Workspace SSO, questa guida è limitata a Windows con Sophos Connect 2.4 o successivo; le indicazioni Entra per macOS non si applicano a Google. Per Entra, le pagine di panoramica indicano macOS da 2.1, non 2.0, mentre le pagine dei requisiti indicano solo Windows da 2.4. Questa contraddizione rimane irrisolta anche nell’articolo di dettaglio collegato: fermare il rollout macOS finché il supporto per build di destinazione, piattaforma/versione del client e tipo di VPN richiesto non sia stato confermato e testato separatamente. Per ogni percorso approvato, verificare impostazioni SFOS compatibili, configurazione client attuale, metodi di autenticazione e Redirect URI; testare MFA presso l’IdP. Non si garantiscono un flusso browser identico o l’applicabilità del deployment GPO Windows a macOS.

I nomi dei profili devono essere univoci, le vecchie voci di connessione devono essere rimosse dopo un cambio di gateway o utente e la distribuzione deve essere verificata con un normale utente di destinazione. Per informazioni sulle versioni del client, consultare Aggiornare Sophos Connect in sicurezza.

SSL VPN con Sophos Connect: Windows 10/11; client macOS 2.0 su macOS 13+, e client 2.1 o successivo su macOS 14+. Linux, iOS e Android usano un client OpenVPN compatibile.

In Current activities > Remote users è possibile filtrare gli utenti remoti connessi per Connection date, Username, Source IP address e Leased IP address. La colonna Mode distingue tre stati:

SSL VPN (remote access): tunnel di accesso remoto stabilito
User portal (clientless access): accesso al portale di un membro di una policy SSL VPN clientless
User portal: accesso al portale senza tale appartenenza

Una voce del portale non prova quindi la presenza di un tunnel SSL VPN. Disconnect termina la sessione selezionata. Prima di un test di supporto o accettazione si documentano utente, indirizzi, modalità e ora.

Testare la configurazione e isolare gli errori

Test di accettazione

Un test completo utilizza un normale utente pilota e una destinazione interna concreta:

L’utente vede esattamente la configurazione SSL VPN prevista in VPN Portal.
Verificare MFA con un fattore corretto e uno errato.
Importare .ovpn o .pro e controllare l’indirizzo assegnato.
Con Split Tunnel, verificare la route verso LAN_Server e DNS_Internal.
Testare la destinazione interna prima tramite indirizzo IP e poi tramite nome host.
Richiamare il servizio consentito e controllare Firewall Rule ID in Log Viewer.
Generare un accesso non consentito e confermare il drop.
Con Full Tunnel, verificare inoltre l’accesso pubblico a Internet, DNS, Web Policy e IPv4-SNAT.
Dopo una modifica della policy o di un FQDN, disconnettersi, riconnettersi e ripetere lo stesso test.

Ogni test deve riportare ora, utente e gruppo, piattaforma e versione del client, rete di origine, destinazione e servizio. Se il test viene eseguito solo con un amministratore, gli errori relativi a gruppi, MFA e policy possono passare facilmente inosservati.

Log per fase dell’errore

Occorre innanzitutto stabilire se l’errore si verifica durante l’accesso al portale, l’autenticazione, la creazione del tunnel o soltanto durante l’accesso alla destinazione:

VPN Portal: vpnportal.log
Autenticazione normale: access_server.log
Microsoft Entra SSO in SFOS 22: oauth_sso_vpn.log; per SFOS 23, usare le indicazioni sui log specifiche della versione nell’articolo di dettaglio Entra o Google pertinente.
Certificati SSL VPN specifici dell’utente: peruser_cert_sslvpn.log
Servizio SSL VPN: sslvpn.log
Connessioni attive: openvpn-status*.log
Traffico verso la destinazione: log del firewall, Rule ID e, se necessario, Packet Capture

In Packet Capture, Incoming dimostra soltanto che il firewall ha ricevuto il pacchetto. Se compare Forwarded ma non arriva alcuna risposta, occorre controllare la route di ritorno, NAT, il sistema di destinazione e il relativo firewall locale.

Per il traffico TUN, nei log di SFOS l’indirizzo dell’interfaccia TUN può comparire come sorgente e l’indirizzo assegnato al client come destinazione. Ciò non significa che gli indirizzi siano invertiti. Per interpretare la voce occorre considerare insieme utente, lease, direzione del traffico, Rule ID e ora del test.

L’associazione di altri processi e file è descritta in Servizi e log di Sophos Firewall.

Nessun utente riesce a stabilire un tunnel: servizio e limiti flood

Quando il problema riguarda tutti gli utenti, eseguire prima controlli in sola lettura, senza modificare policy, limiti flood o servizi. Annotare l’ora del test, il protocollo e la porta SSL VPN configurati, le impostazioni DoS correnti e la presenza di almeno una policy SSL VPN.

Accedere alla CLI, selezionare 5. Device management, quindi 3. Advanced shell, e controllare lo stato del servizio con il comando documentato da Sophos:
```
service -S | grep sslvpn
```
Il servizio deve mostrare Running. UNREGISTERED significa che non è registrata alcuna policy SSL VPN; verificare che ne esista almeno una. Se una policy esiste ma il servizio continua a non mostrare Running, correlare sslvpn.log con l’ora del test e analizzare la discrepanza invece di riavviare servizi senza una procedura documentata.
In Intrusion prevention > DoS & spoof protection > DoS settings, controllare le opzioni e i limiti flood abilitati per UDP, TCP e ICMP/ICMPv6. Per il traffico del tunnel, usare il protocollo SSL VPN configurato. SFOS scarta il traffico SSL VPN e le richieste ping quando viene superato il limite corrispondente; un ping non riuscito, da solo, non dimostra il superamento. Correlare il tentativo di connessione con le prove dello scarto prima di creare un’eccezione.
Solo se è stata confermata la corrispondenza con un limite flood, registrare la configurazione esistente e creare in DoS bypass rules la regola temporanea inbound più restrittiva possibile. L’esempio Sophos usa l’indirizzo IP/netmask di origine pertinente (oppure * solo se inevitabile), l’indirizzo della risorsa di rete consentita come destinazione, il protocollo effettivo TCP o UDP, porta di origine Any e la porta di destinazione SSL VPN configurata (8443 per impostazione predefinita). Limitare ulteriormente origine e destinazione quando il test lo consente; non disabilitare globalmente la protezione flood.
Ripetere gli stessi test temporizzati di connessione e accesso alla risorsa consentita. Se la regola di bypass non spiega lo scarto, rimuoverla immediatamente. Dopo la diagnosi, rimuovere la regola temporanea oppure approvare e documentare formalmente l’eccezione limitata. Ripristinare ai valori annotati gli eventuali limiti flood modificati separatamente, quindi ripetere i test di accesso consentito e bloccato.

La richiesta raggiunge il server, ma manca la risposta

Se è dimostrato che la richiesta del client SSL VPN raggiunge la risorsa interna consentita, ma la risposta non torna al client, occorre controllare il percorso di ritorno in due fasi: prima dalla risorsa al firewall e poi dal firewall all’indirizzo SSL VPN assegnato. Lo stato verde del tunnel non permette di isolare questo errore.

Sulla risorsa interna o sul relativo router, verificare che il percorso di ritorno verso il pool di indirizzi SSL VPN passi attraverso Sophos Firewall. Una route di ritorno specifica è più trasparente dello SNAT. Utilizzare lo SNAT solo in modo mirato quando il ritorno non può essere instradato e la conseguente modifica dell’indirizzo sorgente è accettabile.
Confermare con Packet Capture che la risposta raggiunga il firewall. L’indirizzo sorgente, l’indirizzo di destinazione assegnato, il servizio e l’ora del test devono corrispondere al tentativo di accesso originale.
In Routing > SD-WAN routes, controllare la Route Precedence attuale e le route SD-WAN troppo ampie. SSL VPN appartiene alla categoria static. Se sdwan_policyroute viene prima, una route con la risorsa interna o Any come sorgente e Any come destinazione e servizio può deviare la risposta dal tunnel.
Limitare preferibilmente la route SD-WAN interessata in modo che il pool di indirizzi SSL VPN non corrisponda più come destinazione. Sophos indica in alternativa un’eccezione del servizio per porta e protocollo SSL VPN; questa variante deve essere coerente con la struttura reale delle regole e del traffico.
Modificare la Route Precedence globale solo dopo averne valutato l’impatto. La modifica non riguarda soltanto questa connessione. Preparare ordine iniziale, accesso di gestione e rollback come descritto in Route Precedence su Sophos Firewall.
Ripetere l’accesso e verificare nella cattura l’ingresso della risposta dalla risorsa e l’inoltro verso l’indirizzo assegnato. Quindi riconnettersi e ripetere il test con la stessa applicazione.

⚠️ Una regola ampia con Any, una regola SNAT generica o una modifica globale della Route Precedence possono spostare il problema visibile e interrompere altri percorsi VPN, WAN o di gestione. Fermarsi se non sono stati dimostrati il percorso di ritorno al firewall o la route SD-WAN effettivamente corrispondente.

La rete domestica e la rete interna di destinazione si sovrappongono

Se, ad esempio, il client esterno utilizza 192.168.1.0/24 e anche la risorsa interna consentita si trova in 192.168.1.0/24, il sistema operativo considera normalmente la destinazione come locale. Il pacchetto non raggiunge quindi il tunnel SSL VPN. La soluzione permanente più pulita consiste nel rinumerare una delle due reti.

Se non è possibile farlo subito, Sophos documenta una soluzione alternativa DNAT strettamente limitata. Si sceglie un indirizzo virtuale di destinazione libero che non si sovrapponga ad alcuna rete locale, interna, VPN, statica o SD-WAN. Con Split Tunnel, questo indirizzo deve essere inviato al client come Permitted network resource, seguito da una nuova connessione. La regola DNAT utilizza l’intervallo di lease SSL VPN come Original source, Original come Translated source, l’indirizzo virtuale come Original destination e l’host interno reale come Translated destination. I servizi e la relativa regola firewall da VPN alla zona di destinazione restano limitati all’accesso effettivamente necessario.

L’utente accede quindi all’indirizzo virtuale o a un nome DNS dedicato che vi risolve. Log Viewer deve mostrare la Firewall Rule ID e la NAT Rule ID previste; un Packet Capture conferma la traduzione e il percorso di ritorno. Non creare un intero intervallo sostitutivo se serve un solo host. Fermarsi se l’indirizzo virtuale non è inequivocabilmente libero o se sarebbe necessaria una regola NAT ampia.

Problemi tipici

File .ovpn assente o vuoto nel VPN Portal: Risolvere un download OVPN assente o vuoto distingue gli errori di policy, User ID, certificato, storage, firmware e HA. Gli account guest non sono consentiti. Sophos Connect supporta solo nomi utente ASCII; nome utente e dominio non possono superare complessivamente 51 caratteri.
L’accesso non riesce: confrontare access_server.log e vpnportal.log con l’ora del test; per Entra in SFOS 22 usare anche oauth_sso_vpn.log, mentre in SFOS 23 usare le indicazioni sui log OIDC specifiche della versione nell’articolo di dettaglio pertinente. Verificare lo stesso server IdP per portale e SSL VPN, Redirect URIs e catena di certificati completa.
Il tunnel è attivo, ma le destinazioni interne non sono raggiungibili: controllare la route sull’endpoint, Permitted Resources con Split Tunnel, la regola firewall, la route di ritorno, il firewall di destinazione e un’eventuale sovrapposizione con la rete domestica locale.
L’indirizzo IP funziona, il nome host no: controllare server DNS, dominio di ricerca, route Split Tunnel, regola firewall DNS, DoH locale o DNS dell’endpoint e, se necessario, Device Access per DNS.
Sono interessati solo alcuni utenti: confrontare appartenenza al gruppo, assegnazione della policy, MFA, IP statico, Simultaneous logins e profilo caricato.
Sono interessati solo i client meno recenti: importare un file .ovpn aggiornato dopo modifiche globali. Se sono cambiati solo la policy o un FQDN, riconnettersi prima e controllare il routing caricato.
Full Tunnel senza Internet: controllare la regola da VPN a WAN, IPv4-SNAT, DNS e le Web/Security Policies applicate.
I trasferimenti di grandi dimensioni si bloccano: se gli accessi di piccole dimensioni funzionano, controllare MTU e MSS lungo il percorso effettivo. Per la procedura, consultare MTU e MSS per problemi VPN.
La connessione termina dopo un periodo prolungato: confrontare l’ora di inizio e di interruzione con Idle Timeout, Disconnect idle clients e Key Lifetime. Controllare IP statico e Simultaneous logins; se necessario, assegnare dinamicamente un indirizzo a un utente pilota e analizzare sslvpn.log e openvpn-status*.log all’ora del test.
Nessun utente riesce a stabilire il tunnel: oltre a Device Access e all’apertura della porta, cercare una regola DNAT ampia con Original destination: Any e Services: Any, oppure con la porta SSL VPN, che intercetta in precedenza l’avvio della connessione.
WAF, il portale o SSL VPN sono in conflitto: confrontare IP WAN, porta e protocollo di tutti i servizi locali e delle regole WAF. Le combinazioni condivise possono causare un’ulteriore esposizione del portale o impedire il funzionamento di Login Security.

Durante il funzionamento devono essere verificati regolarmente gruppi, MFA, assegnazioni di IP statici, scadenza dei certificati, intervallo di indirizzi, Device Access, regole firewall, distribuzione dei profili e log. Le nuove versioni di SFOS e Sophos Connect devono essere prima collaudate con un utente pilota e con test positivi e negativi verso le destinazioni.