Configurare e testare L2TP Remote Access su Sophos Firewall

L2TP Remote Access è ancora disponibile su Sophos Firewall, ma non dovrebbe essere automaticamente la prima scelta per nuovi endpoint gestiti. Sophos Connect con IPsec o SSL VPN è più semplice da gestire centralmente e offre il percorso client Sophos più completo. L2TP resta utile quando un sistema operativo deve utilizzare il proprio client VPN nativo o quando occorre mantenere in modo controllato un ambiente compatibile esistente.

Valutazione per i nuovi ambienti: Le pagine della guida di SFOS 22 e 23 messe a confronto indicano L2TP come tipo di accesso remoto configurabile. Ciò attesta le funzionalità documentate, non la disponibilità in ogni build né una garanzia per le future versioni principali. Avanet non consiglia L2TP come nuovo standard per i client gestiti. Non si dovrebbe implementare un nuovo accesso L2TP senza un requisito concreto legato a sistemi legacy o alla compatibilità.

L2TP da solo definisce il tunnel, non la sicurezza necessaria. Su Sophos Firewall la connessione è protetta da una policy IPsec. Il profilo IPsec, l’autenticazione, la preshared key o il certificato e la configurazione del client devono quindi corrispondere. Uno stato Active verde indica inoltre soltanto che la policy è attiva; solo lo stato Connection e il traffico reale confermano il tunnel.

⚠️ La Route Precedence richiesta da Sophos per L2TP colloca globalmente vpn prima di Static e SD-WAN Policy Routes. Anche una nuova policy L2TP con peer wildcard può influire sulle preshared key esistenti. Prima della modifica occorre documentare l’ordine attuale, un accesso di gestione indipendente e tutti gli altri percorsi VPN, Static e SD-WAN.

L2TP in otto passaggi

1. Verificare che L2TP sia realmente necessario e che client, profilo IPsec e autenticazione siano compatibili.
2. Pianificare un intervallo lease privato senza sovrapposizioni, server DNS interni e un gruppo utenti ristretto.
3. In Remote access VPN > L2TP > L2TP global settings, attivare L2TP e aggiungere gli utenti.
4. Creare una policy L2TP con profilo IPsec, porta WAN, autenticazione e NAT Traversal corrispondenti.
5. In Administration > Device access, consentire il servizio IPsec per la raggiungibilità WAN necessaria.
6. Salvare la Route Precedence attuale e portare vpn al primo posto con una modifica controllata.
7. Creare una regola firewall ristretta e con logging dalla zona VPN verso le destinazioni interne effettivamente necessarie.
8. Con un client pilota esterno, verificare autenticazione, indirizzo lease, DNS, regola, percorso di ritorno e test negativo.

Quando L2TP è adatto

L2TP può essere utile per client nativi del sistema operativo o dispositivi esistenti sui quali non è previsto Sophos Connect. È una scelta comprensibile anche quando occorre continuare a gestire un piccolo ambiente L2TP già documentato senza software client aggiuntivo.

Per un nuovo rollout standard è generalmente più adatto Sophos Connect con IPsec o SSL VPN. La distribuzione dei profili, la diagnostica del client e il percorso di supporto specifico di Sophos sono più chiari. Per singole applicazioni, Clientless SSL VPN può fornire accesso tramite browser senza un tunnel di rete completo. PPTP non è un’alternativa moderna: il protocollo non definisce di per sé né cifratura né autenticazione; la possibilità di selezionare metodi di accesso non lo rende un’architettura sicura per nuove implementazioni.

Prima della configurazione devono essere chiari tre limiti:

• Su Sophos Firewall, L2TP utilizza un unico pool di indirizzi globale condiviso e impostazioni DNS comuni per tutte le policy L2TP.
• I gruppi importati da Active Directory o Microsoft Entra ID non vengono abilitati automaticamente per L2TP. Devono essere aggiunti esplicitamente con Add members.
• L2TP e PPTP considerano soltanto il Main Group rilevante nella valutazione delle appartenenze. Un’appartenenza aggiuntiva non dimostra quindi da sola l’autorizzazione. Gestire correttamente gruppi utenti e Main Group spiega il contesto.

Esempio e preparazione

L’esempio collega un client esterno a una rete applicativa interna. I valori sono intenzionalmente dati di documentazione e devono essere adattati all’ambiente reale:

• pool L2TP: da 10.250.30.10 a 10.250.30.100 all’interno di 10.250.30.0/24
• server DNS interno: 10.10.10.10
• gruppo consentito: L2TP_Users
• nome policy: L2TP_Remote_Access
• profilo IPsec: DefaultL2TP come punto di partenza per il test di compatibilità
• rete di destinazione interna: 10.10.10.0/24
• servizio di esempio: HTTPS

