Rendere ridondante IPsec route-based con due connessioni Internet

Una seconda connessione Internet non rende automaticamente ridondante un tunnel IPsec. Un failover affidabile richiede una connessione route-based separata per ogni linea, un’interfaccia XFRM con un proprio indirizzo e un percorso di routing monitorato. Solo così Sophos Firewall può spostare in modo controllato il traffico da ISP1 a ISP2 e tornare al percorso preferito dopo il ripristino.

Questa procedura riguarda IPsec route-based Any-to-Any tra due Sophos Firewall con SFOS 22.0 e segue il design a due connessioni Internet descritto da Sophos. I tunnel policy-based e quelli route-based con Traffic Selectors specifici utilizzano invece un IPsec Failover Group.

⚠️ La guida Sophos attuale contiene un conflitto sulle due connessioni Any-to-Any. La procedura specifica per due ISP crea i tunnel senza Failover Group. Le indicazioni generali per il troubleshooting IPsec affermano invece che più connessioni con Local e Remote Subnets uguali, incluse Any-Any, funzionano solo nello stesso Failover Group. Poiché il gruppo modifica DPD e Failback, qui non si aggiunge un passaggio non documentato: collaudare il design sulla Maintenance Release SFOS 22 installata e sottoporre eventuali differenze a Sophos Support prima della produzione.

Procedura rapida

1. Collaudare separatamente su entrambi i firewall un tunnel Any-to-Any tramite ISP1 e uno tramite ISP2.
2. Assegnare un indirizzo di trasferimento univoco a ciascuna delle quattro interfacce XFRM.
3. Creare su ogni firewall un Custom Gateway con Health Check scelto consapevolmente per entrambi gli indirizzi XFRM del peer.
4. Aggiungere due route statiche verso la stessa LAN remota: Primary con Administrative Distance più bassa e Backup con valore più alto.
5. Registrare la Route Precedence globale e impostarla su static vpn sdwan_policyroute solo se compatibile con l’intero design.
6. Verificare regole firewall e percorsi di ritorno per entrambi i percorsi XFRM.
7. Interrompere ISP1 in modo controllato, testare traffico applicativo reale tramite ISP2 e quindi collaudare il Failback verso ISP1.

⚠️ Route Precedence vale per l’intero firewall. Una modifica può influire anche sui percorsi Static, VPN e SD-WAN esistenti. Prima registrare il valore attuale e tutte le route sovrapposte, creare un backup della configurazione e verificare un accesso di gestione indipendente.

Progettazione e prerequisiti

Comprendere il modello di failover

Le due connessioni IPsec rimangono tunnel indipendenti. La route con Administrative Distance inferiore è il percorso dati preferito. Se il relativo gateway XFRM monitorato viene considerato irraggiungibile, può subentrare la route attraverso il secondo tunnel.

Si tratta di due stati distinti:

• Il tunnel è attivo: IKE e Child SA sono stati stabiliti.
• Il percorso è utilizzabile: gateway, route, regola firewall, comportamento NAT previsto, peer e percorso di ritorno funzionano per il traffico reale.

Un tunnel verde da solo non prova quindi il failover. Non basta nemmeno il normale failover WAN: WAN link manager non crea una seconda connessione IPsec né una route corrispondente sul peer.

Any-to-Any non utilizza un VPN Failover Group aggiuntivo. Il percorso viene selezionato dalle interfacce XFRM indirizzate, dai gateway e dalle route. Configurare una VPN IPsec Site-to-Site spiega la configurazione di base completa di questo tunnel.

SFOS 22 consente route statiche, SD-WAN o dinamiche per le interfacce XFRM Any-to-Any. La procedura specifica per due ISP usa espressamente due route statiche. Questa procedura segue tale design; non aggiungere una route SD-WAN verso la stessa destinazione senza progettarne e collaudarne separatamente l’interazione e la priorità.

Pianificare la topologia di esempio

L’esempio collega una sede centrale a una filiale:

• Sede centrale: 172.16.16.0/24
• Filiale: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• Rete XFRM ISP1: 10.255.1.0/30
• Rete XFRM ISP2: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

Gli indirizzi sono valori di documentazione e vanno sostituiti con reti di trasferimento dedicate e non sovrapposte. Ogni coppia XFRM necessita di una rete distinta. Per ogni tunnel, gli indirizzi pubblici degli ISP, Local e Remote IDs, Profiles e Listening Interfaces devono corrispondere al peer.

Configurare tunnel, gateway e route

Preparare due tunnel

Su ogni firewall si creano due connessioni in Site-to-site VPN > IPsec. Entrambe utilizzano Route-based (Tunnel interface) e Any per Local subnet e Remote subnet. In un tipico design sede centrale-filiale, la centrale usa Respond only e la filiale Initiate the connection.

Il primo tunnel utilizza l’interfaccia WAN di ISP1, il secondo quella di ISP2. Le due connessioni vengono testate singolarmente prima di configurare il failover. A ogni test si attiva soltanto il tunnel previsto e si verifica un flusso di dati definito in entrambe le direzioni.

