Configurare e testare un IPsec Failover Group su Sophos Firewall

Un IPsec Failover Group ordina più connessioni IPsec Site-to-Site in base alla priorità. Se il tunnel primario si interrompe, Sophos Firewall attiva la connessione disponibile successiva. Affinché il passaggio sia realmente utile, entrambi i tunnel devono però funzionare già singolarmente e coprire le stesse reti di produzione, regole, condizioni NAT e route di ritorno.

Procedura breve: testare singolarmente due connessioni IPsec, verificare i Remote IDs e l’ordine, riunirle in un gruppo in Site-to-site VPN > IPsec > Failover group, scegliere una Failover Condition adatta e quindi collaudare Failover e Failback con un flusso di test definito.

La guida presuppone una configurazione IPsec Site-to-Site esistente. Spiega il controllo della ridondanza senza ripetere l’intera configurazione del tunnel.

Quando è adatto un IPsec Failover Group

Il gruppo è indicato soprattutto per IPsec Policy-based e IPsec Route-based con Traffic Selectors specifici. Più connessioni con Local e Remote subnets identiche devono appartenere allo stesso Failover Group oppure utilizzare Selectors chiaramente differenti. In caso contrario, i tunnel possono interferire tra loro.

Con Route-based Any-to-Any la scelta è diversa: le interfacce XFRM ricevono indirizzi di trasferimento, mentre route statiche, dinamiche o SD-WAN Routes determinano il percorso dei dati. Più XFRM Gateways possono essere prioritizzati direttamente tramite un SD-WAN Profile e controlli SLA. Per questo design non serve un VPN Failover Group aggiuntivo.

Anche un normale WAN Failover non sostituisce il gruppo. WAN link manager può cambiare la connessione Internet, ma non crea una seconda connessione IPsec con una propria Gateway Address, Listening Interface e configurazione del peer.

Un FQDN con più indirizzi WAN non è un failover

Se lo stesso record DNS A punta contemporaneamente all’indirizzo WAN primario e a un indirizzo attivo solo durante un guasto, il peer remoto può selezionare anche l’indirizzo inattivo. DNS round robin non conosce né lo stato WAN né lo stato del tunnel. Un IPsec Failover Group locale non corregge automaticamente questa selezione DNS remota.

Per i tunnel avviati dal peer remoto sono quindi necessarie due connessioni configurate esplicitamente oppure un FQDN il cui DNS basato sullo stato o aggiornamento DDNS punti solo all’indirizzo attualmente raggiungibile. Se non è possibile controllare né la configurazione del peer né l’aggiornamento DNS, la progettazione deve fermarsi a questo punto. Due indirizzi pubblicati contemporaneamente non devono essere considerati un failover testato.

Un VPN Failover Group è inoltre diverso da un cluster HA. Il gruppo passa da un tunnel all’altro, mentre HA passa da un nodo firewall all’altro. In un ambiente critico, gli errori WAN, VPN e i possibili errori HA devono quindi essere pianificati e testati separatamente.

Che cosa monitora il gruppo

Sophos Firewall controlla il peer tramite la Failover condition del gruppo. L’intervallo deriva dal valore globale Gateway failover time-out in:

Network > WAN link manager

Lo stesso valore influisce anche sul monitoraggio generale dei WAN Gateways. Non deve quindi essere modificato per un solo tunnel VPN. Un valore breve reagisce più velocemente, ma una perdita di pacchetti momentanea può causare un passaggio inutile. Un valore lungo tollera più a lungo i problemi, ma prolunga l’interruzione prima dello switch.

L’Health Check conferma soltanto che il peer remoto risponde alla condizione Ping o TCP selezionata. Non dimostra che DNS, un’applicazione aziendale, NAT, Routing e l’intero percorso di ritorno funzionino. Questi elementi vengono testati separatamente dopo lo switch.

Preparare due tunnel per il gruppo

Nell’esempio seguente, due tunnel collegano una sede centrale a una filiale:

