Sophos Firewall IPsec-failovergroep instellen en testen

Een IPsec-failovergroep rangschikt meerdere Site-to-Site IPsec-verbindingen op prioriteit. Als de primaire tunnel uitvalt, activeert Sophos Firewall de volgende beschikbare verbinding. De omschakeling helpt echter alleen wanneer beide tunnels afzonderlijk al werken en dezelfde productienetwerken, regels, NAT-verwachtingen en retourpaden afdekken.

Kort proces: Twee IPsec-verbindingen afzonderlijk testen, Remote ID’s en volgorde controleren, ze onder Site-to-site VPN > IPsec > Failover group in een groep onderbrengen, een geschikte Failover condition kiezen en daarna failover en failback met een vaste teststroom accepteren.

Deze handleiding veronderstelt een bestaande Site-to-Site IPsec-configuratie. Ze behandelt de redundantiesturing en niet opnieuw de volledige tunnelconfiguratie.

Wanneer een IPsec-failovergroep past

De groep is vooral geschikt voor policy-based IPsec en route-based IPsec met concrete Traffic Selectors. Meerdere verbindingen met identieke Local en Remote subnets moeten samen in één failovergroep staan of duidelijk verschillende selectors gebruiken. Anders kunnen de tunnels elkaar beïnvloeden.

Bij een volledig door routing gestuurd route-based Any-to-Any-ontwerp is de keuze anders: de XFRM-interfaces krijgen overdrachtsadressen en statische, dynamische of SD-WAN Routes bepalen het datapad. Sophos documenteert voor dit ontwerp meerdere XFRM-gateways met een SD-WAN Profile en SLA-controles zonder extra VPN-failovergroep. Buiten dit ontwerp waarschuwt Sophos echter dat meerdere Any-to-Any-verbindingen met identieke selectors in dezelfde failovergroep moeten staan.

Route-based IPsec redundant maken met twee internetverbindingen legt de volledige opzet met twee providers, afzonderlijke XFRM-gateways, statische Primary- en Backup-routes en een gecontroleerde failovertest uit.

Ook een normale WAN-failover vervangt de groep niet. De WAN link manager kan van internetverbinding wisselen, maar maakt geen tweede IPsec-verbinding met een eigen Gateway Address, Listening Interface en configuratie van de peer.

system link_failover is een afzonderlijk CLI-mechanisme

SFOS 22 publiceert daarnaast een Device Console-opdracht die een VPN- of GRE-tunnel als backup voor een Primary Link toevoegt. De gepubliceerde grammatica is:

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

Bij monitor TCP host moet de te controleren TCP-poort worden opgegeven; monitor PING host gebruikt geen poort. Het doel moet niet alleen antwoorden, maar het relevante pad zinvol vertegenwoordigen. Een geslaagde monitor bewijst niet dat de applicatie, firewallregel, route of retourrichting werkt.

Deze opdracht is niet hetzelfde als de IPsec-failovergroep in WebAdmin en ook niet als het XFRM- en SD-WAN-ontwerp. De openbare SFOS 22-pagina documenteert alleen add: er is geen status-, verwijder- of rollbackopdracht en de interactie met bestaande routes of SD-WAN Policies wordt niet uitgelegd. Zonder een voor de geïnstalleerde build bevestigde rollbackmethode is dit geen kopieerprocedure. Voor nieuwe configuraties zijn de gedocumenteerde WebAdmin- of XFRM-methoden een duidelijker uitgangspunt.

Een FQDN met meerdere WAN-adressen is geen failover

Als hetzelfde DNS A-record tegelijk naar het primaire WAN-adres en naar een adres verwijst dat alleen bij een storing actief is, kan de remote peer het inactieve adres selecteren. DNS round robin kent noch de WAN-status, noch de tunnelstatus. Een lokale IPsec-failovergroep corrigeert deze externe DNS-selectie niet automatisch.

Voor tunnels die door de remote peer worden gestart, heeft die peer daarom twee expliciet geconfigureerde verbindingen nodig of een FQDN waarvan statusafhankelijke DNS of een DDNS-update alleen naar het momenteel bereikbare adres wijst. Als noch de peer noch de DNS-update kan worden beheerd, levert dit ontwerp geen betrouwbare inkomende failover. Twee gelijktijdig gepubliceerde adressen gelden niet als geteste failover.

Een VPN-failovergroep is bovendien iets anders dan een HA-cluster. De groep wisselt tussen tunnels. HA wisselt tussen twee firewallnodes. In een kritieke omgeving moeten WAN-, VPN- en mogelijke HA-storingen daarom afzonderlijk worden gepland en getest.

