Configurare VPN IPsec Site-to-Site Sophos Firewall

Una VPN IPsec Site-to-Site collega due sedi oppure una Sophos Firewall a 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 differenti, regole firewall mancanti, casi particolari di NAT o un percorso di ritorno dimenticato su uno dei due lati.

Procedura rapida: scegliere il tipo di tunnel, allineare profilo e ID, creare la connessione, instradare l’interfaccia XFRM per route-based Any-to-Any, configurare le regole firewall e NAT e collaudare il tunnel con traffico reale, log e Packet Capture.

La procedura è adatta a connessioni Sophos-to-Sophos e verso terze parti tra sede principale, filiale o cloud gateway. Per Microsoft Azure e AWS si applicano ulteriori dettagli specifici del provider: collegare Sophos Firewall ad Azure VPN Gateway e collegare Sophos Firewall ad AWS Site-to-Site VPN. Per il Remote Access dei singoli utenti è invece utile il confronto tra Sophos Connect e SSL VPN. Se un tunnel esistente è già verde ma non passa traffico, consultare Sophos Firewall IPsec VPN Troubleshooting.

Se la connessione avviene esclusivamente tra due Sophos Firewall e la filiale deve stabilire il tunnel come client verso una sede centrale raggiungibile in modo stabile, SSL Site-to-Site VPN è un’alternativa più semplice. Per peer di terze parti, ridondanza, routing dinamico o reti in crescita, IPsec route-based rimane la scelta più flessibile.

Per più firewall gestiti da Sophos Fusion (in precedenza Sophos Central), un gruppo di connessioni SD-WAN può generare automaticamente tunnel route-based, interfacce XFRM, route e regole opzionali. Questo non sostituisce né la pianificazione della topologia né la verifica locale del traffico.

Scegliere policy-based o route-based

Prima della configurazione occorre decidere se creare il tunnel come policy-based o route-based. Al di fuori dell’interfaccia Sophos, route-based viene spesso chiamato anche tunnel-based. Entrambi i termini descrivono un tunnel con una propria interfaccia XFRM. Il termine “root-based”, usato occasionalmente, non è invece una modalità VPN.

Sophos consiglia VPN route-based per i nuovi design. Any-to-Any è particolarmente flessibile per reti in crescita, perché le modifiche alle route non interrompono il tunnel. Le modifiche alle sottoreti o ai Traffic Selectors interrompono invece le connessioni esistenti. Entrambe le estremità devono usare lo stesso tipo: policy-based su un lato e route-based sull’altro non è supportato.

Per utilizzare OSPF o BGP attraverso il tunnel, il design più trasparente è route-based Any-to-Any con interfacce XFRM indirizzate. Prima di aggiornare una configurazione policy-based precedente, verificare se le reti VPN vengono annunciate tramite redistribute kernel; SFOS 22: route IPsec e redistribute kernel spiega il cambiamento di versione e il quadro per una migrazione sicura.

Cosa conferma davvero un tunnel verde

Uno stato come Established conferma che le controparti hanno negoziato IKE e almeno una Child SA. Non conferma che venga scelta una route, che la regola firewall corrisponda, che il NAT sia corretto, che la controparte conosca il percorso di ritorno o che l’host di destinazione risponda. Un tunnel può quindi essere verde senza trasportare traffico utile tra le sedi.

Sophos Firewall usa ESP in modalità tunnel. ESP protegge l’integrità dei dati, autentica l’origine dei dati trasportati e offre protezione anti-replay contro i pacchetti riprodotti.

Il percorso dei dati può essere interpretato con il seguente modello:

Policy-based
Sorgente -> Regola firewall -> Selector Local/Remote -> Child SA -> Peer -> Route di ritorno e regola -> Destinazione

Route-based Any-to-Any
Sorgente -> Route o SD-WAN Route -> Regola firewall -> XFRM -> Child SA -> Peer -> Route di ritorno e regola -> Destinazione

Questo è un modello diagnostico, non una rappresentazione completa dell’ordine di elaborazione interno di SFOS. La distinzione è comunque essenziale per il collaudo: con policy-based, la coppia di reti nella connessione IPsec determina quale traffico appartiene al tunnel. Con route-based Any-to-Any, la selezione viene effettuata dal routing o da SD-WAN.

Prerequisiti e dati di pianificazione

Prima della configurazione occorre documentare almeno questi dati:

