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

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.

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:

⚠️ 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. Per design route-based dipende dalla zona a cui è assegnata l’interfaccia XFRM o il percorso rilevante.

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:

⚠️ 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

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.

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

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.

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

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:

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.

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.

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

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.

Domande frequenti