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 dovrebbero 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.

Limiti dell’API XML per SFOS 22/23: La documentazione dell’API legacy per Configure SSLVPN Tunnel Access indica per DisconnectDeadPeerAfter un valore predefinito di 300 secondi, un intervallo da 60 a 1800 e il valore 180 nell’esempio, senza associarli a un protocollo specifico. Questo non dimostra né un valore predefinito effettivo per TCP/UDP né un nuovo valore predefinito della GUI. Non sostituire quindi i valori TCP/UDP descritti sopra sulla base di questa tabella dell’API; verificare il timer effettivamente salvato in Remote access VPN > SSL VPN > SSL VPN global settings sul build installato.

Anche lo schema dei lease resta irrisolto per quanto riguarda i requisiti condizionali: LeaseMode consente IPv4, sebbene IPv6Lease e IPv6Prefix siano elencati come campi obbligatori e rimangano vuoti nell’esempio; per il prefisso, la tabella indica un intervallo da 64 a 112. Da ciò non si può dedurre né che sia consentito inviare campi IPv6 vuoti né che manchi il supporto dual-stack. EndIP e CompressSSLVPNTraffic compaiono solo nell’esempio e non definiscono né un contratto di scrittura validato né una raccomandazione sulla compressione. Prima di procedere con un’automazione che dipenda da queste informazioni, Sophos Support o la documentazione approvata per il build di destinazione devono chiarire i campi obbligatori condizionali e i valori da scrivere; fino ad allora, non eseguire alcuna modifica XML derivata da tali informazioni. Per le modifiche supportate, conservare prima i valori globali effettivi di timer, lease e DNS e le configurazioni dei peer SSL Site-to-Site interessati, quindi verificare la risposta, i valori salvati e il lease di un utente pilota appena riconnesso. Se il collaudo non riesce, ripristinare esattamente i valori iniziali annotati e le relative configurazioni dei peer, quindi ripetere gli stessi test di accesso.

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.

Limiti dell’API XML per la policy: Gli esempi Add/Edit per SFOS 22/23 separano, all’interno di SSLVPNPolicy, i rami TunnelPolicy e ClientlessPolicy, ciascuno con il proprio Name e PolicyMembers/Member. L’accesso alle risorse di rete tramite tunnel e la pubblicazione clientless sono attività distinte, con nomi di policy e assegnazioni dei membri separati. WebAccessibleResources contiene BookmarkGroups e Bookmarks, non risorse IP del tunnel. Non trattare una modifica come una modifica congiunta di entrambe le sottopolicy; non reinterpretare le autorizzazioni ai bookmark come risorse del tunnel.

La tabella indica inoltre il campo obbligatorio Web Access con i valori 1 e 6, senza un campo corrispondente nell’esempio né un’associazione confermata alle modalità della GUI. Per UseAsDefaultGateway riporta il valore predefinito SplitTunnel e per DisconnectIdleClients il valore UseGlobalSettings, sebbene per entrambi indichi solo Off e On come valori consentiti. Non dedurre da queste informazioni alcuna associazione numerica alle modalità, alcun valore predefinito inviabile, alcun effetto dei campi omessi né alcuna modalità di serializzazione dei membri. Mantenere in sospeso la modifica tramite API che dipende da questi aspetti finché non saranno chiariti per il build di destinazione; la configurazione tramite GUI descritta sopra resta il percorso sicuro. Full Tunnel continua a richiedere regole firewall restrittive e il valore di inattività della policy può solo ridurre 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.

Ritirare una policy SSL VPN in sicurezza

Una policy non più necessaria va eliminata in modo mirato; disconnettere una sessione non la sostituisce. Prima dell’eliminazione, stabilire quale accesso deve cessare e quali autorizzazioni sono ancora necessarie.