• Endpoint locale: interfaccia WAN della Sophos Firewall e indirizzo tramite il quale la controparte raggiunge questa interfaccia.
• Remote Gateway: IP pubblico o hostname DNS della controparte.
• Gateway type: normalmente Respond only nella sede centrale e Initiate the connection nella filiale.
• IP version: IPv4, IPv6 o Dual. Dual è disponibile solo per interfacce tunnel route-based con Any-to-Any come sottoreti locale e remota. Con Dual occorre pianificare separatamente le regole firewall IPv4 e IPv6.
• Reti locali: ad esempio 172.16.10.0/24 e 172.16.20.0/24.
• Reti remote: ad esempio 10.20.30.0/24.
• Tipo di VPN: policy-based o route-based. Esiste anche il Connection type Host-to-host, ma non è l’oggetto di questa guida per collegamenti tra sedi.
• Listening interface: interfaccia WAN del firewall locale. Non è possibile utilizzare una bridge interface.
• Versione IKE: preferibilmente IKEv2, se supportata dalla controparte.
• Authentication type: Preshared key, Digital certificate o RSA key.
• Local ID e Remote ID: particolarmente importanti con FQDN, controparti dinamiche, NAT-T o Wildcard Gateway.
• Profilo IPsec: Encryption, Authentication, DH Group, PFS e Key life.
• Regole firewall: origini, destinazioni e servizi consentiti.
• NAT: nessun NAT oppure SNAT/DNAT per reti sovrapposte o requisiti del provider.
• Operatività: owner, finestra di manutenzione, piano di test, monitoring e percorso di fallback.

Esempio coerente per entrambi i firewall

I seguenti valori di esempio facilitano i passaggi successivi. Sostituiscili tutti con i tuoi indirizzi WAN, le tue reti e i tuoi nomi:

Creare innanzitutto entrambe le reti LAN come oggetti di rete sotto Hosts and services > IP host. Nella sede centrale, 10.10.10.0/24 è la Local subnet e 10.20.20.0/24 la Remote subnet; nella filiale, invertire questi valori. Lo stesso vale per gli ID: la Local ID di un lato deve corrispondere alla Remote ID attesa dalla controparte. La rete di trasferimento 10.255.0.0/30 è utilizzata solo per route-based Any-to-Any e non deve sovrapporsi ad alcuna rete di produzione, VPN o gestione.

⚠️ 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 un NAT differente, il tunnel spesso appare integro anche se le applicazioni non funzionano.

Reti, profilo, ID e certificati

Le reti locali e remote non devono sovrapporsi involontariamente. Sono particolarmente problematiche reti predefinite comuni come 192.168.0.0/24, 192.168.1.0/24 o reti di filiale riutilizzate. In caso di sovrapposizione serve un design NAT consapevole. Usare lo stesso intervallo di indirizzi sui due lati e tradurlo successivamente “in qualche modo” crea tunnel difficili da gestire.

Per le nuove sedi conviene quindi definire un piano di indirizzamento IP pulito. Se VLAN o zone non sono ancora modellate correttamente, consultare configurare zone e interfacce su Sophos Firewall.

Entrambi i lati devono usare parametri compatibili per Phase 1 e Phase 2. Sono inclusi cifratura, autenticazione, DH Group, PFS e durata. Per connessioni a firewall di terze parti è spesso più semplice concordare prima un profilo comune per iscritto e solo dopo configurare entrambi i lati.

Con IKEv2, Sophos può utilizzare Preshared Key uniche per ogni combinazione Local ID/Remote ID. Con IKEv1 questo comportamento è più limitato, perché per ogni combinazione di gateway è valida una sola PSK. Negli ambienti con più tunnel verso la stessa controparte è quindi preferibile IKEv2 con ID definiti chiaramente.

⚠️ Con IKEv1, il firewall utilizza la PSK della connessione configurata più di recente per la stessa combinazione di gateway locale e remoto. Questo vale per le configurazioni IPsec site-to-site e di accesso remoto. Configurare successivamente una connessione per questa combinazione di gateway con una PSK diversa può causare un errore di autenticazione delle connessioni esistenti durante una negoziazione successiva. Prima di aggiungere una connessione di questo tipo o modificare una PSK, verificare tutte le configurazioni IKEv1 interessate e concordare la PSK con le rispettive controparti prima della prossima negoziazione.

NAT Traversal è sempre attivo su Sophos Firewall. Se un lato si trova dietro un router o un NAT del provider, gli ID diventano più importanti perché l’indirizzo pubblico del gateway non identifica in modo univoco il peer. La Local ID di un lato deve corrispondere alla Remote ID attesa dalla controparte. Gli ID DNS, IP o e-mail non devono essere risolvibili pubblicamente, ma formato e valore devono corrispondere in modo incrociato.