L’intervallo 10.250.30.0/24 è solo una rete privata di esempio. Non deve sovrapporsi a reti LAN, VLAN, Site-to-Site o domestiche, né agli intervalli lease usati da Remote Access IPsec, SSL VPN o PPTP. Sophos consente al massimo 254 indirizzi per Assign IP from, all’interno di una subnet /24 o più piccola.

Prima di iniziare, verificare inoltre quanto segue:

• Un profilo IPsec adatto corrisponde alle impostazioni supportate dal client nativo.
• L’indirizzo pubblico o il FQDN della porta WAN selezionata è raggiungibile dal client.
• Ora di sistema, DNS e catena dei certificati sono corretti se si utilizza un certificato.
• L’utente o il gruppo esiste e il metodo di autenticazione corretto è inserito in Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• L’output attuale di system route_precedence show e un comando di rollback corrispondente sono documentati.
• WebAdmin o la console rimane raggiungibile tramite un percorso di gestione indipendente.

L’origine di autenticazione e il client devono supportare lo stesso metodo: SFOS elenca PAP, CHAP o MSCHAPv2 per Local e RADIUS, solo PAP per Active Directory e LDAP, e PAP o CHAP per TACACS+. Prima del rollout, verificare il metodo comune con il client nativo. La protezione IPsec esterna rimane obbligatoria per L2TP; questa matrice di compatibilità non è una raccomandazione per PPTP né per l’uso di PAP non protetto.

Limiti di versione e client

Questa guida è concepita per SFOS 22.0 MR2 Build 546 e per l’interfaccia descritta nella guida online 22.0. L2TP è disponibile in questa versione. Il controllo di upgrade a SFOS 22 di Avanet raccoglie i blocchi correnti e i percorsi supportati; prima di ogni migrazione, confrontare lì lo specifico build sorgente con quello di destinazione. Non esiste una matrice di compatibilità completa per i client L2TP nativi. La guida 22.0 cita soltanto Windows 10 come esempio client concreto. Ciò non dimostra la compatibilità di altre versioni, attuali o successive, dei sistemi operativi.

Le pagine complete della guida L2TP per SFOS 22 e 23 descrivono le stesse impostazioni globali, gli stessi campi delle policy e gli stessi passaggi di configurazione. L’esempio per SFOS 22 non va applicato a SFOS 23 senza chiarire le differenze per la build e il client di destinazione. Anche la matrice delle piattaforme per Sophos Connect, IPsec e SSL VPN nelle FAQ sull’accesso remoto non è una matrice di compatibilità L2TP; per una migrazione, seguire il confronto dei client collegato sopra e la rispettiva procedura IPsec o SSL VPN.

Ogni versione di OS realmente utilizzata va quindi testata separatamente con il profilo IPsec, il server di autenticazione e il tipo di ID previsti. Il massimo di 254 indirizzi del pool è soltanto un limite di indirizzamento, non la garanzia di altrettante sessioni simultanee. La guida pubblica 22.0 non indica un limite generale per le sessioni L2TP. Capacità e stabilità devono essere verificate sul modello di firewall effettivo con il numero previsto di sessioni simultanee.

La guida attuale descrive i valori selezionabili, ma non identifica un valore predefinito universale per Gateway type, Authentication type, Allow NAT traversal o Disconnect when tunnel is idle nelle configurazioni esistenti o migrate. Registrare questi campi prima e dopo un upgrade invece di ricostruirli da un valore presunto.

Configurare e verificare il client Windows nativo

In Windows creare la connessione in Impostazioni > Rete e Internet > VPN > Aggiungi VPN. Selezionare Windows (predefinito) come provider VPN, inserire il FQDN pubblico o l’indirizzo WAN del firewall come Nome o indirizzo server e scegliere come tipo VPN L2TP/IPsec con chiave già condivisa oppure l’opzione certificato corrispondente al profilo del firewall. La chiave condivisa deve coincidere con il PSK della policy L2TP. Come credenziali usare nome utente e password di un account autorizzato in Add members; documentare insieme tipo VPN, metodo di accesso, ID e versione del client.

Eseguire il primo test da una rete esterna. Dopo la connessione usare ipconfig /all per verificare l’indirizzo del pool L2TP e i server DNS previsti, quindi provare la risoluzione dei nomi interni e l’accesso HTTPS consentito. Se non si stabilisce il tunnel, confrontare prima nome server, modalità PSK o certificato, metodo di accesso e profilo IPsec concordato, quindi correlare il timestamp con l2tpd.log e i log IPsec. Ogni versione Windows in uso rimane una combinazione client da verificare separatamente.

Configurare le impostazioni globali L2TP

