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 route-based Any-to-Any is de keuze anders: de XFRM-interfaces krijgen overdrachtsadressen en statische, dynamische of SD-WAN Routes bepalen het datapad. Meerdere XFRM-gateways kunnen daar rechtstreeks via een SD-WAN Profile en SLA-controles worden geprioriteerd. Een extra VPN-failovergroep is dan niet nodig.

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.

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 peerconfiguratie, noch de DNS-update kan worden beheerd, stopt het ontwerp op dit punt. Twee gelijktijdig gepubliceerde adressen mogen niet als geteste failover worden beschouwd.

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. Bij vaste peeradressen is een beperkte Local Service ACL Exception beter dan een onnodig brede vrijgave. Device Access en Local Service ACL beschrijft de veilige implementatie.
• 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 actieve Site-to-Site IPsec-verbindingen.
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 als een tunnelwissel per e-mail moet worden gemeld. 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 stelt het Key negotiation tries effectief in op 3. De Failover condition neemt de bewaking over. De waarden in de profielweergave alleen tonen daarom niet het volledige effectieve gedrag.

Na verwijdering uit de groep gebruikt de verbinding opnieuw de DPD- en Key-negotiation-waarden van het toegewezen IPsec-profiel. Dat is belangrijk bij een rollback: een tunnel kan zich na het opheffen van de groep anders gedragen, hoewel 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.

De groep kan handmatig uit- en weer worden ingeschakeld om opnieuw te proberen de primaire verbinding op te bouwen. Dit veroorzaakt echter downtime en is geen onschuldige refresh-schakelaar. 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, ipsec_monitor.log en het verbindingsspecifieke actielog toe. In de laatste regel wordt HQ-Branch-ISP1 vervangen door de echte verbindingsnaam:

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
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 geselecteerd en actief zijn. Controleer of een verbinding 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 klopt niet na drag-and-drop

Sophos bevestigt voor SFOS 22.0 GA het probleem NC-178121: na een drag-and-drop-wijziging konden Site-to-Site IPsec-verbindingen op de verkeerde positie binnen de failovergroep terechtkomen. Dit specifieke probleem is opgelost met SFOS 22.0 MR2 Build 546.

Documenteer op SFOS 22.0 GA de volgorde vóór en na elke wijziging en vertrouw niet alleen op de visuele verplaatsing. De openbare release note noemt voor MR1 geen duidelijke eigen grens voor getroffen of opgeloste versies. Een vergelijkbaar probleem op MR2 Build 546 of nieuwer mag daarom niet automatisch nog steeds aan NC-178121 worden toegeschreven.

De groep terugbouwen

Als een failovergroep wordt uitgeschakeld, worden de actieve tunnels van haar leden gedeactiveerd. Benodigde afzonderlijke verbindingen worden daarna apart weer geactiveerd. 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