Selezionare il Name esatto salvato e il ramo di policy previsto: TunnelPolicy per l’accesso tramite tunnel oppure ClientlessPolicy per l’accesso clientless. Non basarsi soltanto su un nome visualizzato simile.
Verificare Policy members, l’effettiva appartenenza ai gruppi e le risorse di rete assegnate oppure i bookmark e i gruppi di bookmark. Confermare che il ritiro sia approvato e che nessun accesso ancora necessario dipenda da questa policy. Se le assegnazioni non sono chiare, fermarsi e chiarire prima le dipendenze; una riassegnazione può rimuovere membri da una policy precedente.
Conservare in modo protetto e ripristinabile nome, ramo, membri e tutte le impostazioni associate. In Remote access VPN > SSL VPN, eliminare soltanto la policy selezionata tramite la procedura di eliminazione supportata per il build di destinazione installato. Se la procedura non è chiaramente confermata, consultare la documentazione approvata o Sophos Support prima della modifica.
Se l’accesso deve cessare immediatamente, controllare separatamente le sessioni attive in Current activities > Remote users, verificando utente, indirizzi e Mode, e terminare in modo mirato le sessioni interessate con Disconnect. La disconnessione non sostituisce la revoca delle autorizzazioni; non dedurre dall’eliminazione la chiusura automatica dei tunnel.
Ricontrollare le policy salvate e le assegnazioni dei membri. Con un normale utente interessato, verificare la configurazione prevista in VPN Portal e l’autorizzazione durante un nuovo tentativo di connessione. L’accesso precedentemente concesso dalla policy ritirata deve cessare; quello ancora approvato tramite altre policy deve rimanere disponibile. Verificare il traffico effettivamente consentito e bloccato insieme ai log del firewall e, per l’accesso clientless, le autorizzazioni previste per i bookmark. Chiarire risultati imprevisti prima di altre eliminazioni; utilizzare le impostazioni conservate per un ripristino mirato solo previa approvazione.

Limiti dell’operazione Delete: Le pagine Delete dell’API XML legacy per SFOS 22/23 indicano Name come parametro obbligatorio, ma non confermano un contratto XML completo di eliminazione, effetti a cascata o la semantica dei risultati e delle sessioni. Non dedurne un payload Delete, codici di stato, testi dei messaggi o una revoca immediata dell’accesso.

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 dovrebbe 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.

Completare la configurazione e preparare la diagnosi

In un nuovo ambiente, utilizzare Hosts and services > IP host > Add per inserire nome e rete o indirizzo host, quindi Save. Creare SSLVPN_Users in Authentication > Groups > Add con valori adeguati di Surfing quota e Access time, quindi salvare. In Authentication > Users > Add, impostare nome utente, nome visualizzato e questo gruppo, quindi salvare. L’accesso a internet illimitato e gli orari senza restrizioni sono valori di esempio, non requisiti di sicurezza. Per utenti di directory esistenti, verificare l’assegnazione al gruppo invece di creare account locali superflui.

Oltre ai valori globali descritti sopra, verificare:

Lease mode: IPv4 only assegna solo IPv4; IPv4 and IPv6 both assegna entrambe le famiglie di indirizzi. Pool IPv6, rotte e regole devono essere coerenti. Use static IP addresses mostra l’intervallo statico suddiviso automaticamente; assegnare gli indirizzi individuali in Authentication > Users.
IPv4 WINS: Inserire i server WINS primario e secondario solo se l’ambiente richiede questo servizio di nomi. WINS non sostituisce DNS.
Encryption algorithm, Authentication algorithm e Key size: Scegliere consapevolmente cifratura, autenticazione dei messaggi e lunghezza della chiave secondo i requisiti di sicurezza approvati. Key lifetime è espresso in secondi. Non indebolire la crittografia per diagnosticare una connessione.
Enable debug mode: Fornisce log SSL VPN più dettagliati. Attivarlo solo per un’indagine specifica, proteggere i log e ripristinare poi lo stato precedente.

Salvare le modifiche globali con Apply. Per una catena di certificati firmata esternamente, importare il certificato server con la chiave privata, la CA intermedia e la CA radice. Anche modifiche a Default CA con ApplianceCertificate o un certificato firmato localmente richiedono una nuova importazione manuale di .ovpn. Non utilizzare caratteri UTF-8 nei campi del certificato e della CA; i caratteri speciali nei nomi utente possono influire anche su portale, nomi dei file e client di terze parti.