In Network > Interfaces, alle interfacce XFRM create automaticamente vengono assegnati questi indirizzi di esempio:

• Sede centrale: 10.255.1.1/30 per ISP1 e 10.255.2.1/30 per ISP2
• Filiale: 10.255.1.2/30 per ISP1 e 10.255.2.2/30 per ISP2

Non modificare l’indirizzo di un’interfaccia XFRM finché altre route o servizi ne dipendono. Prima di ogni modifica controllare Object usage, stato del tunnel e oggetti di routing esistenti.

Monitorare i gateway XFRM

In Routing > Gateways, su ogni lato si crea un gateway per tunnel verso l’indirizzo XFRM del peer. Nella sede centrale sono 10.255.1.2 e 10.255.2.2; nella filiale 10.255.1.1 e 10.255.2.1.

Per ogni gateway impostare almeno Name, Gateway IP e Interface. Gateway IP è l’indirizzo XFRM del peer e Interface la XFRM corrispondente. Health check è disattivato per default e va attivato per monitorare il percorso. SFOS 22 mostra quindi Interval (default 60 secondi), Time-out (2 secondi), Retries (3) e almeno una Monitoring condition con Protocol, Port per TCP e IP address.

L’IP di probe deve essere un host dietro il gateway. Per valutare l’intero percorso a valle, scegliere un endpoint stabile e consentito dietro il peer. Un ping al solo indirizzo XFRM prova solo il segmento immediato. Più condizioni possono essere combinate con AND o OR: AND richiede tutte le risposte, OR procede dall’alto fino al primo target che risponde.

La scelta di protocollo, target e intervalli è operativa: il target deve rispondere stabilmente, restare disponibile durante la normale manutenzione e avere la corretta autorizzazione. I default sono valori iniziali, non un tempo di commutazione garantito. Accettare la modifica solo dopo aver misurato rilevamento, Failover e Failback. Creare e verificare un Custom Gateway spiega Health Check, stato e condizioni di arresto.

Aggiungere route statiche Primary e Backup

Nella sede centrale, in Routing > Static routes, si aggiungono due route IPv4 Unicast verso la rete della filiale 192.168.10.0/24:

• tramite 10.255.1.2 e XFRM ISP1 con Administrative distance 1
• tramite 10.255.2.2 e XFRM ISP2 con Administrative distance 2

Nella filiale si creano specularmente due route verso la rete centrale 172.16.16.0/24:

• tramite 10.255.1.1 e XFRM ISP1 con Administrative distance 1
• tramite 10.255.2.1 e XFRM ISP2 con Administrative distance 2

L’Administrative Distance inferiore prevale finché il relativo gateway è disponibile. Reti di destinazione identiche e distanze diverse formano quindi i percorsi Primary e Backup. È diverso da ECMP con priorità uguali. Configurare e testare una route statica spiega la logica generale della route e del percorso di ritorno.

La guida Sophos specifica attribuisce a questo design Failover e Failback automatici. La documentazione generale delle route statiche conferma la priorità tramite Administrative Distance, ma non descrive separatamente come un Health Check fallito rimuova la route dalla selezione. Nel collaudo va quindi osservata la route attiva, non solo lo stato del gateway.

Impostare Route Precedence in modo controllato

Sophos documenta questo design con Static prima di VPN e SD-WAN. Innanzitutto si registra lo stato esistente nella Device Console:

system route_precedence show

Solo se quest’ordine è compatibile con l’intero design di routing, viene impostato su entrambi i firewall:

system route_precedence set static vpn sdwan_policyroute

Quindi si controlla nuovamente il valore con system route_precedence show. Questa modifica non è una soluzione generale per IPsec. Influisce anche sulle altre route Static, VPN e SD-WAN sovrapposte. Modificare Route Precedence in sicurezza spiega l’effetto globale e il rollback.

La guida SFOS 22 indica come default generale static, sdwan_policyroute, vpn, mentre la procedura specifica richiede static vpn sdwan_policyroute. Il rollback deve quindi ripristinare l’ordine esatto registrato prima con show, non applicare automaticamente il default.

Allineare regole, NAT e percorso di ritorno

Entrambi i firewall necessitano di regole adeguate tra LAN e VPN. Sorgenti, destinazioni e servizi vengono limitati alle reti e applicazioni reali delle sedi; Log firewall traffic rimane attivo durante l’introduzione.

Il traffico tra sedi normalmente instradato non richiede in genere SNAT. Se esistono già eccezioni NAT o traduzioni mirate, devono comportarsi allo stesso modo su entrambi i percorsi. Non aggiungere una regola MASQ ampia come scorciatoia per il failover.

Questo è distinto da NAT Traversal: Sophos Firewall attiva NAT-T automaticamente e usa UDP 4500 quando rileva NAT; senza NAT, IKE usa UDP 500 ed ESP il protocollo IP 50. Se un firewall è dietro un router upstream, DNAT e autorizzazioni del router devono raggiungere la Listening Interface corretta su entrambi i percorsi ISP. Reti di sede sovrapposte richiedono invece regole SNAT e DNAT per il traffico utile.

