Configurare VPN IPsec Site-to-Site Sophos Firewall

Una VPN IPsec Site-to-Site collega due sedi, oppure una Sophos Firewall con un firewall di terze parti, tramite un tunnel cifrato. Nella pratica, un tunnel di questo tipo raramente fallisce per una singola opzione nell’interfaccia. Più spesso le cause sono reti poco chiare, profili IPsec diversi, regole firewall mancanti, casi particolari di NAT o un percorso di ritorno dimenticato su un lato.

Questo articolo spiega come creare in modo pulito un tunnel IPsec Site-to-Site su Sophos Firewall. Il focus è su pianificazione, implementazione e test di accettazione. Se un tunnel esistente è già verde ma non passa traffico, Sophos Firewall IPsec VPN Troubleshooting è l’articolo successivo più adatto.

Quando questo articolo è adatto

Questo articolo è adatto a collegamenti classici tra sedi, ad esempio:

• Sede principale verso filiale
• Sophos Firewall verso Sophos Firewall
• Sophos Firewall verso firewall di terze parti
• Sophos Firewall verso cloud gateway quando non viene usato un assistente cloud specifico
• Migrazione da vecchi tunnel policy-based semplici a una configurazione attuale documentata

Per Microsoft Azure o AWS ci sono anche articoli dedicati che trattano le insidie specifiche del provider: Collegare Sophos Firewall ad Azure VPN Gateway e Collegare Sophos Firewall ad AWS Site-to-Site VPN.

Non riguarda il Remote Access per singoli utenti. Per questo sono adatti gli articoli Configurare Sophos Connect su Sophos Firewall, Sophos Connect o SSL VPN: quale soluzione Remote Access è adatta? e Migrare il Remote Access IPsec legacy prima di SFOS 22 MR1.

IPsec policy-based o route-based

Prima della configurazione bisogna decidere se creare il tunnel come policy-based o route-based. Nelle versioni SFOS attuali questi termini sono separati in modo più chiaro rispetto alle guide più vecchie, che in parte parlano ancora di Site-to-Site o Tunnel Interface.

• IPsec policy-based: adatto a collegamenti semplici tra sedi con reti locali e remote chiare. Controllato principalmente tramite subnet locali e remote nella connessione IPsec e tramite regole firewall. Sophos crea singoli tunnel Phase 2 per le combinazioni di subnet locali e remote.
• IPsec route-based con traffic selectors: utilizza anch’esso subnet locali e remote, ma crea una propria interfaccia XFRM per la connessione. Questo facilita il debug e separa meglio il tunnel dalle altre connessioni IPsec.
• IPsec route-based Any-to-Any: la variante più flessibile per reti in crescita, SD-WAN, routing dinamico e design dual-stack. Route e regole firewall decidono quindi quali pacchetti entrano nel tunnel, non più le subnet della connessione IPsec.

Per collegamenti piccoli e stabili, il policy-based IPsec è spesso il più rapido da comprendere. Per reti di sedi più grandi o dinamiche, il route-based IPsec è di solito più pulito, perché routing e negoziazione VPN sono meglio separati. Se sono coinvolte più reti, SD-WAN, BGP, OSPF o reti cloud, il route-based IPsec dovrebbe essere valutato per primo.

Requisiti

Prima della configurazione dovrebbero essere documentate queste informazioni:

• Local gateway: IP WAN o FQDN della Sophos Firewall locale.
• Remote gateway: IP pubblico o FQDN della controparte.
• Reti locali: 172.16.10.0/24, 172.16.20.0/24.
• Reti remote: 10.20.30.0/24.
• Tipo VPN: policy-based o route-based. Esiste anche il connection type Host-to-host, ma non è il focus di questa guida per sedi.
• Listening interface: interfaccia WAN del firewall locale. Una bridge interface non può essere utilizzata per questo.
• Versione IKE: IKEv2, se la controparte lo supporta.
• Autenticazione: Preshared Key o certificato.
• Profilo IPsec: Encryption, authentication, DH group, PFS, key lifetime.
• Regole firewall: sorgenti, destinazioni e servizi consentiti.
• NAT: nessun NAT, SNAT/DNAT per reti sovrapposte o requisito del provider.
• Esercizio: owner, finestra di manutenzione, piano di test, monitoring, percorso di fallback.
• Gateway type: initiate connection o respond only, a seconda del lato che apre il tunnel.
• IP version: IPv4, IPv6 o Dual se entrambe le parti lo supportano esplicitamente.
• Local ID e Remote ID: necessari se l’autenticazione non deve dipendere solo dall’indirizzo IP pubblico.

