Configurare VPN IPsec Site-to-Site Sophos Firewall

Una VPN IPsec Site-to-Site collega due sedi oppure un 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 di 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.

Per gli ID dell’esempio, impostare Local ID type = DNS e Remote ID type = DNS su entrambi i firewall. Nella sede centrale, inserire Local ID vpn-hq.example.invalid e Remote ID vpn-branch.example.invalid; nella filiale, invertire esattamente questi valori. Questi valori identificano i peer e non servono per la risoluzione DNS dei rispettivi indirizzi gateway. Se si utilizza un altro tipo di ID, anche il tipo e il formato devono corrispondere in modo incrociato.

Per ciascun oggetto di rete IPv4, scegliere Add, IP version = IPv4, Type = Network, inserire l’indirizzo di rete e la maschera di sottorete /24, quindi salvare. Nomi appropriati sono HQ_LAN per 10.10.10.0/24 e Branch_LAN per 10.20.20.0/24; entrambi gli oggetti sono necessari su entrambi i firewall. Un oggetto host è invece destinato a un singolo indirizzo di test o monitoring.

Assegnare alla filiale il ruolo di iniziatore distribuisce i tentativi di riconnessione tra le filiali ed è utile quando l’IP WAN della filiale cambia. Se un iniziatore deve raggiungere un peer con IP WAN dinamico, il campo Gateway address deve contenere un hostname DNS che si risolva effettivamente nell’indirizzo pubblico corrente del peer. Configurare e verificare Dynamic DNS su Sophos Firewall descrive la registrazione e il test di risoluzione. Un semplice ID DNS non è un indirizzo gateway raggiungibile. Configurare DDNS soltanto nella sede centrale non rende individuabile l’indirizzo dinamico della filiale.

⚠️ 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. Nell’esempio utilizzato in questa guida, l’indirizzo WAN del router della sede centrale può essere 198.51.100.10, mentre la WAN del firewall utilizza 172.31.255.2. In questo caso, la sede centrale seleziona la propria WAN privata come Listening interface; la filiale continua a collegarsi a 198.51.100.10, non a 172.31.255.2. Il router traduce la destinazione dal proprio indirizzo pubblico a 172.31.255.2. I selector LAN rimangono, nella sede centrale, Local 10.10.10.0/24 e Remote 10.20.20.0/24, e nella filiale esattamente l’opposto.

Per NAT-T devono essere consentiti UDP 500 e UDP 4500. Le guide SFOS 22 e SFOS 23 per un firewall dietro un router indicano anche IP protocol 50, non la porta TCP/UDP 50. Quando viene negoziato NAT-T, ESP è incapsulato in UDP 4500; ESP nativo utilizza il protocollo 50. L’elenco delle autorizzazioni sul router e la spiegazione di NAT-T non devono quindi essere interpretati come percorsi dei pacchetti identici. Prima della modifica, documentare le funzionalità del router e gli inoltri esistenti e verificare, tramite i log IKE e Packet Capture, quale percorso venga effettivamente utilizzato. Non rimuovere un’autorizzazione ESP esistente senza verificarla; limitare le autorizzazioni aggiuntive agli indirizzi dei peer pianificati. Se la negoziazione non avviene, ripristinare la configurazione del router documentata. Questo aspetto è distinto da SNAT/DNAT per LAN 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. Local certificate appartiene al firewall locale, Remote certificate alla controparte e Remote CA certificate costituisce la base di fiducia per il certificato della controparte. Non utilizzare una CA pubblica come Remote CA certificate: un attaccante con un certificato valido emesso da tale CA potrebbe altrimenti ottenere un accesso non autorizzato. Con il tipo di ID DER.ASN1 DN (X.509) viene utilizzato il Distinguished Name del rispettivo certificato; come Remote ID va inserito il DN del certificato del peer.

RSA key è un Authentication type separato, non la selezione di un certificato RSA. Il firewall genera automaticamente la coppia di chiavi e mostra sotto Local RSA key soltanto la chiave pubblica. Copiarla nel campo Remote RSA key della controparte e inserire la chiave pubblica della controparte nel campo Remote RSA key locale. Entrambi i lati devono utilizzare lo stesso formato PKCS1 o DNS. Le chiavi private non vengono trasferite tra i firewall.

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