Sophos Firewall non offre un interruttore NAT-T separato: I dispositivi rilevano automaticamente la presenza di NAT. Senza NAT, le negoziazioni IKE usano UDP 500 e il traffico dati usa ESP tramite IP protocol 50. Quando il firewall rileva un dispositivo NAT, incapsula in UDP 4500 le successive negoziazioni IKE e di fase 2, oltre ai pacchetti ESP.

Se sul percorso IPsec è presente un dispositivo NAT e la controparte è un firewall di terze parti, NAT-T deve essere attivo anche su quel firewall. L’impostazione viene verificata consultando la documentazione della controparte; su Sophos Firewall non serve un interruttore aggiuntivo.

Le controparti rilevano un dispositivo NAT durante lo scambio IKE di fase 1 e concordano quindi l’uso di NAT-T. ESP è un protocollo di livello 3 privo di informazioni sulle porte di livello 4, mentre PAT può tradurre anche le porte. L’incapsulamento UDP tramite la porta 4500 fornisce quindi un involucro UDP identificabile sul percorso NAT; la controparte rimuove questo involucro ed elabora il pacchetto IPsec originale.

Se Sophos Firewall si trova dietro un router, quest’ultimo deve applicare una regola DNAT o un port forwarding dall’indirizzo pubblico al Listening interface privato del firewall. Il percorso NAT-T deve consentire UDP 500 e UDP 4500; ESP nativo tramite IP protocol 50 serve solo su un percorso senza NAT. Questa logica è distinta dalla successiva pianificazione SNAT o DNAT per reti sovrapposte o traffico dati tradotto.

Con Digital certificate, formati e ruoli dei certificati devono corrispondere esattamente su entrambi i lati. Sophos non supporta certificati ECDSA per le connessioni IPsec; sono necessari certificati RSA. Una CA pubblica non dovrebbe essere utilizzata genericamente come Remote CA Certificate, perché concederebbe troppa fiducia a certificati estranei. RSA key è un Authentication type separato: i due firewall si scambiano le chiavi pubbliche e devono usare lo stesso formato PKCS1 o DNS.

La modifica della CA locale Default di Sophos Firewall è un cambio del trust anchor, non una modifica estetica del certificato. I peer con un Default.pem importato e i certificati firmati localmente devono essere migrati in modo controllato. Rinnovare in modo controllato la Default CA di Sophos Firewall spiega inventario, finestra di manutenzione, test e ripristino.

Quando viene selezionato Digital certificate, la scelta nel modulo di connessione non è sufficiente. La fiducia nella CA, i certificati locali, i certificati del peer e i Certificate IDs devono essere preparati in anticipo. La procedura completa è descritta in Configurare IPsec Site-to-Site con certificati. Se la CA revoca i certificati prima della loro scadenza, l’elenco di revoca attuale deve essere incluso nel piano operativo. Una procedura separata descrive l’importazione della CRL, il controllo di nextUpdate e un test negativo controllato su Sophos Firewall.

Se il tunnel non si attiva, NO_PROPOSAL_CHOSEN, errori degli ID o errori di autenticazione sono indicazioni tipiche. La sezione Testare il tunnel e risolvere i problemi inizia con la procedura di analisi appropriata.

Configurare IPsec policy-based

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

1. Verificare o creare il profilo IPsec

Percorso di menu:

Profiles > IPsec profiles

Verificare innanzitutto se un profilo esistente è compatibile con la controparte. Se occorre un profilo dedicato, assegnargli un nome univoco, ad esempio Branch-Zurich-IKEv2. Il nome deve rimanere comprensibile anche quando saranno presenti più tunnel e controparti.

Documentare almeno:

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

Con firewall di terze parti, la controparte dovrebbe confermare gli stessi valori per iscritto. Una sola schermata spesso non basta, perché i singoli campi possono avere nomi diversi a seconda del produttore.

L’interazione tra Phase 1, Phase 2, PFS, Lifetimes, Rekeying e DPD è spiegata in Comprendere e configurare in sicurezza i profili IPsec Sophos Firewall. Prima dell’attivazione, controllare Dead peer detection: Sophos specifica Hold o Disconnect per la controparte che risponde e Re-initiate per l’iniziatore. Un gruppo di failover IPsec cambia questo comportamento e non segue la stessa logica DPD.

2. Aggiungere la connessione IPsec

Percorso di menu:

Site-to-site VPN > IPsec

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

• Nome del tunnel, ad esempio branch-zurich
• IP version, normalmente IPv4
• Gateway type, ad esempio Respond only nella sede centrale o Initiate the connection nella filiale
• Listening interface come interfaccia WAN locale
• Gateway address della controparte come indirizzo IP o hostname DNS
• Authentication type: Preshared key, Digital certificate o RSA key
• Local ID e Remote ID, se necessari
• IPsec profile
• Local subnet
• Remote subnet

