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 en helt routingstyrd route-based Any-to-Any-design ser beslutet annorlunda ut: XFRM-interfacen får överföringsadresser och statiska, dynamiska eller SD-WAN Routes avgör datavägen. För denna design dokumenterar Sophos flera XFRM-gateways med en SD-WAN Profile och SLA-kontroller utan någon extra VPN-failovergrupp. Utanför denna design varnar Sophos dock för att flera Any-to-Any-anslutningar med identiska selectors måste ligga i samma failovergrupp.

Den allmänna felsökningsdokumentationen kräver en grupp även för Any-to-Any, medan den specifika SD-WAN-guiden fungerar utan grupp. Dokumentationen avgränsar inte detta undantag uttryckligen. Följ därför hela XFRM-/SD-WAN-designen och verifiera den på den installerade builden; utelämna inte gruppen enbart för att selektorerna är inställda på Any. Gör ruttbaserad IPsec redundant med två internetanslutningar förklarar hela designen med två operatörer, separata XFRM-gateways, statiska Primary- och Backup-rutter och ett kontrollerat failovertest.

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.

system link_failover är en separat CLI-mekanism

SFOS 22 publicerar dessutom ett Device Console-kommando som lägger till en VPN- eller GRE-tunnel som backup för en Primary Link. Den publicerade grammatiken är:

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

För monitor TCP host måste TCP-porten som ska kontrolleras anges; monitor PING host använder ingen port. Målet ska inte bara svara utan även representera den relevanta vägen på ett meningsfullt sätt. En lyckad monitor bevisar inte att applikationen, brandväggsregeln, rutten eller returvägen fungerar.

Kommandot är inte samma sak som IPsec-failovergruppen i WebAdmin och inte heller XFRM- och SD-WAN-designen. Den offentliga SFOS 22-sidan dokumenterar endast add: den innehåller inget kommando för status, borttagning eller återställning och förklarar inte samspelet med befintliga rutter eller SD-WAN Policies. Utan en återställningsmetod som har bekräftats för den installerade builden är detta inte en procedur att kopiera. För nya konfigurationer är de dokumenterade WebAdmin- eller XFRM-metoderna en tydligare utgångspunkt.

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 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 motparten eller DNS-uppdateringen kan styras ger denna design ingen tillförlitlig inkommande failover. Två samtidigt publicerade adresser räknas inte 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.

Under Site-to-site VPN > IPsec betyder Active och Connection olika saker: Active visar om anslutningen är aktiverad; Connection visar om tunneln är etablerad. En aktiv post kan fortfarande sakna en etablerad tunnel. Med flera Local och Remote subnets skapas en tunnel för varje nätpar; en delvis etablerad status innebär därför inte fullständig acceptans. Activate on save eller reglaget i kolumnen Active aktiverar posten. För flera markerade poster finns Activate och Deactivate, samt ett filter bredvid Active. Dessa åtgärder ändrar tillståndet och hör, liksom grupperingen, hemma i det planerade testfönstret.

För att jämföra båda medlemmarna, välj Local subnet och Remote subnet under IPsec connections > Show additional properties och bekräfta med OK. Fler egenskaper kan visas och kolumnerna kan ordnas om genom att dra och släppa. Logs öppnar loggarna; under Profiles > IPsec profiles > Show additional properties kan även profilvärdena jämföras. Klargör saknade eller avvikande nätpar med motpartens administratör före grupperingen.

Om brandväggen tar emot inkommande IPsec-förfrågningar måste även IPsec tillåtas för WAN-zonen under Administration > Device access. Det är en annan behörighet än ping eller SSH för Health Check och ersätter inte brandväggsregler för applikationstrafiken.

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. Sophos dokumenterar denna zonåtkomst som ett krav. Vid fasta motpartsadresser kan en snäv Local Service ACL Exception utvärderas som härdning; den måste matcha den källadress som motparten faktiskt använder. Device Access och Local Service ACL beskriver konfigurationen.
• 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å Site-to-Site IPsec-anslutningar under Member connections. Endast aktiva anslutningar deltar i failover, så aktivera och testa varje avsedd medlem separat innan gruppen tas i drift.
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 för att få meddelanden om anslutningsfel. 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.

