Konfigurera och testa en IPsec-failovergrupp i Sophos Firewall

En IPsec-failovergrupp ordnar flera Site-to-Site IPsec-anslutningar efter prioritet. Om den primära tunneln går ner aktiverar Sophos Firewall nästa tillgängliga anslutning. Växlingen är dock bara till hjälp om båda tunnlarna redan fungerar var för sig och täcker samma produktionsnät, regler, NAT-förutsättningar och returvägar.

Kort arbetsgång: Testa två IPsec-anslutningar separat, kontrollera Remote IDs och ordningen, samla dem i en grupp under Site-to-site VPN > IPsec > Failover group, välj en lämplig Failover condition och acceptanstesta sedan failover och failback med ett fast testflöde.

Guiden förutsätter en befintlig Site-to-Site IPsec-konfiguration. Den förklarar redundansstyrningen och inte hela tunnelkonfigurationen på nytt.

När en IPsec-failovergrupp passar

Gruppen passar främst för policy-based IPsec och route-based IPsec med konkreta Traffic Selectors. Flera anslutningar med identiska Local och Remote subnets måste ligga i samma failovergrupp eller använda tydligt olika selectors. Annars kan tunnlarna påverka varandra.

För route-based Any-to-Any ser beslutet annorlunda ut: XFRM-interfacen får överföringsadresser och statiska, dynamiska eller SD-WAN Routes avgör datavägen. Flera XFRM-gateways kan där prioriteras direkt via en SD-WAN Profile och SLA-kontroller. Någon extra VPN-failovergrupp behövs då inte.

En vanlig WAN-failover ersätter inte heller gruppen. WAN link manager kan byta internetanslutning men skapar inte en andra IPsec-anslutning med egen Gateway Address, Listening Interface och motpartskonfiguration.

Ett FQDN med flera WAN-adresser är ingen failover

Om samma DNS A-post samtidigt pekar på den primära WAN-adressen och på en adress som bara är aktiv vid ett avbrott kan fjärrmotparten välja den inaktiva adressen. DNS round robin känner varken till WAN-status eller tunnelstatus. En lokal IPsec-failovergrupp korrigerar inte automatiskt detta externa DNS-val.

För tunnlar som initieras av fjärrmotparten krävs därför antingen två uttryckligen konfigurerade anslutningar eller ett FQDN där statusmedveten DNS eller en DDNS-uppdatering endast pekar på den adress som för närvarande är nåbar. Om varken motpartens konfiguration eller DNS-uppdateringen kan styras måste designen stoppas här. Två samtidigt publicerade adresser får inte betraktas som testad failover.

En VPN-failovergrupp är dessutom något annat än ett HA-kluster. Gruppen växlar mellan tunnlar. HA växlar mellan två brandväggsnoder. I en kritisk miljö måste därför WAN-, VPN- och möjliga HA-fel planeras och testas separat.

Vad gruppen övervakar

Sophos Firewall kontrollerar motparten med gruppens Failover condition. Intervallet hämtas från det globala värdet Gateway failover time-out under:

Network > WAN link manager

Samma värde påverkar också den allmänna övervakningen av WAN-gateways. Det bör därför inte ändras enbart för en enskild VPN-tunnel. Ett kort värde reagerar snabbare men kan växla i onödan vid kortvarig paketförlust. Ett långt värde tolererar störningar längre men förlänger avbrottet före växlingen.

Health Check bekräftar bara att fjärrmotparten svarar på det valda ping- eller TCP-villkoret. Det bevisar inte att DNS, en affärsapplikation, NAT, routing och hela returvägen fungerar. Dessa delar testas separat efter växlingen.

Förbereda två tunnlar för gruppen

I följande exempel ansluter två tunnlar ett huvudkontor till en filial:

• huvudkontor: 10.10.0.0/16
• filial: 10.20.0.0/16
• primär anslutning: HQ-Branch-ISP1
• sekundär anslutning: HQ-Branch-ISP2
• primär motpartsadress: 198.51.100.20
• sekundär motpartsadress: 203.0.113.20
• filialens gemensamma Remote ID: 10.255.255.2
• failovergrupp: HQ-Branch-Zurich

Adresserna 198.51.100.0/24 och 203.0.113.0/24 är dokumentationsnät och ersätts med motparternas verkliga publika adresser. Även nät, namn och Remote ID är exempelvärden. Principen är avgörande: Gateway addresses får vara olika, men IP-adressen för Remote ID måste vara densamma för alla gruppmedlemmar. På motparten måste detta Remote ID varje gång motsvara Local ID.

Kontrollera båda anslutningarna separat innan de grupperas:

1. Båda anslutningarna är aktiva under Site-to-site VPN > IPsec.
2. Varje anslutning kan etableras separat och transporterar samma definierade testflöde.
3. Local och Remote subnets eller Traffic Selectors speglar inställningarna på motparten.
4. Brandväggsregler tillåter den nödvändiga trafiken via VPN-zonen i båda riktningarna.
5. NAT är lika och medvetet konfigurerat på båda vägarna.
6. Motparten har en returväg via båda tunnlarna.
7. Profilerna passar respektive motpart. IPsec-profiler i Sophos Firewall förklarar DPD, rekeying och lifetimes.
8. Det finns en alternativ administrationsväg och ett underhållsfönster.

⚠️ När en anslutning läggs till i en failovergrupp bryts redan etablerade anslutningar. Genomför därför inte ändringen under en obemannad fjärrsession eller utan en testad återställningsväg.

En anslutning kan bara vara medlem i en failovergrupp. Så länge den tillhör en grupp kan den inte tas bort. Remote Access IPsec-anslutningar kan inte vara gruppmedlemmar.

Välja en lämplig Failover condition

Sophos stöder ping eller TCP med en definierad port. Villkoret måste tillåtas medvetet på båda brandväggarna:

• Ping: enkelt att kontrollera men kräver Ping/Ping6 för WAN-zonen under Administration > Device access. Vid fasta motpartsadresser är en snäv Local Service ACL Exception bättre än en onödigt bred åtkomst. Device Access och Local Service ACL beskriver en säker implementering.
• TCP 22: kräver SSH via VPN-zonen. WAN-SSH bör inte öppnas för detta. En administrationstjänst är inte en bra allmän Health Check om den måste exponeras enbart för övervakningen.
• Annan TCP-port: kräver lämpliga inkommande och utgående brandväggsregler. Tjänsten måste vara permanent tillgänglig och får inte enbart bero på tillståndet hos en godtycklig applikation.

Villkoret ska motsvara en svarstjänst eller väg hos fjärrmotparten som är stabilt nåbar. Om TCP-tjänsten inte svarar på grund av underhåll, ett lokalt fel eller en hostbrandvägg kan gruppen växla trots att själva IPsec-vägen fortfarande är tillgänglig.

Konfigurera IPsec-failovergruppen

Menyvägen är:

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

1. Ange ett tydligt namn under Name, i exemplet HQ-Branch-Zurich.
2. Välj minst två aktiva Site-to-Site IPsec-anslutningar under Member connections.
3. Placera anslutningarna i önskad ordning: HQ-Branch-ISP1 först och HQ-Branch-ISP2 därefter. Den första anslutningen är den primära tunneln.
4. Aktivera Mail notification om ett tunnelbyte ska meddelas via e-post. Då måste Notification settings och VPN-meddelanden redan fungera.
5. Aktivera Automatic failback om gruppen ska återgå till den föredragna tunneln efter återställningen.
6. Ange en lämplig Failover condition med ping eller TCP och port.
7. Spara med Save.
8. Aktivera gruppens statusreglage. Först då blir gruppen aktiv och försöker etablera den primära anslutningen.

När två Sophos Firewalls används kontrolleras anslutningsegenskaper, medlemsordning, Remote IDs och Health Check-behörigheter på båda sidor. En korrekt grupp på bara ena sidan ersätter inte en passande motpartskonfiguration.

Vad som händer med DPD och Key negotiation tries

När en anslutning blir medlem i gruppen inaktiverar SFOS Dead Peer Detection för anslutningen och sätter det effektiva värdet för Key negotiation tries till 3. Failover condition tar över övervakningen. Enbart värdena i profilvyn visar därför inte hela det effektiva beteendet.

När anslutningen tas bort ur gruppen använder den åter DPD- och Key negotiation-värdena från den tilldelade IPsec-profilen. Det är viktigt vid en rollback: tunneln kan bete sig annorlunda efter att gruppen har lösts upp, trots att själva profilen inte redigerades.

Testa failover och failback kontrollerat

Definiera ett konkret dataflöde före avbrottstestet, till exempel:

• Source: 10.10.10.25
• Destination: 10.20.20.15
• Service: TCP 443
• förväntad brandväggsregel: HQ-to-Branch-HTTPS

Genomför sedan testet i en tydlig ordning:

1. Dokumentera gruppstatus, medlemsordning, firmwarebuild och Gateway failover time-out.
2. Kontrollera den primära tunneln på båda sidor i WebAdmin. Bekräfta med verklig HTTPS-trafik att fram- och returväg fungerar.
3. Spara tillståndet i Advanced Shell med ipsec statusall.
4. Bryt den primära WAN- eller upstreamvägen kontrollerat under underhållsfönstret. Stäng inte av hela failovergruppen, eftersom det inaktiverar alla aktiva grupptunnlar.
5. Observera längre än den konfigurerade Gateway failover time-out och notera tiden för växlingen.
6. Kontrollera att HQ-Branch-ISP2 etableras och att samma HTTPS-test fungerar i båda riktningarna.
7. Kontrollera brandväggsregel, NAT, returväg och applikationsfunktion. En grön tunnel är inte i sig ett framgångskriterium.
8. Återställ den primära vägen och observera Automatic failback.
9. Kör samma test igen efter återgången och dokumentera det faktiskt uppmätta avbrottet.