La route sul peer è importante quanto il percorso di andata. Un tunnel può essere attivo anche se la risposta torna attraverso l’ISP errato o una route più generale. Per questo si valutano insieme Route Lookup, route attiva, Firewall Rule ID, NAT Rule ID e Packet Capture.

Collaudare e gestire il failover

Collaudare Failover e Failback

Prima del test di guasto, entrambi i tunnel vengono collaudati singolarmente con lo stesso flusso applicativo. Si mantiene visibile una connessione di test continua e durante il test si aprono anche nuove sessioni.

Durante la finestra di manutenzione si interrompe in modo controllato soltanto il percorso ISP1. Non disattivare contemporaneamente entrambi i port WAN o entrambi i tunnel. Il collaudo risponde a quattro domande:

1. Il gateway ISP1 viene riconosciuto come non disponibile?
2. Diventa attiva la route con Administrative Distance 2 tramite XFRM ISP2?
3. Le nuove connessioni raggiungono il peer e le risposte tornano tramite ISP2?
4. Dopo il ripristino di ISP1 viene nuovamente usata la route con Administrative Distance 1?

In Log Viewer e in un Packet Capture ristretto devono corrispondere Firewall Rule ID prevista, interfaccia XFRM attiva e flusso bidirezionale. Un ping da solo non basta. HTTPS, RDP, VoIP o un’altra applicazione reale mostrano inoltre se funzionano creazione della sessione, MTU e percorso di ritorno. Testare una regola firewall con Log Viewer e Packet Capture spiega la procedura combinata.

In un cluster HA, dopo un Failover pianificato si testa una nuova connessione attraverso entrambi i percorsi ISP. SFOS 22 ripristina in modo trasparente i tunnel IPsec route-based, ma limita il Failover delle sessioni nel tunnel ai protocolli stateless come UDP e ICMP; TCP non è supportato. Valutare separatamente una connessione TCP esistente e una nuova. Log e report HA restano inoltre solo sul nodo che ha elaborato il traffico: controllare entrambi i dispositivi.

Delimitare sistematicamente gli errori

Entrambi i tunnel sono verdi, ma ISP2 non subentra

Controllare stato dei gateway, Monitoring Target ed entrambe le route statiche. Rete di destinazione e prefix devono essere identici, mentre Next Hops e interfacce XFRM devono essere diversi. Confrontare quindi Administrative Distance e Route Precedence corrente.

ISP2 subentra, ma le applicazioni non rispondono

Controllare regole firewall, eccezioni NAT e route di ritorno su entrambi i lati. Packet Capture deve mostrare richiesta e risposta su XFRM ISP2. Se manca solo la risposta, l’errore si trova normalmente dietro il peer o in un percorso di ritorno asimmetrico.

Il Failback avviene troppo presto o non avviene

Osservare Health Check e Monitoring Target. La destinazione non deve segnalare a intermittenza il tunnel come sano quando il percorso applicativo è ancora disturbato. Controllare insieme Administrative Distance, route attiva e una sessione realmente nuova; le connessioni esistenti possono rimanere legate allo stato precedente.

Funziona una sola direzione

Confrontare la configurazione speculare: indirizzo XFRM, gateway, route statica, regola e percorso di ritorno devono esistere su entrambi i firewall. La documentazione Sophos attuale indica /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log e /log/dgd.log; l’ultimo contiene eventi Dead Gateway Detection e VPN Failover. Nell’Advanced Shell il comando di sola lettura ip xfrm state mostra la presenza dei Transform States. Troubleshooting della VPN IPsec spiega il percorso diagnostico sicuro.

Stato del tunnel e del gateway discordanti

DPD e Gateway Health Check misurano aspetti diversi. Dead Peer Detection si configura in Profiles > IPsec profiles e rileva un peer IKE non responsivo dopo l’inattività del tunnel Phase 2; Sophos consiglia di attivarlo. Il Health Check del Custom Gateway verifica invece l’host scelto dietro il percorso XFRM. Non disattivare DPD per nascondere un probe difettoso. Se Sophos Support richiede un Failover Group per il conflitto sopra descritto, considerare che il gruppo disattiva DPD nel profilo associato, imposta Key negotiation tries a 3 e introduce un Automatic failback separato con al massimo cinque tentativi. È un modello operativo diverso, da non mescolare a questa procedura senza collaudo separato.

Eseguire un rollback sicuro

Prima della modifica si documentano backup, Route Precedence originale, stato dei tunnel, indirizzi XFRM, gateway, regole e route. Se il percorso ridondante non è affidabile:

1. Disattivare le nuove route Backup.
2. Disattivare i gateway ISP2 e il secondo tunnel invece di eliminarli immediatamente.
3. Ripristinare la Route Precedence originale su entrambi i firewall.
4. Ripristinare regole e NAT allo stato precedente documentato.
5. Testare di nuovo il percorso ISP1 originale con una nuova sessione applicativa.

Rimuovere indirizzi XFRM, gateway o tunnel solo quando Object usage non mostra più dipendenze. Backup e ripristino di Sophos Firewall spiega il processo di backup e recupero.

FAQ