API-referens: håll grupp, anslutning och monitor åtskilda

Den kombinerade API-operationen i SFOS 22/23 Add Failover Group IPSEC Connection / Edit IPSEC Connection ger ingen fullständig grupppayload: exemplet visar VPNIPSecConnection/Configuration och anslutningsåtgärder, inte serialiseringen av den separata WebAdmin-gruppen.

• Tabellen anger Failover Group Name som obligatoriskt och Failover Mail Notification som valfritt med y/n. Exemplet visar varken deras XML-mappning eller hur medlemskap, prioritet eller Automatic failback representeras. Härled inte XML-taggar från fältnamn med blanksteg eller medlemsprioritet från ordningen på ARRAY-värden.
• Protocol förekommer två gånger med olika tillämpningsområden: för övervakning som ARRAY med ping, tcp eller en tom sträng (''), bredvid Port som ARRAY från 1 till 65535; för anslutningen som SCALAR med ALL, ICMP, UDP, TCP, bredvid LocalPort och RemotePort. Fälten är inte utbytbara. Referensen förklarar varken parningen av arrayer eller den tomma strängens betydelse; härled inga tillstånd för applikationstrafik eller IKE från dessa fält. Brandväggsregler och Device Access förblir separata krav.

Även värdelistorna skiljer sig åt: exemplet för ConnectionType visar RemoteAccess/SiteToSite/HostToHost, medan tabellen också anger TunnelInterface; SubnetFamily visar IPv4/IPv6, medan tabellen också anger Dual. Att ett värde saknas i exemplet bevisar inte att det saknar stöd. Omvandla inte GUI-lägesnamn till antagna API-token; guiden för Site-to-Site IPsec förklarar anslutningsparametrarna.

Så länge gruppschemat för den installerade builden är oklart, hantera gruppen via WebAdmin-proceduren ovan i stället för att gissa en begäran. Dokumentera det faktiska medlemskapet, ordningen, övervakningsvillkoret och failbackinställningen före ändringar; kontrollera därefter den sparade gruppen och det verkliga testflödet. Om resultatet avviker från det planerade, använd återställningen nedan för att återgå till det dokumenterade utgångsläget.

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 använder 3 för Key negotiation tries. Failover condition tar över övervakningen.

När anslutningen tas bort ur gruppen använder den åter DPD- och Key negotiation-värdena från den tilldelade IPsec-profilen. Ta med detta beteende i återställningstestet även om själva profilen inte ändrades.

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. Om gruppen innehåller fler än två anslutningar återgår SFOS till den första tillgängliga anslutningen i ordningen Member connections.

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 ett avbrott. Kontrollera först loggar, motpart, profil, ID:n 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. Öppna 5. Device Management > 3. Advanced Shell i CLI; dessa kommandon är inte avsedda för Device Console. Loggar kan innehålla interna nät, motpartsadresser och namn och ska granskas innan de delas. Följande kommandon läser endast tillståndet eller loggarna och ändrar ingen konfiguration:

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

Komplettera vid behov med charon.log och den anslutningsspecifika åtgärdsloggen. De officiella SFOS 22-sidorna anger olika namn för övervakningsloggen: den allmänna loggreferensen anger ipsec_monitor.log, medan IPsec-felsökningssidan anger strongswan-monitor.log. Läs endast den fil som finns på den installerade builden. På sista raden ersätts HQ-Branch-ISP1 med det verkliga anslutningsnamnet:

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

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. Endast aktiva anslutningar deltar i failover. Kontrollera om en avsedd medlem är avstängd, 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.

Kontrollera ordningen efter dra och släpp

Den aktuella offentliga SFOS 22-hjälpen anger ingen tillförlitlig gräns för berörda eller korrigerade versioner vid fel ordning efter dra och släpp. Öppna den sparade gruppen igen efter varje ändring och jämför ordningen med den avsedda prioriteten.

Å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. Sophos dokumenterar inte följderna av att ta bort själva gruppen. Stäng därför först av gruppen under ett underhållsfönster, ta bort tilldelningarna kontrollerat och utgå inte från automatisk återaktivering. För en kontrollerad återställning:

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