In Remote access VPN > L2TP > L2TP global settings, attivare Enable L2TP. Per Assign IP from, nell’esempio inserire da 10.250.30.10 a 10.250.30.100. Selezionare 10.10.10.10 come Primary DNS server se questo server è in grado di risolvere i nomi interni. DNS è un campo facoltativo: selezionare il server dall’elenco oppure inserirne l’indirizzo tramite Other. Configurare Secondary DNS server, Primary WINS server e Secondary WINS server soltanto se sono effettivamente necessari nell’ambiente; WINS non sostituisce DNS.

L’opzione Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client è utile solo se il server RADIUS fornisce in modo affidabile un indirizzo adatto. Se non restituisce alcun indirizzo, il firewall utilizza prima un indirizzo statico configurato per l’utente e, se questo manca, il pool globale. L’assegnazione RADIUS e il percorso di fallback devono quindi essere pianificati entrambi senza sovrapposizioni. Configurare RADIUS su Sophos Firewall spiega la configurazione del server.

Selezionare quindi il gruppo L2TP_Users tramite Add members, confermare con Add e verificarlo con Show members. Per un utente di directory, il solo import corretto del gruppo non è sufficiente. Un utente pilota deve appartenere realmente al gruppo autorizzato e tale gruppo deve essere quello principale utilizzato nella valutazione L2TP.

Dopo aver modificato impostazioni globali e membri, fare clic su Apply. Ricontrollare i valori globali salvati e Show members. L’azione Save della policy L2TP è un passaggio distinto.

Limiti dell’automazione tramite API XML

I passaggi nell’interfaccia non costituiscono una richiesta API XML pronta all’uso. Le pagine dell’API confrontate per SFOS 22 e 23 separano, sotto L2TPConfiguration, i valori globali in L2TPSettings dai membri in L2TPMembers con UserName. A differenza dell’interfaccia, la tabella indica PrimaryDNSServer come campo obbligatorio contenente un indirizzo IPv4. Il fatto che il campo DNS nell’interfaccia sia facoltativo non dimostra quindi che questo parametro dell’API possa essere omesso. L2TPGeneralSettings e LeaseIPFromRadiusServer sono elencati come facoltativi, con Disable come valore predefinito documentato; ciò non stabilisce un comportamento verificato in caso di omissione. Prima di automatizzare, chiarire il contratto dell’API del build installato senza ipotizzare una codifica DNS vuota. Quindi rileggere i valori globali previsti e le appartenenze; la procedura nell’interfaccia e il meccanismo di fallback RADIUS descritti sopra rimangono separati.

Per la policy salvata descritta di seguito, l’esempio dell’API mostra L2TPConnection con Configuration; accanto compaiono i rami di controllo Connection, DisConnection, Active e DeActive, ciascuno con Name. Salvataggio, connessione, disconnessione e attivazione non corrispondono quindi alla stessa identità o azione. Le icone dell’interfaccia non attestano una richiesta API eseguibile. Inoltre, l’esempio e la tabella dei campi si contraddicono: RemoteHost contiene un nome host o un indirizzo IP nell’esempio, mentre la tabella consente IPv4 o *; AliasLocalWANPort rappresenta soltanto un alias WAN nell’esempio, ma è obbligatorio nella tabella. Per DisconnectOnIdleInterval, la tabella indica un valore predefinito di 0, ma anche un intervallo da 120 a 999; 600 è soltanto il valore dell’esempio. Non dedurne né un significato per zero né valori sostitutivi sicuri. Prima di apportare modifiche tramite API, chiarire questi punti per il build specifico e verificare l’accesso di gestione indipendente e gli effetti sui PSK condivisi delle policy wildcard, come descritto sopra.

Anche durante la successiva dismissione, occorre distinguere l’eliminazione di una connessione salvata dalla sua disattivazione e dalla disabilitazione globale di L2TP. Innanzitutto inventariare la configurazione esistente, disattivare la connessione prevista e verificare le dipendenze. Delete L2TP Connection richiede l’esatto Name salvato (prima lettera A-Za-z, poi A-Za-z0-9_, al massimo 50 caratteri); la pagina non fornisce alcun esempio di richiesta. Le associazioni di stato 200/L2TPDeleteSuccess, 203/L2TPConnInUse e 500/L2TPDeleteFail rimandano a identificatori Message non risolti, non a testi di messaggio confermati o a una classificazione HTTP. In particolare, non considerare 203 un generico esito positivo di eliminazione della classe 2xx. Una volta chiarita la richiesta di eliminazione, ricontrollare il nome esatto della destinazione e confermare che gli accessi di produzione ancora necessari siano preservati; non ipotizzare un involucro della richiesta di eliminazione né una successiva pulizia automatica.

Indirizzo statico dell’utente e dipendenze PPTP esistenti