⚠️ Una VPN Site-to-Site non dovrebbe essere implementata senza un percorso di ritorno documentato. Se il firewall locale invia traffico nel tunnel ma la controparte non conosce la route di ritorno o si aspetta NAT in modo diverso, il tunnel spesso sembra sano anche se le applicazioni non funzionano.

Pianificare prima della configurazione

Mantenere le reti univoche

Le reti locali e remote non devono sovrapporsi involontariamente. Sono particolarmente problematiche le reti standard comuni come 192.168.0.0/24, 192.168.1.0/24 o reti di filiale riutilizzate più volte. Se le reti si sovrappongono, serve un design NAT consapevole. Usare semplicemente lo stesso intervallo di indirizzi su entrambi i lati e tradurlo poi “in qualche modo” crea tunnel difficili da mantenere.

Per nuove sedi conviene quindi un concetto di indirizzamento IP pulito. Se VLAN o zone non sono ancora modellate correttamente, aiuta configurare zone e interfacce Sophos Firewall.

Allineare il profilo IPsec

Entrambi i lati devono usare parametri compatibili per Phase 1 e Phase 2. Questi includono cifratura, autenticazione, DH group, PFS e durata. Per connessioni verso firewall di terze parti spesso è più semplice fissare prima per iscritto un profilo comune e poi configurare entrambi i lati.

Se un tunnel non si attiva, NO_PROPOSAL_CHOSEN, errori ID o errori di autenticazione sono indicazioni tipiche. L’analisi strutturata è in Sophos Firewall IPsec VPN Troubleshooting.

Non dimenticare le regole firewall

Un tunnel IPsec non consente ancora l’accesso produttivo. Il traffico attraverso il tunnel richiede comunque regole firewall adeguate. Per connessioni policy-based sono di solito regole tra LAN e VPN o tra zone proprie. Nei design route-based l’interfaccia XFRM appartiene alla zona VPN; route e regole firewall decidono poi quale traffico può davvero attraversare il tunnel.

Durante l’introduzione, Log firewall traffic dovrebbe essere attivato nelle regole interessate. Altrimenti manca in seguito proprio l’informazione su quale regola ha consentito o bloccato un test. Il flusso generale di verifica è in testare una regola firewall con Log Viewer, Policy Test e Packet Capture.

Controllare consapevolmente le regole create automaticamente

Durante la creazione di una connessione IPsec Site-to-Site, l’opzione Create firewall rule può aiutare a creare un primo set di regole. Non sostituisce però una verifica di sicurezza. Sophos Firewall crea queste regole in cima alla lista delle regole firewall. Nelle versioni SFOS attuali vengono create regole separate per traffico in ingresso e in uscita con i prefissi Incoming e Outgoing.

Per l’esercizio è quindi importante:

• Posizione regola: Spostare le regole create automaticamente nella posizione corretta dopo il salvataggio.
• Direzione: Verificare separatamente regola in ingresso e in uscita, non solo il nome del tunnel.
• Sorgenti e destinazioni: Limitare reti locali e remote se l’assistente le crea troppo ampie.
• Servizi: Usare Any solo per il primo test e poi ridurre ai servizi necessari.
• Logging: Attivare durante introduzione e analisi degli errori.
• Security Features: Impostare consapevolmente IPS, Web, Application Control o NDR, senza ereditarli per caso.

⚠️ Le regole firewall create automaticamente sono un punto di partenza, non un design di sicurezza finito. Soprattutto per tunnel tra sedi verso reti server, dopo il primo test si dovrebbero ridurre servizi, sorgenti e destinazioni.

Con IPsec route-based e subnet Any-to-Any bisogna lavorare con particolare precisione. Per questi design route-based non possono essere create regole firewall automatiche. Con versioni dual IP, le regole IPv4 e IPv6 devono essere pianificate separatamente. In questi scenari, regole firewall, interfaccia XFRM, route e test dovrebbero essere costruiti manualmente in modo consapevole.

Configurare IPsec policy-based

Il policy-based IPsec è la variante classica per collegamenti Site-to-Site semplici. Le reti locali e remote vengono definite direttamente nella connessione IPsec.

1. Verificare o creare il profilo IPsec

Menu path:

Profiles > IPsec profiles

Per prima cosa verificare se un profilo esistente è adatto alla controparte. Se serve un profilo dedicato, dovrebbe avere un nome chiaro, ad esempio IPsec_IKEv2_AES256_G14. Il nome deve restare comprensibile anche in seguito, quando esistono più tunnel e controparti.