Con IPsec policy-based, al massimo un lato dei Traffic Selectors può essere impostato su Any. Con più reti locali e remote specifiche, Sophos crea una Phase 2 SA per ogni combinazione.

Con Respond only, un indirizzo wildcard * può essere utile quando più filiali o controparti dinamiche si collegano alla sede centrale. In tal caso deve essere impostata almeno una Local ID o Remote ID; per un’assegnazione univoca sono in genere utili entrambe. La Local ID di un lato corrisponde alla Remote ID attesa dall’altro. Initiate the connection non supporta un indirizzo wildcard, quindi la controparte viene definita con un indirizzo IP o un hostname DNS.

Per i Preshared Key utilizzare una chiave forte e univoca e documentarla in modo sicuro. Una vecchia chiave standard condivisa tra più sedi è un rischio operativo inutile.

Creare quindi la connessione sulla controparte con impostazioni speculari. In questo esempio, la sede centrale attende 203.0.113.20 con Respond only; le reti Local/Remote sono rispettivamente 10.10.10.0/24 e 10.20.20.0/24. La filiale utilizza Initiate the connection, Gateway address 198.51.100.10 e inverte le reti e gli ID Local/Remote. Profilo, autenticazione e PSK devono essere compatibili. Attivare la connessione solo dopo aver salvato entrambe le voci e verificato le regole.

Le impostazioni avanzate di User authentication mode appartengono solo ai profili IKEv1 con logica XAuth, ad esempio design client-server molto datati. Nelle normali connessioni Site-to-Site con IKEv2 non devono essere interpretate come un ulteriore passaggio di autenticazione. Anche le impostazioni Idle Connection obsolete non dovrebbero far parte di un design operativo moderno.

3. Attivare il tunnel

Al salvataggio è possibile selezionare Activate on save. Negli ambienti di produzione, procedere in una finestra di manutenzione definita, quando la controparte è raggiungibile ed entrambi i lati possono controllare i log.

Dopo il salvataggio, l’elenco mostra due stati rilevanti:

• se la connessione è attiva
• se il tunnel è effettivamente established

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

Configurare IPsec route-based

IPsec route-based separa la negoziazione VPN dalla selezione della route. Con Any-to-Any, SFOS fornisce un’interfaccia XFRM dedicata e indirizzabile. Per Traffic Selectors specifici, la documentazione SFOS 22 attuale è in conflitto sulla creazione dell’interfaccia, come spiegato di seguito.

1. Creare la connessione come route-based

Percorso di menu:

Site-to-site VPN > IPsec

Nella connessione scegliere Route-based (Tunnel interface). I parametri di gateway, autenticazione, ID e profilo IPsec devono continuare a corrispondere alla controparte. Occorre inoltre comprendere quale interfaccia XFRM verrà creata e come sarà instradata.

2. Implementare Any-to-Any o Traffic Selectors

Per Any-to-Any, Sophos mostra l’interfaccia XFRM generata sotto l’interfaccia fisica utilizzata in:

Network > Interfaces

Un’interfaccia XFRM generata rimane sempre assegnata alla zona VPN. Le due varianti vengono configurate in modo diverso.

Any-to-Any con IPv4, IPv6 o Dual

Quando Local subnet e Remote subnet sono entrambe impostate su Any, SFOS crea automaticamente l’interfaccia XFRM per la connessione IPsec route-based. Non si deve aggiungere un’interfaccia XFRM separata. In Network > Interfaces, espandere l’interfaccia fisica scelta come Listening interface e aprire l’interfaccia XFRM generata. In questo esempio, assegnare 10.255.0.1/30 alla sede centrale e 10.255.0.2/30 alla filiale. Con Dual sono richieste anche regole firewall IPv4 e IPv6 separate.

Il campo Name modificabile è il nome visualizzato. Non va confuso con i valori assegnati da SFOS: Hardware è il nome del record, IPsec connection è la connessione route-based associata e Network zone è sempre VPN. Configurare solo i campi indirizzo relativi alla versione IP selezionata nella connessione IPsec:

• IPv4/netmask: inserire l’indirizzo IPv4 di transito pianificato e selezionare la subnet.
• IPv6/prefix: inserire l’indirizzo IPv6 di transito pianificato e il prefisso.
• Con Dual, configurare entrambe le famiglie. Se la connessione usa solo IPv4 o solo IPv6, SFOS non applica i valori inseriti per l’altra versione.

In Advanced settings > Interface settings, mantenere il valore MTU predefinito oppure inserire il valore verificato con test specifici. SFOS calcola il valore predefinito sottraendo l’overhead IPsec massimo dall’MTU dell’interfaccia fisica. Attivare Override MSS e inserire un valore solo se la rete ne richiede uno diverso dal valore predefinito del firewall; non presumere un valore numerico non documentato.

