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. I tunnel policy-based e i tunnel route-based con Traffic Selectors specifici utilizzano invece un IPsec Failover Group.

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 gateway monitorato 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.

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.

Come Interface si seleziona la relativa XFRM. Se si deve valutare l’intero percorso a valle, il Monitoring Target dovrebbe essere un endpoint stabile e consentito dietro il peer. Un ping al solo indirizzo XFRM del peer prova soltanto il segmento immediato del tunnel.

La scelta della destinazione è una decisione operativa: deve rispondere in modo stabile, non deve scomparire durante la normale manutenzione e necessita della corretta autorizzazione. Creare e verificare un Custom Gateway spiega in dettaglio 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.

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.

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.

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. Un tunnel attivo non garantisce che le sessioni TCP esistenti o gli stati di routing continuino senza interruzioni.

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. strongswan.log e xfrmi.log aiutano per i livelli IKE e XFRM; Troubleshooting della VPN IPsec spiega il percorso diagnostico sicuro.

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