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 un design Route-based Any-to-Any interamente controllato dal routing, la scelta è diversa: le interfacce XFRM ricevono indirizzi di trasferimento, mentre route statiche, dinamiche o SD-WAN Routes determinano il percorso dei dati. Per questo design, Sophos documenta più gateway XFRM con un SD-WAN Profile e controlli SLA senza un ulteriore gruppo di failover VPN. Al di fuori di questo design, Sophos avverte però che più connessioni Any-to-Any con selettori identici devono appartenere allo stesso gruppo di failover.

Rendere ridondante IPsec route-based con due connessioni Internet spiega il design completo con due provider, gateway XFRM separati, route statiche Primary e Backup e un test di failover controllato.

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.

system link_failover è un meccanismo CLI separato

SFOS 22 pubblica inoltre un comando Device Console che aggiunge un tunnel VPN o GRE come backup di un Primary Link. La grammatica pubblicata è:

system link_failover add [primarylink] [portname] [backuplink] [vpn] [gre] [tunnel] [tunnelname] [monitor PING host] [monitor TCP host] [ipaddress] [portnumber]

Con monitor TCP host va indicata la porta TCP da controllare; monitor PING host non usa una porta. Il target non deve soltanto rispondere, ma rappresentare in modo utile il percorso rilevante. Un monitor riuscito non dimostra che funzionino applicazione, regola, route o percorso di ritorno.

Questo comando non equivale al gruppo di failover IPsec configurato in WebAdmin né al design XFRM e SD-WAN. La pagina pubblica di SFOS 22 documenta solo add: non fornisce comandi di stato, eliminazione o ripristino e non spiega l’interazione con route o policy SD-WAN esistenti. Senza un metodo di ripristino confermato per la build installata, non si tratta di una procedura da copiare e incollare. Per le nuove configurazioni, i metodi WebAdmin o XFRM documentati sono un punto di partenza più chiaro.

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. In alternativa, si può usare un FQDN il cui DNS tenga conto dello stato di salute oppure che un aggiornamento DDNS faccia puntare solo all’indirizzo attualmente raggiungibile. Se non è possibile controllare né il peer né l’aggiornamento DNS, questo design non offre un failover in ingresso affidabile. Due indirizzi pubblicati contemporaneamente non costituiscono 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. Sophos documenta questa autorizzazione di zona come prerequisito. Con indirizzi peer fissi, una Local Service ACL Exception limitata può essere valutata come misura di hardening; deve corrispondere all’indirizzo sorgente realmente utilizzato dal peer. Device Access e Local Service ACL illustra la configurazione.
• 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. Solo le connessioni attive partecipano al failover; attivare e testare singolarmente ogni membro previsto prima di mettere in servizio il gruppo.
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 per ricevere notifiche in caso di errore della connessione. 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 usa 3 per Key negotiation tries. La Failover condition assume il monitoraggio.

Dopo la rimozione dal gruppo, la connessione utilizza nuovamente i valori DPD e Key negotiation del proprio IPsec Profile. Includere questo comportamento nel test di ripristino anche se il profilo 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 falliscono, 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. Se il gruppo contiene più di due connessioni, SFOS torna alla prima connessione disponibile nell’ordine Member connections.

È possibile disattivare e riattivare manualmente il gruppo per avviare un altro tentativo di stabilire la connessione primaria. Questa operazione causa un’interruzione. Prima controllare log, peer, profilo, identificatori 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, aggiungere charon.log e il log delle azioni specifico della connessione. Le pagine ufficiali di SFOS 22 non concordano sul nome del log di monitoraggio: il riferimento generale indica ipsec_monitor.log, mentre la pagina di troubleshooting IPsec indica strongswan-monitor.log. Leggere solo il file presente nella build installata. Nell’ultima riga, sostituire HQ-Branch-ISP1 con il nome effettivo della connessione:

tail -n 200 /log/charon.log
for log in /log/ipsec_monitor.log /log/strongswan-monitor.log; do [ -f "$log" ] && tail -n 200 "$log"; done
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 almeno due connessioni. Solo le connessioni attive partecipano al failover. Verificare se un membro previsto è disattivato, appartiene già a un altro gruppo, è stato creato 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.

Verificare l’ordine dopo il trascinamento

L’attuale guida pubblica di SFOS 22 non indica un limite affidabile delle versioni interessate o corrette per un ordine errato dopo il trascinamento. Riaprire il gruppo salvato dopo ogni modifica e confrontare l’ordine con la priorità prevista.

Rimuovere il gruppo

La disattivazione di un gruppo di failover disattiva i tunnel attivi dei suoi membri. Le connessioni singole necessarie devono poi essere riattivate separatamente. Sophos non documenta gli effetti dell’eliminazione del gruppo stesso. Disattivare quindi prima il gruppo in una finestra di manutenzione, rimuovere le assegnazioni in modo controllato e non presumere una riattivazione automatica. Per un ripristino 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