• Sede centrale: 10.10.0.0/16
• Filiale: 10.20.0.0/16
• Connessione primaria: HQ-Branch-ISP1
• Connessione secondaria: HQ-Branch-ISP2
• Indirizzo del Peer primario: 198.51.100.20
• Indirizzo del Peer secondario: 203.0.113.20
• Remote ID comune della filiale: 10.255.255.2
• Failover Group: HQ-Branch-Zurich

Gli indirizzi 198.51.100.0/24 e 203.0.113.0/24 sono reti di documentazione e devono essere sostituiti con gli indirizzi pubblici reali dei Peer. Anche reti, nomi e Remote ID sono valori di esempio. Ciò che conta è il principio: le Gateway addresses possono essere differenti, mentre l’indirizzo IP del Remote ID deve essere uguale per tutti i membri del gruppo. Sul peer, questo Remote ID deve corrispondere al relativo Local ID.

Prima di raggrupparle, testare singolarmente entrambe le connessioni:

1. Entrambe le connessioni sono attive in Site-to-site VPN > IPsec.
2. Ogni connessione può essere stabilita singolarmente e trasporta lo stesso flusso di test definito.
3. Local e Remote subnets o Traffic Selectors rispecchiano la configurazione del peer.
4. Le regole firewall consentono il traffico necessario attraverso la zona VPN in entrambe le direzioni.
5. NAT è identico su entrambi i percorsi ed è configurato consapevolmente.
6. Il peer dispone di una route di ritorno attraverso entrambi i tunnel.
7. I Profiles corrispondono al relativo peer. IPsec Profiles su Sophos Firewall spiega DPD, Rekeying e Lifetimes.
8. Sono disponibili un accesso amministrativo alternativo e una finestra di manutenzione.

⚠️ L’aggiunta a un Failover Group interrompe le connessioni già stabilite. La modifica non deve essere eseguita durante una sessione remota non presidiata o senza un percorso di ripristino testato.

Una connessione può appartenere a un solo Failover Group. Non può essere eliminata finché è assegnata a un gruppo. Le connessioni IPsec Remote Access non possono essere utilizzate come membri.

Scegliere una Failover Condition adatta

Sophos supporta Ping o TCP con una porta definita. La condizione deve essere consentita consapevolmente su entrambi i firewall:

• Ping: è semplice da verificare, ma richiede Ping/Ping6 per la zona WAN in Administration > Device access. Con indirizzi Peer fissi, una Local Service ACL Exception limitata è preferibile a un’autorizzazione inutilmente ampia. Device Access e Local Service ACL illustra la configurazione sicura.
• TCP 22: richiede SSH attraverso la zona VPN. Non si deve aprire SSH sulla WAN a questo scopo. Un servizio di gestione non è un buon Health Check generale se deve essere esposto solo per il monitoraggio.
• Altra porta TCP: richiede regole firewall in ingresso e in uscita adeguate. Il servizio deve essere sempre disponibile e non deve dipendere esclusivamente dallo stato di un’applicazione qualsiasi.

La condizione deve rappresentare un servizio di risposta o un percorso stabile del peer remoto. Se il servizio usato per TCP non risponde a causa di manutenzione, di un guasto locale o di un Host Firewall, il gruppo può effettuare lo switch anche se il percorso IPsec è ancora disponibile.

Configurare l’IPsec Failover Group

Il percorso di menu è:

Site-to-site VPN > IPsec > Failover group > Add

1. Inserire un Name univoco, nell’esempio HQ-Branch-Zurich.
2. In Member connections, selezionare almeno due connessioni IPsec Site-to-Site attive.
3. Disporre le connessioni nell’ordine desiderato: prima HQ-Branch-ISP1, quindi HQ-Branch-ISP2. La prima connessione è il tunnel primario.
4. Attivare Mail notification se si desidera ricevere una notifica email quando cambia il tunnel. I Notification settings e le notifiche VPN devono già funzionare.
5. Attivare Automatic failback se il gruppo deve tornare al tunnel preferito dopo il ripristino.
6. Definire una Failover condition adatta con Ping o TCP e una porta.
7. Salvare con Save.
8. Attivare l’interruttore di stato del gruppo. Solo a questo punto il gruppo è attivo e tenta di stabilire la connessione primaria.