Wat de groep bewaakt

Sophos Firewall controleert de peer met de Failover condition van de groep. Het interval is afkomstig van de globale waarde Gateway failover time-out onder:

Network > WAN link manager

Dezelfde waarde beïnvloedt ook de algemene bewaking van WAN-gateways. Pas deze daarom niet alleen voor één VPN-tunnel aan. Een korte waarde reageert sneller, maar kan bij kort pakketverlies onnodig omschakelen. Een lange waarde verdraagt storingen langer, maar verlengt ook de uitval voordat de wissel plaatsvindt.

De Health Check bevestigt alleen dat de remote peer op de gekozen ping- of TCP-voorwaarde reageert. Daarmee is niet bewezen dat DNS, een bedrijfsapplicatie, NAT, routing en het volledige retourpad werken. Deze onderdelen worden na de omschakeling afzonderlijk getest.

Twee tunnels voor de groep voorbereiden

In het volgende voorbeeld verbinden twee tunnels een hoofdkantoor met een vestiging:

• hoofdkantoor: 10.10.0.0/16
• vestiging: 10.20.0.0/16
• primaire verbinding: HQ-Branch-ISP1
• secundaire verbinding: HQ-Branch-ISP2
• primair peeradres: 198.51.100.20
• secundair peeradres: 203.0.113.20
• gedeelde Remote ID van de vestiging: 10.255.255.2
• failovergroep: HQ-Branch-Zurich

De adressen 198.51.100.0/24 en 203.0.113.0/24 zijn documentatienetwerken en worden vervangen door de echte openbare peeradressen. Ook de netwerken, namen en Remote ID zijn voorbeeldwaarden. Het principe is doorslaggevend: de Gateway addresses mogen verschillen, maar het IP-adres van de Remote ID moet voor alle groepsleden gelijk zijn. Aan de andere zijde moet deze Remote ID telkens overeenkomen met de Local ID.

Controleer beide verbindingen afzonderlijk voordat ze worden gegroepeerd:

1. Beide verbindingen zijn actief onder Site-to-site VPN > IPsec.
2. Elke verbinding kan afzonderlijk worden opgebouwd en draagt dezelfde vastgelegde teststroom.
3. Local en Remote subnets of Traffic Selectors zijn spiegelbeeldig aan de andere zijde.
4. Firewallregels staan het benodigde verkeer via de VPN-zone in beide richtingen toe.
5. NAT is op beide paden gelijk en bewust geconfigureerd.
6. De peer kent via beide tunnels een retourpad.
7. De profielen passen bij de betreffende peer. IPsec-profielen op Sophos Firewall legt de betekenis van DPD, rekeying en lifetimes uit.
8. Er zijn een alternatieve beheertoegang en een onderhoudsvenster beschikbaar.

⚠️ Door een verbinding aan een failovergroep toe te voegen, worden reeds opgebouwde verbindingen verbroken. Voer deze wijziging daarom niet uit tijdens een onbegeleide remote sessie of zonder getest terugvalpad.

Een verbinding kan slechts lid zijn van één failovergroep. Zolang ze aan een groep is toegewezen, kan ze niet worden verwijderd. Remote Access IPsec-verbindingen kunnen geen groepslid zijn.

Een geschikte Failover condition kiezen

Sophos ondersteunt ping of TCP met een vastgelegde poort. Sta de voorwaarde bewust op beide firewalls toe:

• Ping: eenvoudig te controleren, maar vereist Ping/Ping6 voor de WAN-zone onder Administration > Device access. Sophos documenteert deze zonetoegang als voorwaarde. Bij vaste peeradressen kan een beperkte Local Service ACL Exception als hardening worden beoordeeld; deze moet overeenkomen met het bronadres dat de peer werkelijk gebruikt. Device Access en Local Service ACL beschrijft de configuratie.
• TCP 22: vereist SSH via de VPN-zone. Open hiervoor geen WAN-SSH. Een beheerdienst is geen goede algemene Health Check wanneer deze alleen voor de bewaking beschikbaar zou moeten worden gemaakt.
• Andere TCP-poort: vereist passende inkomende en uitgaande firewallregels. De dienst moet permanent beschikbaar zijn en mag niet uitsluitend afhangen van de toestand van een willekeurige applicatie.

De voorwaarde moet een stabiel bereikbare antwoorddienst of een stabiel pad van de remote peer vertegenwoordigen. Als de TCP-dienst door onderhoud, een lokale storing of een hostfirewall niet antwoordt, kan de groep omschakelen terwijl het IPsec-pad zelf nog beschikbaar is.

