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.

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.

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.

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.

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

Sophos richiede che per L2TP le route VPN siano valutate prima di Static e SD-WAN Policy Routes. Innanzitutto salvare lo stato iniziale 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.
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.

Eseguire un rollback sicuro

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