Con un solo IP WAN pubblico statico, Override hostname può restare vuoto. Con più indirizzi, impostare il FQDN desiderato o un indirizzo di interfaccia specifico, oppure verificare ogni voce esportata. Dietro NAT a monte, indicare l’endpoint pubblico del router e verificarne il port forwarding; per un indirizzo dinamico, configurare prima Network > DDNS e utilizzare il FQDN DDNS. Controllare le effettive voci gateway in .ovpn e testare separatamente la risoluzione dei nomi.

Nell’assistente, verificare i valori globali, scegliere Next, quindi impostare VPN name, utenti/gruppi e Authentication servers. Le opzioni sono Same as VPN (IPsec, L2TP, PPTP), Same as firewall o Set authentication method for SSL VPN. Selezionare separatamente modalità del tunnel e zone; per Split Tunnel, confermare le risorse con Apply selected items in fondo all’elenco. Scegliere Finish solo dopo la verifica e controllare le regole generate. L’assistente non sostituisce il controllo SNAT né la configurazione separata dell’IdP.

⚠️ L’introduzione della guida Full Tunnel afferma che sono accessibili solo le risorse selezionate nella policy; la guida del campo indica esplicitamente che Permitted network resources non viene applicato con Use as default gateway. Anche una precedente guida diagnostica continua a raccomandare la selezione delle risorse in questa modalità. Questa affermazione contraddittoria non garantisce il controllo degli accessi: utilizzare regole firewall esplicite come controllo per Full Tunnel e testare destinazioni consentite e bloccate. Le ampie regole di esempio con Any non sono obbligatorie; limitare separatamente accesso interno e accesso a internet.

Per configurare il client manualmente, aprire VPN in VPN Portal, scegliere Download for Windows o Download for macOS se necessario e installare il client. Download configuration for Windows, macOS, Linux fornisce .ovpn; importarlo con Import connection e accedere con le credenziali del portale o l’SSO predisposto. L’amministratore può ottenere l’installer anche tramite Remote access VPN > SSL VPN > Download client. Il vecchio client SSL VPN ha raggiunto il fine vita e non è più disponibile nel portale.

Se falliscono solo singoli endpoint, verificare prima accesso a internet e autorizzazioni di sistema operativo, firewall dell’endpoint e antivirus. Durante un tentativo di connessione, usare il filtro BPF port <SSL VPN port number> in Diagnostics > Packet capture; Details in Sophos Connect mostra i parametri di connessione. L’assenza di pacchetti non dimostra un blocco dell’ISP. Escludere prima altre cause; passare a una combinazione porta/protocollo consentita solo dopo aver verificato conflitti WAF/portale e preparato distribuzione dei profili e rollback. Il problema documentato di compressione Android/OpenVPN riguarda SFOS 20.0 GA e precedenti, non SFOS 22/23 in generale.

Con il tunnel stabilito, verificare nella tabella di routing dell’endpoint rete di destinazione, interfaccia TUN e indirizzo assegnato. Se manca la rotta, riconnettersi prima e controllare log del client e autorizzazioni dell’endpoint; reimportare aiuta solo con la configurazione attuale appropriata. In Log viewer > Firewall, filtrare per In interface, Is, tun e verificare l’ID Firewall rule. Per regole specifiche per utente, verificare anche Match known users e User or groups. Per distinguere problemi VPN da problemi di rete interna, testare la raggiungibilità dal firewall alla destinazione in Diagnostics > Tools; rimuovere poi eventuali autorizzazioni temporanee al ping. In caso di riconnessioni, verificare anche modifiche ad assegnazione indirizzi, DNS/WINS e dominio, e non utilizzare interfacce WAN come Permitted network resources. Le modifiche alle policy non terminano automaticamente i tunnel esistenti: gli utenti devono disconnettersi e riconnettersi separatamente.

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 dovrebbe 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. Se il servizio mostra UNREGISTERED, verificare che esista almeno una policy SSL VPN. 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. Per questa eccezione diagnostica, usare 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.