IPsec-failovergroep configureren

Het menupad is:

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

1. Voer onder Name een duidelijke naam in, in dit voorbeeld HQ-Branch-Zurich.
2. Selecteer onder Member connections minstens twee Site-to-Site IPsec-verbindingen. Alleen actieve verbindingen nemen deel aan failover; activeer en test daarom elk gepland lid afzonderlijk voordat de groep in gebruik wordt genomen.
3. Zet de verbindingen in de gewenste volgorde: eerst HQ-Branch-ISP1, daarna HQ-Branch-ISP2. De eerste verbinding is de primaire tunnel.
4. Activeer Mail notification om meldingen van verbindingsfouten te ontvangen. Daarvoor moeten de Notification settings en VPN-meldingen al werken.
5. Activeer Automatic failback als de groep na herstel naar de voorkeurtunnel moet terugkeren.
6. Stel een passende Failover condition met ping of TCP en poort in.
7. Sla de configuratie op met Save.
8. Activeer de statusschakelaar van de groep. Pas dan wordt de groep actief en probeert ze de primaire verbinding op te bouwen.

Bij twee Sophos Firewalls worden aan beide zijden de verbindingseigenschappen, volgorde van de leden, Remote ID’s en toestemmingen voor de Health Check gecontroleerd. Een correct ingestelde groep aan slechts één zijde vervangt geen passende configuratie van de peer.

Wat er met DPD en Key negotiation tries gebeurt

Zodra een verbinding lid van de groep is, schakelt SFOS Dead Peer Detection voor deze verbinding uit en gebruikt het 3 voor Key negotiation tries. De Failover condition neemt de bewaking over.

Na verwijdering uit de groep gebruikt de verbinding opnieuw de DPD- en Key negotiation-waarden van het toegewezen IPsec-profiel. Neem dit gedrag op in de rollbacktest, ook als het profiel zelf niet is gewijzigd.

Failover en failback gecontroleerd testen

Leg vóór de uitvaltest een concrete datastroom vast, bijvoorbeeld:

• Source: 10.10.10.25
• Destination: 10.20.20.15
• Service: TCP 443
• verwachte firewallregel: HQ-to-Branch-HTTPS

Voer de test daarna in een vaste volgorde uit:

1. Documenteer groepsstatus, volgorde van de leden, firmwarebuild en Gateway failover time-out.
2. Controleer de primaire tunnel aan beide zijden in WebAdmin. Bevestig met echt HTTPS-verkeer dat heen- en retourpad werken.
3. Leg de toestand in de Advanced Shell vast met ipsec statusall.
4. Onderbreek het primaire WAN- of upstreampad gecontroleerd binnen het onderhoudsvenster. Schakel niet de hele failovergroep uit, want daardoor worden alle actieve groepstunnels gedeactiveerd.
5. Observeer langer dan de geconfigureerde Gateway failover time-out en noteer het tijdstip van omschakeling.
6. Controleer of HQ-Branch-ISP2 wordt opgebouwd en dezelfde HTTPS-test in beide richtingen werkt.
7. Controleer firewallregel, NAT, retourpad en applicatiefunctie. Alleen een groene tunnel is geen succescriterium.
8. Herstel het primaire pad en observeer Automatic failback.
9. Voer na de terugschakeling dezelfde test opnieuw uit en documenteer de werkelijk gemeten onderbreking.

Bestaande TCP-sessies kunnen tijdens de wissel worden verbroken. De nieuwe tunnel heeft andere Security Associations en kan via een ander openbaar adres lopen. De applicatie moet daarom vaak een nieuwe sessie opbouwen. IPsec-failover verhoogt de beschikbaarheid, maar garandeert geen ononderbroken sessie.

Automatic failback stopt na vijf mislukte pogingen

Wanneer de primaire peer weer bereikbaar is, probeert SFOS bij ingeschakelde Automatic failback maximaal vijfmaal de voorkeursverbinding te herstellen. Als dat niet lukt, blijft de secundaire tunnel actief. De firewall blijft de primaire tunnel daarna niet onbeperkt controleren; een nieuwe terugschakeling vindt pas plaats wanneer het secundaire pad uitvalt. Bevat de groep meer dan twee verbindingen, dan schakelt SFOS terug naar de eerste beschikbare verbinding in de volgorde Member connections.

