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 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. Nelle versioni attuali di SFOS questi termini sono separati più chiaramente rispetto alle guide meno recenti, che talvolta parlano ancora di Site-to-Site o Tunnel Interface.

• IPsec policy-based: adatto a connessioni semplici tra sedi con reti locali e remote ben definite. Il controllo avviene principalmente tramite le sottoreti locali e remote nella connessione IPsec e tramite le regole firewall. Sophos crea singoli tunnel Phase 2 per ogni combinazione di sottoreti locali e remote.
• IPsec route-based con Traffic Selectors: utilizza anch’esso sottoreti locali e remote, ma crea un’interfaccia XFRM dedicata. Sophos genera automaticamente la route; all’interfaccia XFRM non devono essere assegnati né un indirizzo IP né route proprie. WAF non è supportato con questa variante.
• IPsec route-based Any-to-Any: è la variante più flessibile per reti in crescita, SD-WAN, routing dinamico e design dual-stack. In questo caso sono le route e le regole firewall, non le sottoreti della connessione IPsec, a decidere quali pacchetti entrano nel tunnel.

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.

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.

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

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.

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.

Se la CA revoca certificati prima della scadenza, anche l’elenco di revoca aggiornato deve far parte del piano operativo. La procedura separata descrive l’importazione della CRL, nextUpdate e il 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 IPsec_IKEv2_AES256_G14. 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.

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.

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 dal percorso dati tramite un’interfaccia XFRM dedicata. L’indirizzamento e il routing manuale di questa interfaccia dipendono dalla variante scelta.

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

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

Network > Interfaces

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

Any-to-Any e Dual

Se entrambe le sottoreti sono impostate su Any oppure viene usato Dual, l’interfaccia XFRM riceve un indirizzo IP di trasferimento. Serve quindi una route statica, una SD-WAN Route o una route dinamica tramite BGP oppure OSPF. Con Dual sono necessarie regole firewall IPv4 e IPv6 separate.

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.

Dopo il salvataggio verificare tre punti:

1. L’interfaccia XFRM è visibile in Network > Interfaces e dispone dell’indirizzo IP di trasferimento pianificato.
2. La route verso la rete remota punta direttamente all’interfaccia XFRM o, in un design Gateway/SD-WAN, al XFRM Gateway appropriato.
3. Le regole firewall consentono soltanto le direzioni e i servizi pianificati.

Traffic Selectors

Con Local subnet e Remote subnet specifiche, Sophos crea ugualmente un’interfaccia XFRM, ma non è consentito assegnarle né un indirizzo IP né route proprie. La route statica viene creata automaticamente quando il tunnel è established. Any su un solo lato e un Selector specifico sull’altro non sono supportati.

Questa variante è adatta a reti piccole e chiaramente definite e facilita la diagnostica XFRM. WAF tramite IPsec route-based con Traffic Selectors non è tuttavia 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.

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

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

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, l’interfaccia XFRM non ha un indirizzo IP. Se questo traffico corrisponde a una regola MASQ-SNAT, il firewall scarta i pacchetti. Per le reti sovrapposte utilizzare quindi l’impostazione NAT nella connessione IPsec e assicurarsi che nessuna regola MASQ-SNAT intercetti questo traffico.

A partire da SFOS 22, IPsec policy-based crea la route VPN nel backend. Una ipsec_route manuale è rilevante solo per determinati flussi tradotti e inoltrati e non è un passaggio standard; il traffico generato dal sistema non ne ha bisogno. Ulteriori nozioni fondamentali sul NAT sono disponibili 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.

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: non configurare IP o route manuali sull’interfaccia XFRM. Verificare 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.

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 non sono previsti IP o route manuali sull’interfaccia XFRM.
• 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.
• È definita una matrice di accettazione con almeno un test per ogni direzione necessaria.
• 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