Per questo esempio policy-based vengono selezionate reti specifiche su entrambi i lati. La documentazione SFOS 22 e SFOS 23 non è formulata in modo uniforme riguardo a Any: la panoramica Policy-based afferma che Any non può essere selezionato per le sottoreti locali e remote; la guida Add an IPsec connection consente Any al massimo su un lato. Da questa ambiguità documentale non va dedotta la possibilità di una configurazione policy-based Any-to-Any. Se è necessario utilizzare Any su un solo lato, prima dell’implementazione verificare l’opzione nel build installato, i selector della controparte e il routing previsto in una configurazione di test isolata. In caso di SA o associazione del traffico inattese, disattivare la nuova connessione e ripristinare i selector specifici documentati. Con più reti locali e remote specifiche viene creata una Phase 2 SA per ogni combinazione: due reti locali e due reti remote producono quattro SA. Tutte le connessioni policy-based condividono un’unica interfaccia IPsec; pertanto, una cattura su questa sola interfaccia non identifica il tunnel.

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.

Con Authentication type = Preshared key, inserire la PSK concordata e ripeterla nel campo di conferma. Sulla controparte, inserire esattamente la stessa PSK e confermarla anche lì; gli ID speculari non modificano la chiave condivisa. Scambiare la PSK solo tramite il canale sicuro previsto e non includerla in screenshot o ticket pubblici.

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.

Senza Activate on save, la connessione salvata viene attivata tramite il relativo pulsante Status in Site-to-site VPN > IPsec. Questa operazione va distinta da Gateway type = Disable: in tal caso la connessione rimane inattiva finché non viene avviata dall’utente. Respond only attende le richieste; Initiate the connection avvia la negoziazione anche dopo un riavvio del servizio VPN o del firewall. Dopo un semplice Disconnect, un iniziatore può riconnettersi; per il rollback è quindi necessario anche disattivare la connessione.

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.

API XML: separare configurazione e azioni di controllo

Per automatizzare questa procedura, non basta tradurre i campi della GUI in una richiesta XML. La documentazione API di SFOS 22 e SFOS 23 mostra le impostazioni sotto VPNIPSecConnection/Configuration e, separatamente, i rami di controllo Active, DeActive, Connection e DisConnection, ciascuno con Name. Il commento dell’esempio precisa che questi quattro rami funzionano solo dopo la creazione della connessione. L’esempio di configurazione contiene inoltre Status con Active/Deactive; la riga di ActivateOnSave indica y/n. Salvataggio, attivazione, comportamento dopo un riavvio e tunnel effettivamente stabilito non sono quindi impostazioni intercambiabili né dimostrano che una richiesta API sia eseguibile.

Questa rappresentazione precedente contiene anche contraddizioni tra l’esempio e le righe dei parametri:

• Nell’esempio, AliasLocalWANPort segue un commento relativo a una porta WAN alias, ma la tabella lo definisce come ARRAY obbligatorio. Anche Name e RemoteHost sono indicati come ARRAY; ciò non definisce né una serializzazione sicura di più valori né il loro abbinamento a coppie.
• L’esempio di UserAuthenticationMode mostra AsServer/AsClient, mentre la riga indica EnableAsServer/EnableAsClient. Per DisconnectOnIdleInterval, il valore predefinito 0 è fuori dall’intervallo dichiarato 120..21600; 600 è solo il valore dell’esempio. Non uniformare silenziosamente queste differenze né adottare questi valori come predefiniti di IKEv2.
• Il vecchio campo AllowNATTraversal con Enable/Disable non dimostra l’esistenza di un interruttore NAT-T attuale. La riga di RemoteHost vieta * con RSAKey; è una restrizione di quella documentazione, non una regola generale di funzionamento della GUI confermata qui.

Finché la rappresentazione API del build installato non è chiara, utilizzare la procedura WebAdmin descritta sopra e chiarire i dubbi prima di automatizzarla. Per la procedura GUI, il rilevamento automatico di NAT-T e le indicazioni su IKEv2, RSA e ID restano invariati per la procedura GUI descritta.

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. Le guide SFOS 22 e SFOS 23 descrivono un’interfaccia XFRM generata anche con Traffic Selectors specifici; a differenza di Any-to-Any, non deve ricevere un indirizzo IP né una route assegnata manualmente. Prima di una migrazione, documentare la versione SFOS installata, l’associazione dell’interfaccia e la route effettivamente generata.

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 determinano 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.

Per l’alternativa SD-WAN, sotto Routing > SD-WAN routes scegliere IPv4 e Add. Nella sede centrale impostare Source networks = HQ_LAN, Destination networks = Branch_LAN e, sotto Link selection settings, selezionare Primary and backup gateways. In Primary gateway > Add, scegliere 10.255.0.2 come Gateway IP e l’interfaccia XFRM locale con 10.255.0.1/30 come Interface. Nella filiale, invertire Source/Destination, utilizzare Gateway IP 10.255.0.1 e l’interfaccia XFRM locale con 10.255.0.2/30. Per Health check, sotto Monitoring condition, scegliere un host interno della controparte che risponda effettivamente, ad esempio 10.20.20.15 nella filiale o 10.10.10.25 nella sede centrale. Anche la sonda deve essere consentita e utilizzare il tunnel previsto. Per la selezione basata su SLA, selezionare un profilo SD-WAN con i gateway del tunnel. La route statica e la route SD-WAN sono qui alternative; non crearle entrambe come percorsi concorrenti senza averne verificato gli effetti. Prima della modifica, documentare la Route Precedence e le regole esistenti e, in caso di rollback, ripristinare la selezione precedente della route e del gateway.

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