I campi lease specifici dell’utente si trovano in Authentication > Users > [Utente], nella sezione delle impostazioni di accesso remoto. L2TP consente l’accesso L2TP e permette di inserire un indirizzo IP da assegnare in lease all’utente remoto. PPTP dispone di un interruttore separato e di un proprio campo per l’indirizzo IP da assegnare in lease. Si tratta di due impostazioni distinte dell’account, non del pool globale né di un’assegnazione IP per SSL VPN. Per gestire l’utente locale e la sua password, seguire Creare utenti locali su Sophos Firewall. Pianificare un indirizzo univoco e privo di conflitti solo per un accesso esistente giustificato, salvarlo con Save e, alla successiva connessione da una rete esterna, verificare l’indirizzo effettivamente assegnato e il percorso di ritorno. Con il leasing RADIUS, l’indirizzo dell’utente rimane il fallback descritto sopra quando RADIUS non fornisce un indirizzo; un interruttore dell’account non sostituisce né l’autorizzazione tramite Add members né la regola firewall.

Primo accesso prima del tunnel: La guida all’aggiunta degli utenti per SFOS 22 e 23 richiede che, dopo l’attivazione di L2TP o PPTP, i membri della policy accedano prima al VPN portal e creino una password prima di connettersi. Verificare questa procedura iniziale documentata con un account pilota per il build e il server di autenticazione utilizzati. Non reimpostare le password esistenti sulla base di supposizioni e non sostituire indiscriminatamente un’autenticazione di directory funzionante con password locali. La raggiungibilità del portale e VPN portal authentication methods devono essere verificate separatamente dal metodo del tunnel; a questo scopo non è necessario aprire WebAdmin dalla WAN.

Per inventariare un accesso PPTP già esistente, in Remote access VPN > PPTP sono disponibili Enable PPTP, Assign IP from, l’opzione condivisa di leasing RADIUS, il server DNS primario e i server DNS secondario e WINS facoltativi. Il lease è valido per la durata della connessione; l’intervallo privato si trova in una subnet /24 o più piccola e contiene al massimo 254 indirizzi. Non deve sovrapporsi agli intervalli di Remote Access IPsec e SSL VPN. La guida descrive Apply per i valori globali e Add members e Show members per l’autorizzazione degli utenti; anche in questo caso, l’import di un gruppo AD o Entra ID non abilita automaticamente l’accesso. Questi campi vengono rilevati esclusivamente dalla configurazione esistente ai fini della migrazione e della risoluzione dei problemi, non come raccomandazione ad attivare PPTP. I metodi documentati PAP, CHAP e MS-CHAPv2 non offrono uno standard di sicurezza moderno; la sostituzione va pianificata con IPsec, SSL VPN o accesso a livello applicativo.

Creare la policy L2TP

In Remote access VPN > L2TP, utilizzare Add per creare la policy L2TP_Remote_Access.

Profilo e comportamento all’avvio

In Profile, selezionare il profilo IPsec che corrisponde ai client. Nell’esempio, il profilo esistente DefaultL2TP funge da punto di partenza per il test di compatibilità. Algoritmi e lifetimes devono comunque essere confrontati con i valori supportati dal client; un nome contenente Default non è una garanzia di sicurezza permanente. I due valori di Gateway type hanno conseguenze operative differenti:

• Respond only mantiene la policy pronta dopo un riavvio affinché possa rispondere alle richieste in ingresso.
• Disable la lascia inattiva finché non viene attivata manualmente tramite lo stato Active.

Per un servizio Remote Access produttivo, Respond only è in genere il punto di partenza più comprensibile. La scelta va verificata esplicitamente dopo un riavvio del firewall o del servizio, per non confondere attivazione e stato della connessione.

Autenticazione e preshared key

I valori disponibili per Authentication type sono Preshared key e Digital certificate. Digital certificate autentica gli endpoint tramite lo scambio di certificati firmati localmente o emessi da un’autorità di certificazione. I certificati evitano un PSK condiviso, ma richiedono una catena di attendibilità completamente pianificata e un supporto client adeguato. Un PSK deve essere lungo, casuale, trasmesso separatamente e rinnovato regolarmente in modo controllato.

Sophos utilizza il PSK configurato più di recente per tutte le connessioni con la stessa interfaccia di ascolto e lo stesso peer remoto. Per Remote Access, Remote host è normalmente impostato su *. Una policy wildcard nuova o modificata può quindi sostituire il PSK di configurazioni Remote Access esistenti. Prima di salvare, occorre controllare tutte le policy che utilizzano la stessa porta WAN e lo stesso gateway wildcard.