Prima della modifica, registrare nome, indirizzi, MTU, stato e valore di Override MSS e route o gateway dipendenti. Dopo il salvataggio, riaprire l’interfaccia e verificare che Hardware, IPsec connection e zona VPN assegnati non siano cambiati. Eseguire quindi Route lookup su entrambi i peer e testare traffico reale nelle due direzioni, compreso un trasferimento di grandi dimensioni se sono cambiati MTU o MSS. Per il rollback, ripristinare i valori registrati e le route o i gateway precedenti. Se la connessione è nuova, disattivarla e rimuovere solo route e regole dipendenti; non tentare di eliminare o ricreare separatamente l’interfaccia XFRM generata.

Successivamente, creare la route verso la LAN remota su entrambi i lati. Per una semplice configurazione statica, aprire Routing > Static routes > IPv4 unicast route > Add:

• Sede centrale: Destination 10.20.20.0/24, Interface l’interfaccia XFRM locale.
• Filiale: Destination 10.10.10.0/24, Interface l’interfaccia XFRM locale.

In alternativa, utilizzare una SD-WAN Route o il routing dinamico tramite BGP o OSPF. Per una SD-WAN Route, decidere esplicitamente se un percorso diverso è consentito come fallback. Se il traffico non deve utilizzare un altro percorso quando il tunnel non è disponibile, attivare Route only through specified gateways e testare separatamente questo scenario di errore.

Le route e le regole firewall decidono quale traffico entra nel tunnel. Una semplice route statica può puntare direttamente all’interfaccia XFRM. In presenza di più linee, controlli SLA o determinati design di Failover, viene creato anche un Custom Gateway con l’indirizzo IP XFRM della controparte e utilizzato in una SD-WAN Route.

I tunnel Any-to-Any possono gestire più XFRM Gateway direttamente tramite SD-WAN e controlli SLA; non è necessario un VPN Failover Group aggiuntivo. I tunnel Policy-based e i tunnel Route-based con Traffic Selectors utilizzano invece un IPsec Failover Group per le connessioni ridondanti. La procedura collegata spiega ordine, Health Check, Automatic failback e test di interruzione controllato. Il gruppo disattiva DPD per le connessioni assegnate e imposta Key negotiation tries su 3.

Controlla quattro punti dopo il salvataggio:

1. L’interfaccia XFRM è visibile sotto Network > Interfaces e ha l’indirizzo IP di trasferimento pianificato.
2. La route verso la rete remota punta direttamente all’interfaccia XFRM o, in un design con gateway/SD-WAN, al gateway XFRM appropriato.
3. Diagnostics > Tools > Route lookup restituisce l’interfaccia XFRM prevista o il gateway XFRM previsto per un host effettivo nella LAN remota. Eseguire lo stesso test sulla controparte.
4. Le regole Firewall permettono solo le direzioni e i servizi previsti.

Traffic Selectors

Con subnet specifiche, il comportamento di SFOS 22 in questo caso particolare non è univoco: un’interfaccia XFRM può non comparire, ma il firewall può anche crearne una per ogni configurazione di Traffic Selectors. Espandi la Listening interface in Network > Interfaces e verifica lo stato effettivo del build installato; un’interfaccia XFRM esistente può essere selezionata anche in Diagnostics > Packet capture. Se compare un’interfaccia XFRM, non assegnarle né un indirizzo IP né route. La route statica viene creata automaticamente quando il tunnel è established. Any su un solo lato con un selector specifico sull’altro non è supportato.

Questa variante è adatta a reti piccole e chiaramente definite. Se l’interfaccia è visibile, usarla come documentato per confermare il traffico in uscita in Diagnostics > Packet capture; controllare anche route automatica, Child SAs, log e traffico in entrambe le direzioni. WAF tramite IPsec route-based con Traffic Selectors non è supportato.

Un tunnel Any-to-Any non può essere convertito direttamente a Traffic Selectors specifici. Occorre clonare o ricreare la connessione e poi eseguire una commutazione controllata.

3. Considerare XFRM e MTU

Le VPN route-based sono più soggette a incomprensioni relative a routing, MTU e MSS. Se i test piccoli funzionano ma i trasferimenti più grandi si bloccano, non modificare immediatamente il profilo IPsec. Verificare prima MTU, MSS, frammentazione e percorso effettivo. La procedura appropriata è descritta in verificare MTU e MSS su Sophos Firewall in caso di problemi VPN.

Regole firewall, NAT e Device Access

Regole firewall e regole automatiche