Befintliga TCP-sessioner kan brytas vid växlingen. Den nya tunneln har andra Security Associations och kan gå via en annan publik adress. Applikationen måste därför ofta skapa en ny session. IPsec-failover förbättrar tillgängligheten men garanterar inte en avbrottsfri session.

Automatic failback upphör efter fem misslyckade försök

När den primära motparten åter blir nåbar försöker SFOS återställa den föredragna anslutningen upp till fem gånger om Automatic failback är aktiverat. Om det misslyckas förblir den sekundära tunneln aktiv. Brandväggen fortsätter därefter inte att kontrollera den primära tunneln utan gräns; en ny återgång sker först när den sekundära vägen fallerar.

Gruppen kan stängas av och slås på manuellt för att starta ett nytt försök att etablera den primära anslutningen. Det orsakar dock downtime och är inte ett ofarligt refresh-reglage. Kontrollera först loggar, motpart, profil, IDs och väg.

Kontrollera loggar utan att ändra något

För gruppbeslutet är dgd.log viktig och för själva IPsec-etableringen är strongswan.log viktig. Följande kommandon körs i Advanced Shell och ändrar ingen konfiguration:

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

Komplettera vid behov med charon.log, ipsec_monitor.log och den anslutningsspecifika åtgärdsloggen. På sista raden ersätts HQ-Branch-ISP1 med det verkliga anslutningsnamnet:

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

Jämför tidsstämplar från dgd.log, IPsec-status, WAN-händelse och applikationstest. En misslyckad Health Check utan ett motsvarande tunnel- eller applikationsfel bevisar ännu inte en operatörsstörning. Den fullständiga diagnostikvägen finns i Felsökning av IPsec VPN på Sophos Firewall.

Vanliga fel och säker återgång

Gruppen kan inte aktiveras korrekt

Minst två anslutningar måste vara valda och aktiva. Kontrollera om en anslutning redan tillhör en annan grupp, skapades som Remote Access eller använder ett avvikande Remote ID. Testa därefter båda tunnlarna separat igen innan gruppen aktiveras på nytt.

Den sekundära tunneln är grön men trafiken fallerar

Grupplogiken har då sannolikt fungerat men inte datavägen. Kontrollera brandväggsregler, NAT, Local och Remote subnets, automatiska eller manuella routes samt returvägen hos motparten. Den sekundära tunneln måste kunna bära samma produktiva testflöde som den primära.

Gruppen växlar för tidigt eller för sent

Kontrollera Failover condition och Gateway failover time-out tillsammans. Ett instabilt ping- eller TCP-mål kan orsaka onödiga växlingar. Ett långt globalt timeout-värde fördröjer däremot också andra gatewaykontroller som är beroende av det. Ändra inte bara siffervärdet, utan dokumentera orsak, paketförlust och faktisk växlingstid.

Ordningen är fel efter drag-and-drop

Sophos bekräftar felet NC-178121 för SFOS 22.0 GA: efter en drag-and-drop-ändring kunde Site-to-Site IPsec-anslutningar hamna på fel plats i failovergruppen. Det specifika felet är åtgärdat i SFOS 22.0 MR2 Build 546.

I SFOS 22.0 GA ska ordningen dokumenteras före och efter varje ändring, och man ska inte förlita sig enbart på den visuella flytten. Den offentliga Release Note anger ingen entydig separat gräns för berörda eller korrigerade MR1-versioner. Ett liknande fel i MR2 Build 546 eller senare får därför inte automatiskt fortsätta att tillskrivas NC-178121.

Återställa utan gruppen

När en failovergrupp stängs av inaktiveras medlemmarnas aktiva tunnlar. Nödvändiga fristående anslutningar måste därefter aktiveras separat igen. För en kontrollerad rollback:

1. Spara utgångsläge, medlemsordning och använda profiler.
2. Bekräfta underhållsfönster och alternativ administrationsväg.
3. Stäng av gruppen och dokumentera avbrottet.
4. Ta bort anslutningarna ur gruppen eller återställ den ursprungliga tilldelningen.
5. Aktivera den fristående anslutning som behövs.
6. Beakta åter DPD- och Key negotiation-beteendet från profilen.
7. Kontrollera samma testflöde, loggar och returväg.

Drift

• Testa failover och failback igen efter ändringar av firmware, operatör, motpart, routing, NAT eller profil.
• Dokumentera medlemsordning, Remote IDs, profiler, Health Check-villkor och globalt timeout-värde.
• Använd Mail notification endast som en indikation; den tekniska acceptansen görs fortfarande med status, loggar och verklig trafik.
• Ta med båda tunnlarna i övervakning, underhållsplan och motpartsdokumentation.
• Kontrollera om den sekundära operatören uppfyller samma allowlists, NAT-beroenden och publika åtkomstkrav.
• Stäng av och slå på gruppen manuellt endast med ett planerat avbrott.

FAQ