Da documentare almeno:

• Versione IKE
• Phase 1 Encryption e Authentication
• DH Group
• Phase 2 Encryption e Authentication
• PFS
• Key lifetime

Per firewall di terze parti, la controparte dovrebbe confermare gli stessi valori per iscritto. Uno screenshot da solo spesso non basta, perché singoli campi possono avere nomi diversi a seconda del produttore.

2. Aggiungere la connessione IPsec

Menu path:

Site-to-site VPN > IPsec

Creare una nuova connessione IPsec e scegliere Policy-based come Connection type. Poi impostare i dati di base:

• Nome del tunnel, ad esempio branch-zurich
• Local gateway o Listening interface
• Remote Gateway come indirizzo IP o FQDN
• Authentication type: Preshared Key o certificato
• Local ID e Remote ID se necessari
• IPsec profile
• Local subnet
• Remote subnet

NAT Traversal è sempre attivo su Sophos Firewall. Se un lato si trova dietro un router o un NAT del provider, Local ID e Remote ID diventano ancora più importanti, perché l’indirizzo gateway pubblico da solo non basta più per identificare correttamente il peer. Gli ID DNS, IP o e-mail non devono essere risolvibili pubblicamente; devono solo coincidere su entrambi i lati e usare un formato valido.

Per le Preshared Keys si dovrebbe usare una chiave forte e univoca e documentarla in modo sicuro. Una vecchia chiave standard condivisa tra più sedi è un rischio operativo inutile.

Le impostazioni avanzate per User authentication mode appartengono solo ai profili IKEv1 con logica XAuth, ad esempio design client-server molto vecchi. Per normali connessioni site-to-site con IKEv2 non bisogna considerarle un passaggio di autenticazione aggiuntivo. Anche le impostazioni idle connection obsolete non dovrebbero essere pianificate come design operativo moderno.

3. Attivare il tunnel

Al salvataggio può essere impostato Activate on save. In ambienti produttivi dovrebbe avvenire in una finestra di manutenzione definita, quando la controparte è raggiungibile ed entrambi i lati possono controllare i log.

Dopo il salvataggio, la lista mostra due stati rilevanti:

• se la connessione è attiva
• se il tunnel è effettivamente established
• IP version, di solito IPv4.
• Gateway type, di solito initiate connection sul lato con gateway remoto definito.

Una voce attiva non equivale automaticamente a un tunnel stabilito. Con più reti locali o remote possono inoltre esistere più Security Associations.

Configurare IPsec route-based

Il route-based IPsec separa più chiaramente negoziazione VPN e routing. Sophos Firewall crea un’interfaccia XFRM. Poi route statiche, SD-WAN Routes o routing dinamico decidono quale traffico passa nel tunnel.

1. Creare la connessione come route-based

Menu path:

Site-to-site VPN > IPsec

Scegliere Route-based (Tunnel interface) per la connessione. I parametri per gateway, autenticazione, IDs e profilo IPsec devono comunque essere coerenti con la controparte. Inoltre bisogna capire quale interfaccia XFRM viene creata e come viene instradata.

Sophos mostra l’interfaccia XFRM generata sotto l’interfaccia fisica usata in:

Network > Interfaces

A seconda del design, l’interfaccia XFRM richiede un indirizzo IP. Soprattutto con design Any-to-Any, versione dual IP o scenari di routing più complessi, l’indirizzamento dell’interfaccia dovrebbe essere pianificato con cura. L’interfaccia XFRM resta assegnata alla zona VPN; questa assegnazione di zona non è un campo di design liberamente selezionabile come nelle normali interfacce fisiche.

Quando si usa Any-to-Any, non è più solo il Tunnel Selector a decidere quale traffico passa nel tunnel. Route e regole firewall diventano quindi il controllo centrale. È flessibile, ma anche soggetto a errori: una regola troppo ampia può consentire più traffico del previsto, una route mancante può far apparire il tunnel verde senza che passi traffico utente.

2. Impostare il routing

Per una VPN route-based, la sola connessione IPsec non basta. Serve una route verso la rete remota:

• route statica verso l’interfaccia XFRM
• SD-WAN Route con gateway o profilo adatto
• route dinamica tramite BGP o OSPF, se il design è costruito per questo
• Se entrambe le subnet sono impostate su Any, il routing decide quale traffico entra nel tunnel.
• Se si usano traffic selectors specifici, devono corrispondere esattamente al peer.