Dopo la configurazione IPsec occorrono regole per il traffico di produzione. Senza regole adeguate, il tunnel può essere verde ma le applicazioni non funzionano.

Percorso di menu:

Rules and policies > Firewall rules

Regole tipiche:

• Rete locale verso rete remota: ad esempio da LAN a VPN.
• Rete remota verso rete server locale: ad esempio da VPN a Server.
• Management o Monitoring: consentire solo sistemi amministrativi o di monitoring definiti.
• DNS, AD, RDP, HTTPS: consentire solo i servizi necessari, non Any in modo generico.

Le interfacce XFRM appartengono sempre alla zona VPN. Se vengono usate entrambe le direzioni, occorrono regole inbound e outbound adeguate. Regole separate con logging mostrano più chiaramente durante il collaudo quale lato può raggiungere quali servizi. La configurazione generale è descritta in creare e verificare in sicurezza le regole Sophos Firewall.

I pacchetti IPsec in ingresso vengono prima decapsulati e decifrati. La regola firewall corrispondente applica poi le proprie policy di sicurezza al traffico dati prima che venga inoltrato alla destinazione. Per il traffico in uscita, la regola firewall corrispondente viene applicata prima dell’incapsulamento e della cifratura.

L’opzione Create firewall rule genera regole separate con i prefissi Incoming e Outgoing all’inizio dell’elenco delle regole. In seguito:

• Controllare la posizione delle regole.
• Restringere Source e Destination.
• Ridurre Any ai Services necessari.
• Attivare Log firewall traffic durante l’implementazione e l’analisi degli errori.
• Scegliere consapevolmente IPS, Web, Application Control e altre Security Features.
• Assegnare un nome comprensibile alla regola, ad esempio LAN_to_Branch_Zurich.

⚠️ Le regole firewall create automaticamente sono un punto di partenza, non un design di sicurezza completo. Soprattutto per i tunnel tra sedi e reti server, dopo il primo test occorre limitare servizi, origini e destinazioni.

Per route-based Any-to-Any, Sophos non può creare regole automaticamente. Con Dual, le regole IPv4 e IPv6 vengono create separatamente. Se il traffico Internet di una filiale deve passare attraverso la sede centrale, serve inoltre un design NAT e di sicurezza dedicato.

Pianificare il NAT in base al tipo di tunnel

NAT non è vietato con IPsec, ma deve avere una ragione chiara. I casi tipici sono reti sovrapposte, requisiti cloud o terze parti che accettano solo indirizzi sorgenti specifici. NAT non sostituisce una route e non modifica la decisione di routing: indipendentemente dalla traduzione, SFOS deve poter selezionare una route VPN, statica, SD-WAN o dinamica adatta alla destinazione.

Percorso di menu:

Rules and policies > NAT rules

Prima di creare una regola NAT, rispondere alle seguenti domande:

• La controparte si aspetta indirizzi IP originali o tradotti?
• Esistono reti sovrapposte?
• Il NAT viene configurato nella connessione IPsec o tramite regole NAT separate?
• Il percorso di ritorno è documentato?
• Dopo il NAT, Log Viewer mostra Source e Destination attese?

La logica NAT varia in base al tipo di VPN:

• Con IPsec policy-based e VPN route-based con Traffic Selectors, il NAT per reti sovrapposte può essere configurato direttamente nella connessione IPsec.
• Con route-based Any-to-Any, le regole SNAT e DNAT vengono create in Rules and policies > NAT rules.
• Con reti sovrapposte, entrambi i lati devono comprendere lo stesso piano di traduzione. Un NAT unilaterale senza pianificazione del ritorno spesso produce tunnel verdi senza traffico utilizzabile.

⚠️ Con IPsec route-based e Traffic Selectors, usare l’impostazione NAT nella connessione IPsec e non assegnare un indirizzo IP o una route manuale a un’interfaccia XFRM se il build installato la mostra. IPsec con NAT per reti sovrapposte mostra il design completo e speculare di indirizzamento, DNS e NAT.

Se il traffico di una VPN route-based con Traffic Selectors corrisponde a una regola SNAT con Translated source = MASQ, il firewall scarta i pacchetti perché queste interfacce XFRM non hanno indirizzi IP assegnati. Questo può spiegare un tunnel verde senza traffico utilizzabile. Per il flusso di test interessato, verificare la regola NAT corrispondente e la sua posizione, quindi correggere soltanto la regola in conflitto; non disattivare MASQ indiscriminatamente per le altre connessioni. Ripetere poi la verifica dello stesso flusso in entrambe le direzioni con Log Viewer e Packet Capture.