Per subnet specifiche, le guide SFOS 22 e SFOS 23 esaminate descrivono un’interfaccia XFRM per ogni configurazione IPsec. In Network > Interfaces, espandere la Listening interface tramite l’indicatore blu. Non assegnare all’interfaccia generata né un indirizzo IP né una route manuale: la route statica viene creata automaticamente quando il tunnel è established. Nella sede centrale scegliere Local HQ_LAN e Remote Branch_LAN; nella filiale scegliere Local Branch_LAN e Remote HQ_LAN. Gateway, profilo, autenticazione e ID vengono configurati in modo speculare come nelle altre varianti. Con route-based, Any su un solo lato e un selector specifico sull’altro non sono supportati. Se l’interfaccia documentata manca nel build installato, chiarire prima configurazione, versione e log; non tentare di creare un’interfaccia XFRM sostitutiva o di imporre un indirizzamento Any-to-Any.

Questa variante è adatta a reti piccole e chiaramente definite; Sophos la consiglia rispetto a policy-based, anche per connessioni compatibili con terze parti. Utilizzare l’interfaccia XFRM in Diagnostics > Packet capture per identificare il traffico in uscita; verificare inoltre la route automatica, ogni Child SA prevista, i log e il traffico in entrambe le direzioni. WAF tramite IPsec route-based con Traffic Selectors non è supportato; a tale scopo è possibile valutare una configurazione route-based Any-to-Any appropriata. Se la migrazione fallisce, disattivare la nuova connessione e soltanto le sue nuove regole, quindi riattivare la connessione precedente documentata.

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 generate si trovano nel gruppo Automatic VPN rules. Nell’esempio, per il traffico in uscita la sede centrale consente Source zone LAN, Source network HQ_LAN, Destination zone VPN, Destination network Branch_LAN; per il traffico in ingresso, zone e reti vengono invertite. Nella filiale si applica la stessa configurazione speculare, con Branch_LAN come rete locale. Limitare in ogni caso Services alle porte applicative autorizzate e attivare Log firewall traffic. È possibile aggiungere le reti Source/Destination corrette a regole esistenti appropriate, anziché creare nuove regole per ogni tunnel. Prima di farlo, verificare l’impatto su tutte le altre connessioni gestite dalla stessa regola. SFOS valuta le regole dall’alto verso il basso e si ferma alla prima corrispondenza; una nuova regola all’inizio dell’elenco può quindi prevalere sulle restrizioni precedenti.

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

Per il NAT all’interno della connessione IPsec, attivare Network Address Translation (NAT). Translated subnet mostra la rete locale tradotta selezionata nella connessione; sotto Original subnet, selezionare la rete locale sovrapposta effettiva. Per le reti senza traduzione, lasciare impostato Not translated. Prima del salvataggio, confrontare in una tabella la rete originale, la rete tradotta, il Remote selector del peer e l’indirizzo di destinazione DNS. Non dedurre la direzione soltanto dai nomi dei campi; la procedura NAT collegata contiene l’esempio completo. Con Any-to-Any, non utilizzare questi campi in sostituzione di regole SNAT/DNAT separate.

⚠️ Con IPsec route-based e Traffic Selectors, usare l’impostazione NAT nella connessione IPsec e non assegnare un indirizzo IP o una route manuale all’interfaccia XFRM mostrata dal build installato. 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 non è un passaggio standard, ma può essere rilevante per determinati scenari di traffico inoltrato. Per le richieste di autenticazione generate dal sistema, i testi della guida Sophos per SFOS 22 e SFOS 23 sono in contraddizione: la panoramica Routing/NAT afferma che questo traffico non richiede il comando; la procedura di autenticazione descrive invece un’eccezione policy-based quando la Route Precedence selezionata non invia il traffico nel tunnel. Da ciò non deriva né la necessità di una route aggiuntiva per tutto il traffico di sistema né una modifica indiscriminata della Route Precedence globale.

Prima di una modifica, l’indirizzo sorgente, sys-traffic-nat, i Traffic Selectors e il percorso di ritorno devono essere coerenti con il flusso di pacchetti effettivamente osservato. La guida esistente alle route IPsec e la procedura per le richieste di autenticazione generate dal sistema spiegano le verifiche mirate con una richiesta reale e Packet Capture, nonché il rollback separato per NAT e route. Se il comportamento nel build installato rimane poco chiaro, occorre chiarirlo con Sophos Support prima di una modifica in produzione. 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.