1. L’interfaccia XFRM esiste ed è nella zona corretta.
2. La route verso la rete remota punta all’interfaccia XFRM.
3. Le regole firewall consentono il traffico necessario tra le zone corrette.

Per setup semplici, una route statica è spesso sufficiente. Se vengono usate più linee WAN, controlli SLA o percorsi di failover, una SD-WAN Route è più sensata. Il contesto generale su SD-WAN, Reply Packets e traffico generato dal sistema è in verificare il routing SD-WAN Sophos Firewall per Reply Packets e System Traffic.

3. Considerare XFRM e MTU

Le VPN route-based sono più soggette a equivoci su routing, MTU e MSS. Se piccoli test funzionano ma trasferimenti più grandi restano bloccati, non si dovrebbe modificare subito il profilo IPsec. Prima bisogna verificare MTU, MSS, frammentazione e il percorso reale. Il flusso adatto è in verificare MTU e MSS su Sophos Firewall per problemi VPN.

Creare le regole firewall

Dopo la configurazione IPsec servono regole per il traffico produttivo. Senza regole adeguate, il tunnel può anche rimanere verde, ma le applicazioni non funzionano.

Menu path:

Rules and policies > Firewall rules

Regole tipiche:

• Rete locale verso rete remota: LAN verso VPN o zona di destinazione.
• Rete remota verso rete server locale: VPN o zona XFRM verso Server.
• Management o Monitoring: solo sistemi admin o di monitoring definiti.
• DNS, AD, RDP, HTTPS: solo servizi necessari, non Any in modo generico.

Buona pratica:

• Nome regola con tunnel o sede, ad esempio LAN_to_Branch_Zurich.
• Impostare Source e Destination nel modo più ristretto possibile.
• Definire concretamente i Services.
• Attivare logging durante introduzione e troubleshooting.
• Verificare la posizione della regola.
• Impostare consapevolmente le funzioni di protezione invece di ereditarle per caso.

Se il traffico Internet di una filiale deve passare attraverso la sede centrale, serve inoltre un concetto NAT e sicurezza consapevole. È un design diverso da un semplice collegamento tra sedi per reti interne.

Pianificare NAT consapevolmente

NAT non è vietato con IPsec, ma deve essere chiaramente motivato. Casi tipici sono reti sovrapposte, requisiti cloud o terze parti che accettano solo determinati indirizzi sorgente.

• Con reti sovrapposte, NAT spesso non è opzionale ma parte del design del tunnel.
• Con route-based Any-to-Any, routing e regole firewall decidono maggiormente quale traffico entra nel tunnel.
• Con IPsec policy-based e VPN route-based con traffic selectors, NAT modifica gli indirizzi prima che vengano confrontati con i selectors.

Menu path:

Rules and policies > NAT rules

Prima di una regola NAT, bisognerebbe rispondere a queste domande:

• La controparte si aspetta indirizzi IP originali o indirizzi tradotti?
• Esistono reti sovrapposte?
• NAT viene risolto nella connessione IPsec o tramite regole NAT separate?
• La direzione di ritorno è documentata?
• Log Viewer mostra dopo NAT la Source e la Destination previste?

Per casi particolari policy-based con NAT può diventare rilevante una route IPsec su Sophos Firewall manuale. Non è però un passaggio standard per ogni tunnel.

Device Access e accesso WAN

Per richieste IPsec in ingresso, il firewall deve poter accettare traffico IPsec sulla zona WAN corretta. Questo non si risolve con una normale regola LAN-to-WAN, ma tramite i servizi locali del firewall.

Menu path:

Administration > Device access

Lì IPsec deve essere consentito per la zona necessaria. Allo stesso tempo bisogna verificare se altri servizi locali come WebAdmin, SSH, User Portal o VPN Portal sono raggiungibili in modo troppo ampio. Per l’hardening di questi servizi locali, mettere in sicurezza l’accesso a Sophos Firewall: configurare correttamente Device Access è l’articolo centrale.

Testare il tunnel

Un buon test di accettazione non verifica solo lo stato verde. Verifica il flusso dati effettivo.

Definire una matrice di accettazione

Prima del primo test è opportuno definire una piccola matrice di accettazione. In questo modo è chiaro quale connessione deve funzionare e quale connessione deve essere volutamente non consentita.

Casi di test utili:

• Rete client locale verso rete server remota: test applicativo tipico, ad esempio HTTPS, RDP, SMB, SQL oppure ICMP solo come test di base.
• Rete client remota verso rete server locale: verificare la direzione opposta se la connessione viene usata in modo bidirezionale.
• DNS o AD attraverso il tunnel: testare solo se questi servizi devono davvero passare nel tunnel. Definire con precisione sorgente, server di destinazione e porta.
• Monitoraggio o backup: verificare che i sistemi previsti accedano dalla direzione corretta e non richiedano accidentalmente regole Any.
• Test non consentito: una porta o una rete volutamente non autorizzata deve essere bloccata. In caso contrario, la base di regole è troppo ampia.
• Trasferimento grande: per trasferimenti file, RDP, VoIP o problemi applicativi, osservare anche MTU/MSS e frammentazione.

Per ogni caso di test annotare IP sorgente, IP destinazione, servizio, regola firewall attesa, regola NAT attesa e direzione attesa. Dopo ogni test confrontare Log Viewer, Packet Capture e contatori byte. Se si testa solo il ping, il tunnel non è ancora stato accettato.

1. Verificare lo stato

Nell’interfaccia WebAdmin:

Site-to-site VPN > IPsec

Verificare:

• La connessione è attiva.
• Lo stato del tunnel è established.
• Con più reti, tutte le Child SAs attese sono stabilite.
• Non sono visibili reconnect o errori ricorrenti.

2. Verificare Log Viewer

Menu path:

Log viewer

Generare traffico di test con Source, Destination e Service chiari. Poi verificare in Log Viewer quale regola firewall corrisponde e se NAT, Webfilter, IPS o altri moduli influenzano il traffico.

3. Usare Packet Capture

Se Log Viewer non basta, Packet Capture dovrebbe essere usato con un filtro stretto:

Diagnostics > Tools > Packet capture

Esempio di filtro:

host 172.16.10.25 and host 10.20.30.15

Nel troubleshooting VPN è importante verificare entrambe le direzioni. Pacchetti solo in uscita senza risposta indicano di solito un problema di percorso di ritorno, NAT o controparte.

4. Usare la CLI solo in modo mirato

Per analisi più profonde si può usare l’Advanced Shell via SSH:

ipsec statusall

Sono interessanti tra l’altro:

• IKE SA established
• Child SA installed
• reti locali e remote
• contatori byte in entrambe le direzioni
• messaggi ricorrenti di rekey o disconnect

Se SSH non è ancora preparato, aiuta collegarsi a Sophos Firewall via SSH.

Errori tipici

• Il tunnel non si attiva: Versione IKE, profilo, PSK, certificato, Local ID o Remote ID non corrisponde. strongswan.log, profilo IPsec, controparte.
• Phase 1 è attiva, Phase 2 no: reti locali/remote o Phase 2 proposal non corrispondono. Traffic Selectors, subnet, PFS.
• Il tunnel è verde, ma non c’è accesso: manca regola firewall, NAT, routing o percorso di ritorno. Log Viewer, Packet Capture, routing.
• Funziona una sola direzione: la controparte non conosce la route di ritorno o NAT è errato. controparte, regole NAT, contatori byte.
• Piccoli ping funzionano, applicazioni bloccate: MTU/MSS, frammentazione o Security Feature. verificare MTU/MSS, Packet Capture.
• Tunnel route-based poco chiaro: interfaccia XFRM, route o SD-WAN Route non adatta. Network > Interfaces, routing, SD-WAN.
• Più tunnel si influenzano: reti sovrapposte o configurazione Selector simile. oggetti tunnel, failover group, route.

Checklist

Prima del change:

• Le reti locali e remote sono univoche.
• La scelta policy-based o route-based è stata fatta consapevolmente.
• Il profilo IPsec è allineato con la controparte.
• Preshared Key o certificati sono documentati in modo sicuro.
• Le regole firewall sono pianificate, inclusi direzione, posizione, logging e servizi.
• Con Create firewall rule è chiaro quali regole create automaticamente devono essere rielaborate.
• Per route-based Any-to-Any sono pianificate regole firewall e route manuali.
• NAT è escluso oppure documentato consapevolmente.
• Device Access per IPsec è stato verificato.
• Finestra di manutenzione, controparte e percorso di fallback sono noti.

Dopo il change:

• Lo stato del tunnel è established.
• Log Viewer mostra la regola firewall attesa.
• Packet Capture mostra direzione di andata e ritorno.
• Accessi DNS interni e applicativi sono stati testati.
• I contatori byte aumentano in entrambe le direzioni.
• NAT e percorso di ritorno sono allineati con la controparte.
• La modifica è stata aggiornata nella documentazione di rete.
• Matrice di accettazione con almeno un test definito per ogni direzione richiesta.

Domande frequenti