Con un PSK, definire valori corrispondenti per Local ID e Remote ID. Il tipo di ID DER ASN1DN (X.509) non è accettato con PSK. Gli ID devono corrispondere al client nativo e non vanno impostati su valori arbitrari per comodità.

Porta WAN, peer e selettori

In Local WAN port, selezionare la porta WAN realmente raggiungibile. Per client con indirizzi variabili, impostare Remote host sul valore wildcard *. Attivare Allow NAT traversal quando i client si trovano dietro NAT, condizione normale nelle reti domestiche, mobili e degli hotel.

Per il tipico flusso Remote Access, l’esempio Sophos utilizza Remote subnet: Any, Local port: 1701 e Remote port: *. 1701 è la porta L2TP sul firewall; la porta client può variare. Questi valori sono selettori del tunnel e non sostituiscono una regola firewall. L’accesso successivo rimane limitato a zone, destinazioni e servizi specifici.

Per un peer fisso, Remote host può contenere anche un indirizzo IP o un nome host. Remote subnet descrive le reti remote; verificare il valore rispetto alla configurazione specifica del client. La guida dei campi consente porte TCP/UDP o il valore wildcard * per Local port e Remote port; l’esempio con porta locale 1701 non è una prescrizione generale per ogni configurazione dei selettori. La guida della policy chiama questa sezione QuickHA mode, mentre la procedura di configurazione parla di selettori Quick Mode. Da questa intestazione non va dedotta alcuna funzionalità HA: ciò che conta sono i due campi delle porte e i selettori IPsec concordati.

Con Disconnect when tunnel is idle, il firewall può disconnettere i client inattivi dopo il periodo specificato in Idle session time interval. Il valore va adattato al modello di lavoro reale e testato con pause realistiche. Un intervallo troppo breve genera riconnessioni inutili; senza limite, le sessioni dimenticate possono rimanere attive più a lungo. Idle session time interval è espresso in secondi.

Dopo Save, attivare la policy tramite l’icona rossa nella colonna Active. Il verde sotto Active non indica ancora che un client sia connesso. Lo stato Connection separato mostra se il tunnel è stato effettivamente stabilito; la guida descrive l’azione di connessione tramite la relativa icona di stato. Per un client remoto, resta determinante il suo tentativo di connessione da una rete esterna. Logs nella pagina L2TP apre i log L2TP. Quando Active è disabilitato, la policy è inattiva, indipendentemente da un precedente stato del tunnel.

Con più subnet locali e remote viene creato un tunnel per ogni coppia locale/remota. Connection può mostrare uno stato parziale: la configurazione è attiva, ma almeno un tunnel non è stabilito. Testare separatamente ogni coppia necessaria e il relativo flusso di dati; Active abilitato non conferma tutti i tunnel.

Raggiungibilità, routing e regola firewall

Consentire IPsec sulla WAN

In Administration > Device access, IPsec deve essere consentito per la raggiungibilità WAN necessaria. Questa autorizzazione va applicata nel modo più ristretto permesso dalla topologia. Un PSK robusto o un certificato non giustifica un accesso inutilmente ampio a WebAdmin, User Portal o SSH. Device Access e Local Service ACL spiega la separazione tra raggiungibilità del servizio e autorizzazione dell’utente.

Impostare Route Precedence in modo controllato

L’ordine predefinito documentato da Sophos è Static, SD-WAN Policy Routes, VPN. Per L2TP, invece, le route VPN devono essere valutate per prime; Static e SD-WAN possono seguire in qualsiasi ordine. Accedere alla CLI del firewall e selezionare 4. Device Console. Innanzitutto salvare lo stato iniziale effettivo:

system route_precedence show

Quindi impostare l’ordine L2TP documentato e verificarlo di nuovo:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Questa modifica è globale e non è un interruttore isolato per la nuova policy L2TP. Prima e dopo il cambiamento occorre testare i percorsi Static, SD-WAN e VPN sovrapposti, oltre all’accesso di gestione. Modificare Route Precedence su Sophos Firewall spiega l’effetto e il rollback sicuro.

Consentire l’accesso alle destinazioni interne

In Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, creare una regola con logging e salvarla con Save. Assegnare un Rule name riconoscibile, ad esempio VPN-LAN. L’esempio Sophos che utilizza Any per origine, destinazione e servizio è semplice per una prima verifica funzionale, ma non rappresenta un buon standard di sicurezza permanente. In questo esempio si applicano criteri più restrittivi:

• Source zone: VPN
• Source network: il pool L2TP 10.250.30.0/24 oppure un oggetto IP host corrispondente
• Destination zone: la zona che contiene la rete applicativa
• Destination network: 10.10.10.0/24 o, preferibilmente, i server necessari
• Services: HTTPS oppure soltanto i servizi effettivamente necessari
• Log firewall traffic: attivato