De groep kan handmatig uit- en weer worden ingeschakeld om opnieuw te proberen de primaire verbinding op te bouwen. Dit veroorzaakt downtime. Controleer eerst logs, peer, profiel, ID’s en pad.

Logs zonder wijzigingen controleren

Voor de groepsbeslissing is dgd.log belangrijk; voor de feitelijke IPsec-opbouw is dat strongswan.log. De volgende opdrachten worden uitgevoerd in de Advanced Shell en wijzigen geen configuratie:

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

Voeg indien nodig charon.log en het verbindingsspecifieke actielog toe. De officiële SFOS 22-pagina’s spreken elkaar tegen over de naam van het monitorlog: de algemene logreferentie noemt ipsec_monitor.log, terwijl de IPsec-troubleshootingpagina strongswan-monitor.log noemt. Lees alleen het bestand dat op de geïnstalleerde build bestaat. In de laatste regel wordt HQ-Branch-ISP1 vervangen door de echte verbindingsnaam:

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

Vergelijk de tijdstempels uit dgd.log, de IPsec-status, het WAN-event en de applicatietest. Een mislukte Health Check zonder bijpassende tunnel- of applicatiefout bewijst nog geen providerstoring. Sophos Firewall IPsec VPN-problemen oplossen bevat het volledige diagnoseproces.

Typische fouten en veilig terugkeren

De groep kan niet correct worden geactiveerd

Er moeten minstens twee verbindingen zijn geselecteerd. Alleen actieve verbindingen nemen deel aan failover. Controleer of een gepland lid is uitgeschakeld, al tot een andere groep behoort, als Remote Access is aangemaakt of een afwijkende Remote ID gebruikt. Test daarna beide tunnels opnieuw afzonderlijk voordat de groep weer wordt geactiveerd.

De secundaire tunnel is groen, maar het verkeer valt uit

De groepslogica heeft dan waarschijnlijk gewerkt, maar het datapad niet. Controleer firewallregels, NAT, Local en Remote subnets, automatische of handmatige routes en het retourpad aan de andere zijde. De secundaire tunnel moet dezelfde productieve teststroom kunnen dragen als de primaire tunnel.

De groep schakelt te vroeg of te laat om

Controleer Failover condition en Gateway failover time-out samen. Een instabiel ping- of TCP-doel kan onnodige wissels veroorzaken. Een lange globale time-out vertraagt daarentegen ook andere gatewaycontroles die ervan afhankelijk zijn. Wijzig niet alleen de getalswaarde, maar documenteer oorzaak, pakketverlies en werkelijke omschakeltijd.

De volgorde na slepen controleren

De huidige openbare SFOS 22-help geeft geen betrouwbare grens voor betrokken of gecorrigeerde versies bij een verkeerde volgorde na slepen. Open de opgeslagen groep na elke wijziging opnieuw en vergelijk de volgorde met de geplande prioriteit.

De groep terugbouwen

Als een failovergroep wordt uitgeschakeld, worden de actieve tunnels van haar leden gedeactiveerd. Benodigde afzonderlijke verbindingen worden daarna apart weer geactiveerd. Sophos documenteert de gevolgen van het verwijderen van de groep zelf niet. Schakel de groep daarom eerst uit tijdens een onderhoudsvenster, verwijder de toewijzingen gecontroleerd en ga niet uit van automatische heractivering. Voor een gecontroleerde rollback:

1. Leg de uitgangstoestand, volgorde van de leden en gebruikte profielen vast.
2. Bevestig het onderhoudsvenster en de alternatieve beheertoegang.
3. Schakel de groep uit en documenteer de onderbreking.
4. Verwijder verbindingen uit de groep of herstel de oorspronkelijke toewijzing.
5. Activeer de benodigde afzonderlijke verbinding.
6. Houd opnieuw rekening met het DPD- en Key-negotiation-gedrag uit het profiel.
7. Controleer dezelfde teststroom, de logs en het retourpad.

Beheer

• Test failover en failback opnieuw na wijzigingen aan firmware, provider, peer, routing, NAT of profiel.
• Documenteer de volgorde van de leden, Remote ID’s, profielen, Health Check-voorwaarde en globale time-out.
• Gebruik Mail notification alleen als melding; de technische acceptatie gebeurt nog steeds met status, logs en echt verkeer.
• Neem beide tunnels op in monitoring, onderhoudsplan en documentatie van de peer.
• Controleer of de secundaire provider dezelfde allowlists, NAT-afhankelijkheden en openbare bereikbaarheid ondersteunt.
• Schakel de groep alleen handmatig uit en weer in als een onderbreking is ingepland.

FAQ