Se sono coinvolti due Sophos Firewall, occorre verificare su entrambi i lati le proprietà delle connessioni, l’ordine dei membri, i Remote IDs e le autorizzazioni dell’Health Check. Un gruppo corretto su un solo lato non sostituisce una configurazione coerente sul peer.

Che cosa succede a DPD e Key negotiation tries

Non appena una connessione diventa membro del gruppo, SFOS disattiva Dead Peer Detection per questa connessione e imposta effettivamente Key negotiation tries su 3. La Failover Condition assume il monitoraggio. I valori mostrati nella sola vista del Profile non rappresentano quindi l’intero comportamento effettivo.

Dopo la rimozione dal gruppo, la connessione utilizza nuovamente i valori DPD e Key-negotiation del proprio IPsec Profile. Questo è importante durante il Rollback: un tunnel può comportarsi diversamente dopo la rimozione del gruppo, anche se il Profile non è stato modificato.

Testare Failover e Failback in modo controllato

Prima del test di interruzione si definisce un flusso di dati specifico, ad esempio:

• Source: 10.10.10.25
• Destination: 10.20.20.15
• Service: TCP 443
• Regola firewall prevista: HQ-to-Branch-HTTPS

Il test viene quindi eseguito in una sequenza chiara:

1. Documentare lo stato del gruppo, l’ordine dei membri, il Firmware Build e Gateway failover time-out.
2. Verificare il tunnel primario su entrambi i lati in WebAdmin. Confermare con traffico HTTPS reale che funzionino sia l’andata sia il ritorno.
3. Registrare lo stato nell’Advanced Shell con ipsec statusall.
4. Durante la finestra di manutenzione, interrompere in modo controllato il percorso WAN o Upstream primario. Non disattivare l’intero Failover Group, perché in questo modo vengono disattivati tutti i tunnel attivi del gruppo.
5. Osservare per un tempo superiore al Gateway failover time-out configurato e annotare il momento dello switch.
6. Verificare che venga stabilito HQ-Branch-ISP2 e che lo stesso test HTTPS funzioni in entrambe le direzioni.
7. Controllare la regola firewall, NAT, la route di ritorno e il funzionamento dell’applicazione. Un tunnel verde da solo non è un criterio di successo.
8. Ripristinare il percorso primario e osservare Automatic failback.
9. Dopo il ritorno, ripetere lo stesso test e documentare l’interruzione effettivamente misurata.

Le sessioni TCP esistenti possono interrompersi durante il passaggio. Il nuovo tunnel utilizza Security Associations differenti e può passare attraverso un altro indirizzo pubblico. L’applicazione deve quindi spesso stabilire una nuova sessione. Il Failover IPsec migliora la disponibilità, ma non garantisce una sessione senza interruzioni.

Automatic failback termina dopo cinque tentativi falliti

Quando il peer primario torna raggiungibile, SFOS tenta fino a cinque volte di ripristinare la connessione preferita se Automatic failback è attivo. Se i tentativi non riescono, il tunnel secondario rimane attivo. Il firewall non continua a verificare il tunnel primario all’infinito; un nuovo ritorno avviene solo se il percorso secondario si interrompe.

È possibile disattivare e riattivare manualmente il gruppo per avviare un altro tentativo di stabilire la connessione primaria. Questa operazione causa tuttavia downtime e non è un innocuo comando di aggiornamento. Prima occorre controllare Logs, peer, Profile, IDs e percorso.

Leggere i Logs senza modificare la configurazione

dgd.log è importante per la decisione del gruppo, mentre strongswan.log riguarda l’effettiva negoziazione IPsec. I comandi seguenti vengono eseguiti nell’Advanced Shell e non modificano la configurazione:

tail -n 200 /log/dgd.log
tail -n 200 /log/strongswan.log
ipsec statusall

