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: La guida attuale di SFOS 22 continua a documentare L2TP come tipo di accesso remoto configurabile. Sophos non ha pubblicato alcun avviso di ritiro per questa funzione. Ciò non garantisce tuttavia il supporto in una futura versione principale. Avanet non consiglia L2TP come nuovo standard per i client gestiti. Non si dovrebbe implementare un nuovo accesso L2TP senza una necessità concreta di compatibilità o di continuità di un ambiente esistente.

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. PPTP non è un’alternativa moderna: il protocollo non definisce di per sé la cifratura e non dovrebbe più essere pianificato per nuovi accessi remoti.

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.

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 la concorrenza prevista.

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. Configurare DNS secondario e WINS soltanto se l’ambiente ne ha effettivamente bisogno.

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

Aggiungere quindi il gruppo L2TP_Users tramite Add members 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 il Main Group usato 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.

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

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.

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 e poi VPN. Per L2TP, le route VPN devono invece essere valutate per prime; Static e SD-WAN possono seguire in qualsiasi ordine. Innanzitutto salvare lo stato iniziale effettivo nella Device Console:

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, creare una regola IPv4 con logging. L’esempio Sophos che utilizza Any per origine, destinazione e servizio è semplice per un primo test funzionale, ma non rappresenta un buon standard di sicurezza permanente. Questo esempio è più ristretto:

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

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

Durante il rollback mantenere aperto l’accesso di gestione indipendente. Ripristinare prima l’esatta Route Precedence salvata e testare i percorsi di gestione, Static, SD-WAN e VPN. Disattivare poi la policy L2TP e confermare con un client pilota che non restino dipendenze produttive.

Rimuovere quindi le regole firewall e l’autorizzazione IPsec se nessun altro servizio ne dipende. Solo dopo rimuovere gli utenti da Add members e disattivare Enable L2TP. 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 controllate insieme.

FAQ