Se il traffico utile di un IPsec policy-based viene tradotto da una regola SNAT separata, il relativo Outbound interface deve essere impostato su Any. Una regola che elenca solo porte WAN specifiche, normalmente inclusa la regola SNAT predefinita, non corrisponde a questo traffico VPN. Con Any, il firewall utilizza il valore di Translated source configurato nella regola SNAT corrispondente. Questo comportamento si applica anche quando Override source translation (SNAT) è abilitato per specifiche interfacce in uscita.

Da SFOS 22, IPsec policy-based crea la route VPN nel backend. Una ipsec_route manuale è rilevante solo per alcuni scenari di traffico inoltrato e non è un passaggio standard; il traffico generato dal sistema non la richiede. Ulteriori nozioni di base sul NAT sono descritte in Comprendere le regole NAT di Sophos Firewall.

Device Access per IPsec in ingresso

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

Percorso di menu:

Administration > Device access

Qui IPsec deve essere consentito per WAN quando il firewall accetta richieste in ingresso, ad esempio con Respond only. Ciò non sostituisce le regole per il traffico utile attraverso il tunnel. Verificare inoltre che WebAdmin, SSH, User Portal o VPN Portal non siano raggiungibili in modo inutilmente ampio. Per proteggere questi servizi locali, consultare proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Testare il tunnel e risolvere i problemi

Un buon test di accettazione non verifica soltanto lo stato verde, ma il flusso di dati effettivo.

Definire la matrice di accettazione

Prima del primo test occorre definire una piccola matrice di accettazione. In questo modo è chiaro quali connessioni devono funzionare e quali devono essere intenzionalmente bloccate.

Casi di test utili:

• Rete client locale verso rete server remota: tipico test applicativo, 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 è utilizzata in modo bidirezionale.
• DNS o AD attraverso il tunnel: eseguire il test solo se questi servizi devono realmente transitare nel tunnel. Definire concretamente Source, server di destinazione e porta.
• Monitoring o backup: verificare che i sistemi pianificati 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 di grandi dimensioni: per trasferimenti di file, RDP, VoIP o problemi applicativi, osservare anche MTU/MSS e frammentazione.

Per ogni caso di test annotare Source IP, Destination IP, Service, regola firewall attesa, regola NAT attesa e direzione attesa. Dopo ogni test confrontare Log Viewer, Packet Capture e contatori di byte. Se viene verificato solo il ping, il tunnel non è ancora stato collaudato.

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 SA previste sono stabilite.

Sotto Current activities > IPsec connections, filtrare le connessioni effettivamente stabilite per Connection name, Local subnet o Remote subnet e aggiornare la vista con Refresh. Disconnect termina una SA esistente in modo controllato, ad esempio una volta che entrambi i lati sono pronti per una modifica di configurazione; non sostituisce la disabilitazione o il roll back della connessione.

Determinare in anticipo il numero atteso: route-based Any-to-Any crea una connessione Phase 2 per interfaccia XFRM, mentre Dual ne crea una per IPv4 e una per IPv6. Policy-based e route-based con Traffic Selectors creano una connessione per ogni combinazione di Local e Remote subnet.

Prima di inviare il primo traffico utile tramite route-based Any-to-Any, controllare l’indirizzo effettivo dell’host di destinazione sotto Diagnostics > Tools > Route lookup. Su ogni firewall, il risultato deve puntare all’interfaccia XFRM o al gateway XFRM previsto.

2. Verificare Log Viewer

Percorso di menu:

Log viewer

Generare traffico di test con Source, Destination e Service chiari. Verificare quindi in Log Viewer quale regola firewall corrisponde e se NAT, Webfilter, IPS o altri moduli influenzano il traffico. La procedura è descritta in testare una regola firewall con Log Viewer, Policy Test e Packet Capture. Rekey, disconnessioni ed errori di connessione ricorrenti vanno verificati nei log IPsec, non dedotti dallo stato SA corrente.

3. Packet Capture e Advanced Shell

Se Log Viewer non basta, utilizzare Packet Capture con un filtro specifico:

Diagnostics > Packet capture

Esempio di filtro:

host 172.16.10.25 and host 10.20.30.15

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

Advanced Shell

Per un troubleshooting più approfondito tramite SSH, aprire 5. Device Management > 3. Advanced Shell e verificare lo stato SA corrente:

ipsec statusall

Sono rilevanti, tra gli altri:

• IKE SA established
• Child SA installed
• Traffic Selectors locali e remoti
• contatori di byte in entrambe le direzioni

Se SSH non è ancora configurato, consultare collegarsi a Sophos Firewall tramite SSH.

Log IPsec attuali

L’attuale panoramica dei log di SFOS 22 separa le funzioni:

• strongswan.log: servizio IPsec e connessioni.
• charon.log: servizio IPsec e NAT nelle connessioni IPsec.
• ipsec_monitor.log: monitoring del servizio IPsec.
• /log/ipsec_conn/ipsec_<connectionname>.log: attivazione, disattivazione e connessione tramite WebAdmin.
• xfrmi.log: interfacce XFRM per IPsec route-based.
• dgd.log: solo in aggiunta per VPN failover, SD-WAN, DGD o Link Load Balancing, non come log IPsec generale.

Per una diagnostica completa di log e XFRM, seguire Sophos Firewall IPsec VPN Troubleshooting.

Errori tipici

• Il tunnel non si stabilisce: probabilmente non corrispondono versione IKE, profilo, PSK, certificato, Local ID o Remote ID. Verificare strongswan.log, profilo IPsec e controparte.
• Phase 1 è attiva, Phase 2 no: probabilmente non corrispondono le reti locali o remote oppure la proposta Phase 2. Verificare Traffic Selectors, sottoreti e PFS.
• Il tunnel è verde, ma non c’è accesso: probabilmente manca una regola firewall, il NAT, il routing o il percorso di ritorno. Verificare Log Viewer, Packet Capture e routing.
• Funziona una sola direzione: la controparte non conosce la route di ritorno oppure il NAT è errato. Verificare controparte, regole NAT e contatori di byte.
• I ping piccoli funzionano, ma le applicazioni si bloccano: probabilmente intervengono MTU/MSS, frammentazione o una Security Feature. Verificare MTU/MSS e Packet Capture.
• Route-based Any-to-Any non funziona: probabilmente non corrispondono IP XFRM, gateway, route o regola firewall. Verificare Network > Interfaces, routing e regole della zona VPN.
• Route-based con Traffic Selectors non funziona: verificare se il build effettivo mostra l’interfaccia XFRM sotto la Listening interface. Se appare, usarla in Packet Capture, ma non assegnarle IP o route. Verificare anche route automatica, Selectors, regole della zona VPN ed eventuale regola MASQ.
• Più tunnel si influenzano a vicenda: probabilmente sono presenti reti sovrapposte o configurazioni Selector simili. Verificare oggetti tunnel, Failover Group e route.

Rollback dopo l’accettazione fallita

Ripristinare la configurazione precedente di un nuovo tunnel in modo controllato, anziché eliminare regole e oggetti sulla base di supposizioni:

1. Sotto Current activities > IPsec connections, terminare la SA interessata con Disconnect e disabilitare la nuova connessione IPsec.
2. Disattivare solo le route statiche o SD-WAN, le regole NAT e le regole firewall create per questa modifica, incluse le regole VPN generate automaticamente. Non eliminare separatamente un’interfaccia XFRM generata se il build la mostra; la disattivazione della connessione gestisce tale interfaccia.
3. In caso di migrazione, riassegnare il profilo precedente alla vecchia connessione, quindi riattivare la connessione e il vecchio percorso di routing.
4. Verificare nuovamente il flusso di test originale e il traffico Internet locale o tra sedi con Log Viewer e Packet Capture.
5. Rimuovere i nuovi oggetti solo quando Object Usage non mostra più dipendenze e il vecchio percorso ha ripreso a funzionare in modo dimostrabile.

Checklist

Prima della modifica:

• Le reti locali e remote sono univoche.
• È stata scelta consapevolmente la modalità policy-based o route-based.
• Il profilo IPsec è allineato con la controparte.
• Preshared Key, certificati o chiavi RSA sono documentati in modo sicuro.
• Le regole firewall sono pianificate, incluse direzione, posizione, logging e servizi.
• Con Create firewall rule è chiaro quali regole create automaticamente devono essere rielaborate.
• Per route-based Any-to-Any sono pianificati IP XFRM, gateway, regole firewall manuali e route.
• Per route-based con Traffic Selectors è stata registrata la visibilità XFRM effettiva; non sono previsti IP XFRM o route manuali, indipendentemente dalla presenza dell’interfaccia nel build.
• Il NAT è escluso oppure documentato consapevolmente.
• Device Access per IPsec in ingresso è stato verificato.
• Finestra di manutenzione, controparte e percorso di fallback sono noti.

Dopo la modifica:

• Lo stato del tunnel è established.
• È stata completata e superata una matrice di accettazione con almeno un test per direzione richiesta.
• Log Viewer mostra la regola firewall attesa.
• Packet Capture mostra direzione di andata e ritorno.
• Sono stati testati DNS interno e accessi applicativi.
• I contatori di byte aumentano in entrambe le direzioni.
• NAT e percorso di ritorno sono stati allineati con la controparte.
• La modifica è stata riportata nella documentazione di rete.

Domande frequenti