Il traffico internet attraverso il firewall richiede una regola separata da VPN a WAN e un design NAT e di sicurezza consapevole. Questo accesso non viene creato automaticamente solo perché il tunnel L2TP è attivo.

Verificare la connessione

La verifica si esegue da una rete esterna reale. Un test dalla stessa LAN o attraverso un percorso VPN già esistente può nascondere problemi di routing, NAT e raggiungibilità pubblica.

1. Connettersi con un utente pilota autorizzato e la configurazione client documentata.
2. In Remote access VPN > L2TP, verificare separatamente gli stati Active e Connection. Con più subnet locali e remote viene creato un tunnel per ogni coppia locale/remota. Connection può mostrare uno stato parziale: la configurazione è attiva, ma almeno un tunnel non è stabilito. Testare separatamente ogni coppia necessaria e il relativo flusso di dati; Active abilitato non conferma tutti i tunnel.
3. Controllare che il client riceva un indirizzo tra 10.250.30.10 e 10.250.30.100 e i server DNS previsti.
4. Risolvere un nome interno e raggiungere tramite HTTPS una destinazione espressamente consentita.
5. In Log Viewer, verificare la Firewall Rule ID prevista, l’IP sorgente del pool L2TP, la destinazione, il servizio e l’azione.
6. Controllare il percorso di ritorno dalla rete di destinazione al pool L2TP e ripetere lo stesso accesso dopo una nuova connessione.
7. Eseguire un test negativo con un utente non aggiunto, che non deve ottenere un tunnel utilizzabile.
8. Verificare comportamento idle, disconnessione, riconnessione e, in HA, un failover controllato con un nuovo accesso.

Un’autenticazione riuscita non dimostra il percorso dati. Allo stesso modo, un tunnel verde non dimostra che DNS, regola, NAT e percorso di ritorno siano corretti. Testare le regole di Sophos Firewall spiega come distinguere le prove di Log Viewer e Packet Capture.

Risolvere i problemi in modo sistematico

La policy è attiva, ma il tunnel rimane down

Confrontare innanzitutto porta WAN, raggiungibilità pubblica, IPsec in Device Access, NAT Traversal, indirizzo client, PSK o certificato, Local/Remote ID e profilo IPsec. Controllare quindi se una policy wildcard salvata più di recente abbia sostituito il PSK previsto.

Per la prima separazione utilizzare l2tpd.log per L2TP e strongswan.log o charon.log per la negoziazione IPsec. Servizi e file di log di Sophos Firewall fornisce la mappatura completa. Correlare i log con ora esatta, utente, IP pubblico del client e nome della policy; il riavvio di un servizio non è il primo passo diagnostico.

L’accesso non riesce o l’utente non ottiene autorizzazione

In Authentication > Services, controllare il metodo per VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Verificare quindi se utente o gruppo sono elencati in Add members e quale gruppo compare come Main Group nell’oggetto utente. Con RADIUS, verificare separatamente anche autenticazione e assegnazione lease opzionale.

Il tunnel è up, ma le destinazioni interne non sono raggiungibili

Controllare nell’ordine indirizzo lease, Route Precedence, Firewall Rule ID, route di destinazione e percorso di ritorno. Una route SD-WAN ampia o una Static Route concorrente può modificare il percorso. Il pool L2TP deve essere raggiungibile dalla rete interna senza che una seconda route identica o una rete sovrapposta prenda il controllo del ritorno.

Se Log Viewer mostra Rule 0, una Rule ID imprevista o nessuna voce corrispondente, identificare la regola effettiva prima di ampliare qualsiasi cosa a Any. Se il pacchetto in uscita è visibile ma non torna alcuna risposta, proseguire sul sistema di destinazione, il suo gateway, firewall locale o route di ritorno.

La connessione è lenta o instabile

Controllare latenza, packet loss, MTU o frammentazione, cambi WAN e utilizzo CPU durante un test riproducibile. Un singolo trasferimento SMB non è un test pulito del throughput VPN. Più flussi TCP controllati in entrambe le direzioni aiutano a distinguere tunnel, trasporto e applicazione.

Se sono instabili solo le connessioni L2TP, confrontare i timestamp di l2tpd.log, dei log IPsec, degli eventi WAN e del log client. Modificare profilo, MTU o idle time singolarmente e in una finestra di manutenzione soltanto dopo aver dimostrato una relazione concreta.

Non trasferire le regole L2TP quando si passa a Sophos Connect