Se un peer deve eseguire un ping verso il firewall stesso attraverso il tunnel, consentire la zona VPN sotto Ping/Ping6 e scegliere Apply. Non si tratta di un passaggio globale necessario per eseguire un ping verso un host LAN: in quel caso contano le regole di transito appropriate e il firewall dell’host. Abilitare soltanto il servizio locale necessario per il test, documentarne l’impostazione originale e ripristinarla dopo il test, salvo che l’autorizzazione sia necessaria in modo permanente. Inoltre, un ping dalla shell del firewall utilizza un indirizzo sorgente diverso da quello di un client LAN; non considerare i due test come verifiche equivalenti della regola del client.

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 vengono mostrate soltanto le connessioni effettivamente stabilite. I filtri disponibili sono Connection name, Local server name, Local subnet, Username, Remote server/host e Remote subnet; Refresh aggiorna la vista. 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 disattivazione o il rollback 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.

Per l’esempio utilizzato in questa guida, dal client LAN 10.10.10.25 testare un host della filiale effettivamente esistente, 10.20.20.15, non l’indirizzo di rete 10.20.20.0. Su Windows, ping 10.20.20.15 -t avvia un test continuo; terminarlo con Ctrl+C. Sotto Diagnostics > Packet capture > Configure, impostare come BPF string host 10.10.10.25 and host 10.20.20.15 and proto ICMP, salvare e attivare la cattura. Con route-based, verificare l’uscita sull’interfaccia XFRM associata e i pacchetti di ritorno. Nel Log viewer, cercare l’indirizzo effettivo del client; tramite la Firewall rule ID e Filter firewall rule, aprire la regola corrispondente. Successivamente, testare anche una porta applicativa pianificata e la direzione opposta. Disattivare nuovamente la cattura e rimuovere filtri e autorizzazioni temporanei; una cattura continua non costituisce monitoring operativo. Dietro un router, verificare inoltre nei log di entrambi i peer che il NAT sia stato rilevato e che NAT-T sia stato negoziato.

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 l’interfaccia XFRM documentata sotto la Listening interface, la route automatica, ogni Child SA prevista, i Selectors, le regole della zona VPN ed eventuale regola MASQ. Utilizzare l’interfaccia XFRM per Packet Capture, ma non assegnarle né un indirizzo IP né una route manuale. Se manca, chiarire il build e la configurazione anziché creare un’interfaccia sostitutiva.
• 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 l’interfaccia XFRM generata; 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.

Rimuovere una specifica connessione salvata

Eliminare una connessione IPsec salvata è diverso da Disconnect, dalla disattivazione o dall’eliminazione di un gruppo di failover. Prima di una rimozione autorizzata separatamente, documentare il Name esistente esatto, Object Usage, le appartenenze ai gruppi e un accesso di gestione indipendente dal tunnel. Non eliminare una connessione finché appartiene a un gruppo di failover; la procedura di failover collegata descrive la rimozione controllata dell’associazione.

La documentazione di eliminazione dell’API XML per SFOS 22 e SFOS 23 definisce Name come ARRAY obbligatorio con tipo STRING: primo carattere A-Za-z, successivi A-Za-z0-9_, massimo 100 caratteri, più valori consentiti. Non contiene però un esempio di richiesta. Non dedurre un serializzatore per più nomi né un nome di destinazione dall’esempio GUI branch-zurich; non riscrivere un nome salvato per renderlo apparentemente conforme.

La documentazione associa lo stato dell’operazione XML 200 a Message.IPSecDeleteSuccess, 201 a Message.IPSecConnInUse e 500 a Message.IPSecDeleteFail. I testi dei messaggi vengono inseriti tramite JavaScript e non sono risolti qui: non sono codici di stato HTTP né testi di risposta visualizzati e confermati. Non considerare 201 un’eliminazione riuscita solo perché inizia con 2; per Edit, lo stesso numero corrisponde a Message.IPSecUpdated. Dopo una rimozione autorizzata, rileggere esattamente la connessione interessata e verificare i percorsi produttivi rimasti. Se il risultato è incerto, chiarire lo stato della connessione interessata e le dipendenze prima di riprovare, senza ripetere alla cieca.

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 sono state documentate la versione SFOS installata, la visibilità effettiva e l’associazione dell’interfaccia XFRM generata e la route automatica effettiva; indipendentemente dalla visualizzazione dell’interfaccia, non sono previsti indirizzi IP XFRM o route manuali. Se l’interfaccia documentata manca, occorre chiarire versione, configurazione e log prima di procedere.
• 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