Se necessario, si aggiungono charon.log, ipsec_monitor.log e l’Action Log specifico della connessione. Nell’ultima riga, sostituire HQ-Branch-ISP1 con il nome effettivo della connessione:

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
tail -n 200 /log/ipsec_conn/ipsec_HQ-Branch-ISP1.log

Confrontare i timestamp in dgd.log, lo stato IPsec, l’evento WAN e il test dell’applicazione. Un Health Check fallito senza un corrispondente errore del tunnel o dell’applicazione non dimostra ancora un’interruzione del provider. Il percorso di diagnosi completo è descritto in Troubleshooting IPsec VPN su Sophos Firewall.

Errori frequenti e ritorno sicuro

Il gruppo non si attiva correttamente

Devono essere selezionate e attive almeno due connessioni. Verificare se una connessione appartiene già a un altro gruppo, è stata creata come Remote Access o utilizza un Remote ID differente. Quindi testare nuovamente entrambi i tunnel singolarmente prima di riattivare il gruppo.

Il tunnel secondario è verde, ma il traffico non funziona

Probabilmente la logica del gruppo ha funzionato, ma non il percorso dei dati. Controllare le regole firewall, NAT, Local e Remote subnets, le route automatiche o manuali e il percorso di ritorno sul peer. Il tunnel secondario deve poter trasportare lo stesso flusso di test di produzione del primario.

Il gruppo effettua lo switch troppo presto o troppo tardi

Controllare insieme la Failover Condition e Gateway failover time-out. Un target Ping o TCP instabile può provocare passaggi inutili. Un Timeout globale lungo ritarda anche altri controlli Gateway che dipendono dallo stesso valore. Non modificare soltanto il numero, ma documentare la causa, la perdita di pacchetti e il tempo effettivo dello switch.

L’ordine è errato dopo il Drag-and-drop

Sophos conferma il problema NC-178121 in SFOS 22.0 GA: dopo una modifica tramite Drag-and-drop, le connessioni IPsec Site-to-Site potevano trovarsi nella posizione sbagliata all’interno del Failover Group. Questo specifico problema è stato corretto in SFOS 22.0 MR2 Build 546.

Su SFOS 22.0 GA occorre documentare l’ordine prima e dopo ogni modifica e non affidarsi soltanto allo spostamento visivo. La Release Note pubblica non indica un limite separato e inequivocabile relativo alle versioni interessate o alla correzione per MR1. Se un problema simile si presenta in MR2 Build 546 o versioni successive, non deve continuare a essere attribuito automaticamente a NC-178121.

Rimuovere il gruppo

La disattivazione di un Failover Group disattiva i tunnel attivi dei suoi membri. Le connessioni singole necessarie devono poi essere riattivate separatamente. Per un Rollback controllato:

1. Registrare lo stato iniziale, l’ordine dei membri e i Profiles utilizzati.
2. Confermare la finestra di manutenzione e un accesso amministrativo alternativo.
3. Disattivare il gruppo e documentare l’interruzione.
4. Rimuovere le connessioni dal gruppo oppure ripristinare l’assegnazione originale.
5. Attivare la connessione singola necessaria.
6. Considerare nuovamente il comportamento DPD e Key-negotiation del Profile.
7. Verificare lo stesso flusso di test, i Logs e il percorso di ritorno.

Gestione operativa

• Ripetere i test di Failover e Failback dopo modifiche a Firmware, provider, peer, Routing, NAT o Profile.
• Documentare l’ordine dei membri, i Remote IDs, i Profiles, la condizione dell’Health Check e il Timeout globale.
• Utilizzare Mail notification solo come avviso; il collaudo tecnico richiede comunque stato, Logs e traffico reale.
• Includere entrambi i tunnel nel Monitoring, nel piano di manutenzione e nella documentazione del peer.
• Verificare che il provider secondario supporti le stesse Allowlists, dipendenze NAT e raggiungibilità pubbliche.
• Disattivare e riattivare manualmente il gruppo solo con un’interruzione pianificata.

FAQ