Le FAQ sull’accesso remoto trattano IPsec e SSL VPN, non un’ulteriore abilitazione dei client L2TP. La tabella delle piattaforme indica per Windows .pro o .scx per IPsec e .pro o .ovpn per SSL VPN; indica gli stessi tipi di file per macOS con Sophos Connect dalla versione 2.1. macOS con Connect 2.0 utilizza rispettivamente .scx e .ovpn; prima della versione 2.0, IPsec continua a utilizzare Sophos Connect con .scx, mentre SSL VPN utilizza un client di terze parti con .ovpn. Android utilizza client di terze parti con .tgb per IPsec o .ovpn per SSL VPN; per IPsec, iOS non richiede un client aggiuntivo e scarica la configurazione dal VPN portal, mentre per SSL VPN richiede un client di terze parti con .ovpn. Verificare la specifica combinazione attuale di client e sistema operativo prima della sostituzione. Verificare la cifratura per IPsec in Remote access VPN > IPsec > IPsec profiles > Encryption algorithm e per SSL VPN in Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings. L’affermazione generale delle FAQ sulla connessione di accesso remoto cifrata non deve essere estesa a PPTP in assenza di una protezione specifica del protocollo.

Nel provisioning di Sophos Connect, i gateway in .pro servono solo a recuperare la configurazione dal portale, non a scegliere il tunnel: IPsec utilizza l’interfaccia configurata, mentre SSL VPN utilizza le interfacce indicate in .ovpn, presenti in Network > Interfaces e autorizzate tramite Local Service ACL. Override hostname imposta l’indirizzo pubblico desiderato per SSL VPN; se il firewall si trova dietro un router, inserire il FQDN pubblico o l’IP WAN del router in .pro, configurare sul router un inoltro DNAT adeguato e, per IPsec, inserire il suo IP WAN come gateway in .scx. Il certificato privato predefinito per WebAdmin e VPN Portal può causare un errore di attendibilità durante il provisioning; correggere la catena dei certificati, non disabilitare la verifica. La configurazione del firewall per Sophos Connect e la procedura SSL VPN sostituiscono qui la configurazione L2TP.

Per le modifiche IPsec, le FAQ richiedono Edit connection > Update policy e un nuovo recupero della configurazione dal portale; per SSL VPN, gli aggiornamenti manuali riguardano in particolare porta, protocollo, gateway e certificato del server SSL. .pro recupera automaticamente alcune modifiche SSL VPN; un nuovo import può recuperare nuovamente entrambe le configurazioni. Per distinguere un aggiornamento del profilo da un errore di download, seguire Scaricare nuovamente il profilo SSL VPN. Sophos Connect utilizza i gateway SSL VPN di .ovpn in ordine di priorità inverso, non necessariamente nell’ordine di .pro. SSL VPN distribuisce il pool tra istanze dipendenti dalla CPU, ciascuna con proprie subnet tun0: intervalli più piccoli di /24 riducono la capacità di assegnazione dei lease; con /27 e otto istanze, le FAQ indicano un solo indirizzo rimasto disponibile per il lease. Questo non è un limite del pool L2TP. L’indisponibilità dei download .ovpn può anche essere legata a ID utente superiori al limite condiviso di 65535 per gli ID di utenti e gruppi; Verificare in sicurezza il limite degli ID utente descrive una pulizia controllata anziché eliminazioni indiscriminate.

Pianificare MFA per la soluzione sostitutiva in Authentication > Multi-factor authentication, con le opzioni necessarie User portal, SSL VPN remote access e IPsec remote access. Per IPsec, il campo OTP separato richiede Prompt users for 2FA token e Apply, oppure otp: true e 2fa: 1 nel provisioning. Sophos Connect invia password e OTP combinati come passwordotp e, secondo le FAQ, non supporta un flusso OTP con challenge; sono supportati i metodi tramite chiamata o push e, per WebAdmin, anche MFA con challenge. Verificare questa differenza nel progetto pilota di provisioning, senza estenderla a un client L2TP nativo. Le FAQ limitano inoltre Remote Access IPsec a una sola interfaccia WAN; da ciò non si deduce né lo stesso limite per L2TP né una garanzia multi-WAN per la soluzione sostitutiva.

Migrare a SFOS 22

La migrazione del firmware va pianificata separatamente da una modifica della configurazione L2TP. Prima dell’upgrade, inventariare firmware e piattaforma esatti, impostazioni L2TP globali, utenti e Main Group consentiti, ogni policy L2TP con profilo, ID e autenticazione, Device Access, Route Precedence e le regole firewall e NAT associate. Preparare inoltre un backup cifrato e un percorso di gestione indipendente. Usare il controllo di upgrade a SFOS 22 per confrontare lo specifico build sorgente con la tabella di upgrade corrente; l’affermazione generale secondo cui le configurazioni possono migrare a 22.0 GA non sostituisce questo controllo del percorso.

L2TP non va confuso con Remote Access IPsec (legacy): L2TP rimane disponibile in SFOS 22.0 MR2, mentre la variante IPsec legacy è stata ritirata in 22.0 MR1. Un firewall che contiene tale configurazione legacy non può essere aggiornato a 22.0 MR1 o versioni successive. Inoltre, SFOS 22.0 GA e versioni successive non supportano appliance hardware XG o SG. La piattaforma e i tipi di accesso remoto esistenti sono quindi vere condizioni di blocco, non semplici elementi dell’inventario.

SFOS 22.0 MR1 Build 490 ha corretto NC-162171, per cui NAS-Identifier non veniva inserito nelle connessioni L2TP con MS-CHAPv2 o MS-CHAP. Se le regole RADIUS dipendono da NAS-Identifier e il firewall proviene da un build precedente, dopo l’upgrade verificare non solo l’accesso, ma anche la richiesta RADIUS ricevuta e la policy RADIUS effettivamente applicata. La correzione non dimostra la compatibilità automatica di ogni combinazione di client e autenticazione.

Dopo il riavvio, confrontare la versione firmware e tutti i campi inventariati. Eseguire poi la verifica completa da una rete esterna, inclusi test negativo, DNS, percorso dati, comportamento idle e un nuovo accesso dopo un failover HA. Mantenere disponibile il vecchio metodo di accesso come fallback controllato finché i controlli non sono superati.

Il rollback del firmware non consiste soltanto nel disattivare L2TP. Firmware attivo e precedente risiedono in partizioni separate insieme ai rispettivi stati di configurazione. Avviando il firmware precedente diventa quindi attivo anche il suo stato di configurazione precedente, perciò le modifiche apportate dopo l’upgrade non fanno parte della configurazione in esecuzione dopo il rollback. Prima di procedere, salvare separatamente le modifiche successive necessarie, verificare la versione di destinazione supportata e confermare la finestra di manutenzione per il riavvio.

Eseguire un rollback sicuro della configurazione L2TP

Il rollback consiste nel riportare soltanto gli stati modificati durante questa procedura alla situazione iniziale documentata, non nello smantellare un ambiente L2TP esistente. Prima della prima modifica, registrare quindi i valori globali L2TP, incluso Enable L2TP, lo stato Active di ogni policy interessata, l’elenco completo in Add members, le autorizzazioni degli utenti, le regole firewall e l’autorizzazione IPsec in Administration > Device access; annotare separatamente gli elementi nuovi e le modifiche alla configurazione esistente. Se mancano i valori iniziali o un metodo confermato per il ripristino esatto sul build installato, non eseguire la modifica interessata; chiarire prima questi aspetti con Sophos Support. Un valore predefinito documentato non sostituisce un valore iniziale rilevato.

Durante il rollback, mantenere aperto l’accesso di gestione indipendente. Per prima cosa, se la Route Precedence è stata modificata durante questa procedura, ripristinare esattamente l’ordine salvato in precedenza, rileggere il valore con system route_precedence show e verificare i percorsi di gestione, Static, SD-WAN e VPN. Se l’ordine non era stato modificato, mantenerlo invariato.

In una configurazione esistente, ripristinare esattamente soltanto i valori, gli stati delle policy, le appartenenze e le autorizzazioni modificati. Le policy, i membri, le regole e le autorizzazioni già presenti devono essere mantenuti nel loro stato originale; se Enable L2TP era già attivato, deve rimanere attivato. Annullare una singola modifica della Device Console non giustifica la rimozione di questi accessi né la disattivazione globale di L2TP.

La dismissione di un’implementazione creata interamente durante questa procedura è un’operazione distinta: prima di ogni disattivazione o rimozione, verificare le dipendenze e confermare che non sia interessato alcun accesso di produzione ancora necessario. Solo allora disattivare la policy L2TP appena creata e controllarne gli effetti con un client pilota. Successivamente, revocare esclusivamente le regole firewall e le autorizzazioni IPsec appena create e non più necessarie, e rimuovere da Add members soltanto i membri aggiunti durante questa procedura. Disattivare Enable L2TP solo se era disattivato prima di questa procedura e non esistono dipendenze ancora necessarie. Gli elementi condivisi esistenti non devono essere eliminati come parte della pulizia.

Dopo il rollback, confrontare i valori globali salvati, Show members, lo stato delle policy, le autorizzazioni degli utenti, le regole e Device Access con la situazione iniziale documentata. Con un client pilota esterno, confermare che gli accessi di produzione precedentemente necessari continuino a funzionare e che le autorizzazioni di test revocate non consentano più l’accesso. La preshared key non va reimpostata alla cieca su un valore precedente; tutte le policy con la stessa porta WAN e lo stesso gateway wildcard devono essere verificate insieme.

FAQ