Sophos Firewall: systematisk felsökning av IPsec VPN

Vid IPsec-felsökning är ordningen avgörande: kontrollera först IKE och Child SA, därefter brandväggsregler, NAT, routing och returväg. En grön tunnel bekräftar endast förhandlingen, inte att nyttotrafiken fungerar.

För en ny tunnel är Konfigurera Site-to-Site IPsec VPN på Sophos Firewall rätt startpunkt. Följande steg gäller en redan konfigurerad anslutning.

Ändra inte globala avancerade inställningar som sessionsrensning vid failover, anti-replay-fönstret, IKEv2-cookiegränsen eller användning av redan upplösta peeradresser som ett första diagnostikförsök. Använd globala VPN-inställningar säkert beskriver effekt, utgångskontroll och rollback.

Diagnostisk arbetsgång

Tunneln förblir nere: Kontrollera IKE-version, IPsec-profil, gateway, Local/Remote ID, PSK eller certifikat i strongswan.log.
Fas 1 är etablerad, men Child SA saknas: Jämför Traffic Selectors, fas 2-förslag, PFS och subnät.
Tunneln är grön: Använd ipsec statusall för att kontrollera att SA är ESTABLISHED, att Child SA är INSTALLED och att byte-räknarna ökar.
Endast en riktning räknar byte: Kontrollera brandväggsregler, NAT, routing och särskilt returvägen hos motparten.
Orsaken är fortfarande oklar: Följ ett enskilt testflöde med Log Viewer och Packet Capture.

Innan dess räcker några få dokumenterade värden: tunnelnamn, peer-IP eller FQDN, IKE-version, Local/Remote ID, lokala nät och fjärrnät, policy-based eller route-based, IPsec-profil samt ett test med Source, Destination och Service. Exempel: tunneln azure-vpn, lokalt 172.16.10.0/24, på fjärrsidan 10.20.30.0/24.

Med policy-based IPsec är nätverken en del av förhandlingen. Route-based IPsec använder ett XFRM-gränssnitt och statiska, SD-WAN- eller dynamiska rutter. Vid felaktig väg hjälper de separata guiderna om IPsec Routes och Route Precedence.

⚠️ Loggar och Packet Captures kan innehålla publika IP-adresser, interna nätverk, värdnamn eller paketinnehåll. Samla bara in dem målinriktat och under begränsad tid och kontrollera dem innan de delas.

Före CLI-diagnosen visar Current activities > IPsec connections endast de IPsec-anslutningar som för närvarande är upprättade. Listan kan filtreras efter Connection name, Local server name, Local subnet, Username, Remote server/host eller Remote subnet och uppdateras med Refresh. Disconnect bryter aktivt den valda anslutningen och är inte en ofarlig uppdatering: dokumentera först tidpunkt och status och koppla sedan endast från i ett planerat testfönster. Denna ögonblicksbild ersätter inte kontroll av Child SA, loggar eller trafik.

Kontrollera loggar och CLI

Under Site-to-site VPN > IPsec visar Show additional properties bland annat Local subnet, Remote subnet, Gateway type och Profile. Under Profiles > IPsec profiles kan fas 1- och fas 2-värden också jämföras direkt.

De viktigaste filerna i /log är:

strongswan.log: IKE, autentisering och Child SA
charon.log: IKE-demon
ipsec_monitor.log: övervakning av IPsec-tjänsten
/log/ipsec_conn/ipsec_<connectionname>.log: Connect-, Activate- och Deactivate-åtgärder i WebAdmin
xfrmi.log: XFRM-gränssnitt
dgd.log: Dead Gateway Detection och VPN-failover

Den aktuella centrala logglistan för SFOS 22 anger ipsec_monitor.log. En äldre felsökningssida från Sophos anger fortfarande strongswan-monitor.log; för aktuella SFOS 22-system är den nyare logglistan vägledande.

I Advanced Shell kan huvudloggen följas eller filtreras live. För den som inte är van vid SSH- och shellåtkomst hjälper Sophos Firewall CLI-felsökning: viktiga kommandon.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

Raderna är alternativ, inte ett sammanhängande förlopp. I less söker /sökterm i filen.

Debuggning av StrongSwan

Om den vanliga loggen inte räcker, dokumentera först det aktuella tillståndet i Advanced Shell:

service -S | grep strongswan

Om utdata redan visar att debug är aktivt ska växlingskommandot inte köras igen. Ta först reda på vem som aktiverade debug och varför; sekvensen nedan gäller bara om debug var inaktivt från början. Den exakta statustexten kan skilja sig mellan versioner.

⚠️ Kör debug endast en kort stund. Det kan snabbt skapa stora loggfiler och ta upp lagringsutrymme.

Om debug inte är aktivt, kör kommandot en gång och kontrollera det nya tillståndet:

service strongswan:debug -ds nosync
service -S | grep strongswan

Följ sedan strongswan.log i en andra terminal, återskapa felet exakt en gång och avsluta tail med Ctrl+C:

tail -f /log/strongswan.log

Kör till sist samma växlingskommando en gång. Den andra raden måste bekräfta att det tidigare dokumenterade normala tillståndet utan debug har återställts:

service strongswan:debug -ds nosync
service -S | grep strongswan

Kontrollera tunneluppbyggnaden

Fas 1: IKE, ID:n och autentisering

Om tunneln inte kommer upp matchar vanligtvis inte IKE-version, gateway, ID:n, förslag, PSK eller certifikat.

no IKE config found eller Remote peer is refusing our Phase 1 proposals: Brandväggen hittar ingen passande anslutning eller profilen matchar inte. Kontrollera IKE-version, Listening Interface, peer-adress, Local/Remote ID och profil.
peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found eller Remote peer reports we failed to authenticate: ID:n och autentisering matchar inte den förväntade peer-konfigurationen.
invalid HASH_V1 payload length eller decryption failed: Med IKEv1 är orsaken ofta fel PSK. Med IKEv2 visas oftare AUTH_FAILED.
Motparten når en annan publik adress eller så vidarebefordras UDP 500/4500 inte korrekt av NAT, router eller operatör.
För certifikat matchar inte certifikatkedjan, utfärdande CA, giltighet eller förväntat ID.

Om ett certifikat har återkallats före utgångsdatumet eller återkallningens effekt fortfarande är oklar ska issuer, serienummer, thisUpdate, nextUpdate och den tjänstespecifika avvisningen kontrolleras tillsammans. Den säkra processen beskrivs i Importera och testa Certificate Revocation Lists i Sophos Firewall.

Local ID på den ena sidan måste motsvara Remote ID på den andra och tvärtom. Jämför först ID:n och lagrad PSK på båda sidor. Om PSK måste bytas ska ändringen samordnas på båda motparterna under ett servicefönster; osynliga blanksteg och kopiering från lösenordshanterare är vanliga orsaker. Ett felaktigt ID kan hindra matchning av motparten innan förväntad PSK kontrolleras.

Vid Remote peer is refusing our Phase 1 proposals, jämför fas 1-värdena samt Gateway address och Listening interface på båda sidor. Om värdena matchar måste motpartens administratör kontrollera konfigurationen och loggarna från samma tidpunkt på den sida som avvisar anslutningen. Vid Remote peer reports we failed to authenticate, be även administratören bekräfta om den förväntade ID-typen skiljer sig, till exempel en IP-adress i stället för ett DNS-namn. Local ID och Remote ID måste matcha korsvis i både typ och värde; korrigera endast den bekräftade avvikelsen och kontrollera tunneluppbyggnaden igen. Dokumentera tidigare värden före en ändring och samordna den med motpartens administratör under ett underhållsfönster; återställ det dokumenterade tillståndet om det inte sker någon förbättring. Dela inte PSK i loggar eller supportpaket.

Meddelandena Error on decryption of the exchange eller Information field of the IKE request is malformed or not readable tyder först på olika förhandsdelade nycklar. Först när PSK har bekräftats vara identisk på båda sidor och felet kvarstår ska den mer sällsynta orsak som Sophos anger undersökas: paket som skadas hos internetleverantören eller i en router eller brandvägg tidigare på vägen. Undersök den berörda vägen tillsammans med leverantören eller ansvarig administratör med hjälp av samtidiga, snävt filtrerade paketinsamlingar och jämför WAN-värdena för MTU/MSS med leverantörens specifikationer. En enda paketinsamling bevisar inte att paket har skadats. Den befintliga guiden om MTU och MSS beskriver utgångskontroll, säkra tester och rollback; sänk inte värden globalt utifrån antaganden. TCP MSS är ingen lösning på fel i IKE-förhandlingen. Kontrollera insamlingarna för känsliga data innan de delas.

Fas 2: Traffic Selectors och Child SA

Om fas 1 är etablerad men Child SA saknas är vanligtvis subnäten eller fas 2-värdena olika.

traffic selectors ... inacceptable
failed to establish CHILD_SA
received traffic selectors didn't match
Remote peer reports INVALID_ID_INFORMATION
avvikande värden för TSi och TSr
NO_PROPOSAL_CHOSEN efter Phase 1 is up och Initiating establishment of Phase 2 SA

Enbart NO_PROPOSAL_CHOSEN räcker inte för klassificering: före fas 1 pekar det på IKE-/fas 1-värden, efter en lyckad fas 1 på ESP, PFS eller andra fas 2-värden.

För en fullständig jämförelse av fälten under General settings, Phase 1, Phase 2 och DPD finns Förstå och konfigurera IPsec-profiler säkert i Sophos Firewall.

Nätverken måste vara spegelvända. Om Sophos lokalt förväntar sig 172.16.10.0/24 och på fjärrsidan 10.20.30.0/24 måste motparten erbjuda 10.20.30.0/24 till 172.16.10.0/24. Även /24 på ena sidan mot en enskild värd på den andra, eller värdobjekt som underhålls på olika sätt, kan förhindra Child SA.

Om NO_PROPOSAL_CHOSEN eller Remote peer reports INVALID_ID_INFORMATION kvarstår efter en lyckad fas 1 trots att fas 2-värdena för Encryption, Authentication, PFS-/DH-grupp och spegelvända subnät har jämförts, be motpartens administratör kontrollera förhandlingsloggarna från samma tidpunkt på fjärrsidan. Ange tunnelnamn, tidpunkt, erbjudna selectorvärden och INSTALLED-status för berörd Child SA eller selector från ipsec statusall; dokumentera uttryckligen om just den SA:n saknas i stället för att dra slutsatsen att alla SA saknas utifrån felet. ip xfrm policy kompletterar kontrollen av policyer, men bevisar inte att SA är installerade. Dokumentera tidigare värden och rollbackförfarande före en ändring och kom överens om ett underhållsfönster. Ändra därefter endast den belagda avvikelsen under samordnade former och kontrollera tunneluppbyggnaden och samma testflöde igen; återställ tidigare tillstånd om det inte sker någon förbättring.

Tunneln är uppe men ingen trafik passerar

I Advanced Shell visar följande kommando SA, förhandlade nätverk och byte-räknare:

ipsec statusall

Det viktiga är ESTABLISHED, INSTALLED och räknarna i båda riktningarna. Om båda ligger kvar på noll eller inte ökar når testtrafiken troligen inte tunneln. Om endast den utgående sidan ökar saknas vanligtvis returvägen eller en regel hos motparten. Om endast inkommande byte ökar är den lokala rutten, lokala regeln eller målsystemet misstänkt.

Följ ett testflöde

Ett snävt test är mer informativt än flera parallella ping:

Source IP: 172.16.10.25
Destination IP: 10.20.30.15
Service: ICMP eller TCP 443
förväntad riktning: LAN till VPN
förväntad regel: LAN_to_VPN_Branch

Kontrollera därefter i följande ordning:

Aktivera Log firewall traffic i den berörda regeln.
Filtrera Log Viewer efter Source, Destination och Rule ID.
Starta Packet Capture med host 172.16.10.25 and host 10.20.30.15.
Kör testet exakt en gång.
Jämför regel, NAT Rule ID, vidarebefordran, svar och byte-räknare.
Kontrollera returväg, fjärrregel och målsystem hos motparten.

Packet Capture använder en begränsad buffert och stoppar när den är full. Vyn visar bland annat Rule ID, NAT ID, Status och Reason. Under en standardinsamling leds accelererad FastPath-trafik normalt tillfälligt via SlowPath. Kontrollera buffertstatus, filter och testtid innan en tom eller stoppad insamling tolkas som bevis på att trafik saknas.

Om inget paket når Sophos Firewall ligger orsaken tidigare i trafikvägen, exempelvis i klientgateway, VLAN eller lokal routing. Om paketet kommer fram men inte vidarebefordras är det regel, NAT, rutt eller en Security Feature som inte stämmer. Den fullständiga regelkontrollen finns i Kontrollera brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Routing och XFRM

För policy-based IPsec skapar SFOS VPN-rutter i backend. De visas inte i den vanliga routingvyn. Läs manuella IPsec Routes och Route Precedence i Device Console:

system ipsec_route show
system route_precedence show

Standardordningen är static, sdwan_policyroute, vpn. En post som saknas i den vanliga vyn bevisar därför inte ett routingfel. Jämför Diagnostics > Tools > Route lookup, brandväggsloggen och Packet Capture för det aktuella testflödet.

För route-based IPsec beror vägen på typen av XFRM-gränssnitt:

Any/Any eller Dual: XFRM-gränssnittet har IP-adresser. En statisk, SD-WAN- eller dynamisk rutt måste styra fjärrtrafiken dit.
Specifika Traffic Selectors: SFOS skapar den statiska rutten automatiskt. Ingen IP-adress eller extra rutt kan tilldelas XFRM-gränssnittet.

Kontrollera gränssnittet under Network > Interfaces och vägen under Diagnostics > Tools > Route lookup. Device Console visar konfigurerade statiska rutter:

show static-route

Kontrollera XFRM-tillstånd i Advanced Shell:

ip xfrm state
ip xfrm policy

Vid flera XFRM-gränssnitt med IP-adresser ska även transitnäten jämföras: varje gränssnitt behöver ett eget nät utan överlappning. Olika enskilda IP-adresser räcker inte. xfrm1 med 192.168.0.1/24 och xfrm2 med 192.168.0.6/24 tillhör båda 192.168.0.0/24; även 192.168.0.1/16 på xfrm1 överlappar med 192.168.0.6/24 på xfrm2, eftersom nätet /16 omfattar nätet /24. Exemplen visar ett fel, inte rekommenderade adresser. Det gäller gränssnittens transitnät, inte de skyddade LAN-näten i Traffic Selectors.

⚠️ Ändrad XFRM-adressering kan bryta tunnelvägen och administrationsåtkomsten. Dokumentera först IP-adresser, prefix och beroende rutter på båda sidor och ordna oberoende administrationsåtkomst samt ett underhållsfönster. Ändra under Network > Interfaces endast de berörda gränssnitten med IP-adresser till tillgängliga transitnät utan överlappning och samordna ändringarna av motpartens adressering och beroende rutter. Kontrollera därefter Route lookup, samma testflöde och byte-räknarna i båda riktningarna. Återställ dokumenterade adresser, prefix och rutter på båda sidor om det inte sker någon förbättring. Vid specifika Traffic Selectors gäller fortfarande: tilldela ingen XFRM-IP-adress eller extra rutt.

Om flera anslutningar använder samma lokala nät och fjärrnät som alternativa vägar måste val och failover vara tydligt definierade. Lägg policy-based anslutningar och route-based anslutningar med specifika Traffic Selectors i samma IPsec-failovergrupp. Any/Any XFRM-tunnlar kan i stället växla via SD-WAN-rutter; den länkade proceduren beskriver ordning, Health Check och kontrollerat växlingstest.

Kontrollera NAT efter tunneltyp

NAT är tillåtet men ersätter inte en rutt. Kontrollera först att vägen för den ursprungliga eller översatta destinationen väljer rätt tunnel och därefter att motparten förväntar sig adresserna som faktiskt används.

Om lokala nät och fjärrnät är identiska räcker inte en enskild SNAT-anmärkning. Använd NAT för överlappande IPsec-nätverk beskriver den fullständiga spegelvända proceduren för adressering, tunnel, regler och routing.

Policy-based med SNAT: den avsedda SNAT-regeln kräver Outbound interface Any. Standard-SNAT-regeln med specifika WAN-portar matchar inte policy-based IPsec-trafik.
Route-based med Any/Any eller Dual: XFRM-gränssnittet har en IP-adress och kräver en explicit rutt. Avgör om och hur översättning sker från den matchande NAT-regeln och Packet Capture; härled det inte enbart från tunneltypen.
Route-based med specifika Traffic Selectors: SFOS skapar rutten automatiskt och tilldelar inte XFRM-gränssnittet någon IP-adress. Att anta MASQ till en förmodad XFRM-IP är därför ingen tillförlitlig diagnos; kontrollera i stället ursprunglig och översatt Source samt matchande NAT Rule ID.

Dokumentera ursprunglig och översatt Source, tillåt dem hos motparten och säkerställ returvägen. NAT på Sophos Firewall förklarar grunderna och regelordningen.

Instabilitet och specialfall i SFOS 22

Om trafiken stannar först senare, jämför tidsstämplar i tunnelstatus, strongswan.log, dgd.log, WAN-händelser och applikationstest. Vanliga orsaker är:

Tredjepartsleverantören använder traffic-based Rekeying. Sophos Firewall stöder time-based Rekeying.
Vid policy-based IPsec avslutar en inaktivitetstimeout på fjärrbrandväggen anslutningen efter en period utan trafik. Jämför tillsammans med motpartens administratör timeouten för den berörda VPN-anslutningen med tidpunkten för nedkopplingen. Dokumentera tidigare värde och tillämpningsområde före ändringen; om orsaken bekräftas, inaktivera timeouten för den anslutningen hos motparten under ett överenskommet testfönster. Anslutningen kan då förbli upprättad under inaktivitet. Vänta därefter ut den tidigare problematiska inaktiva perioden och kontrollera samma testflöde, tunnelstatus och byte-räknare. Återställ motpartens tidigare inställning om det inte sker någon förbättring. Detta ändrar inte globala SFOS-timeouter, nycklarnas livstider eller DPD.
Båda sidor genomför rekey samtidigt. Förskjut medvetet fas 1- och fas 2-nycklarnas livstider mellan Initiator och Responder.
Det tilldelade gränssnittet har inaktiverats. Tunnlar i Initiator-läge kopplas ned omedelbart, anslutningar i Responder-läge senast efter inaktivitet eller DPD-timeout.
Stora överföringar misslyckas trots att ett litet test fungerar. Kontrollera då MTU och MSS.

Upprepade brandväggskrascher vid multicast via VPN

Om krascherna sammanfaller med multicasttrafik genom en VPN-tunnel ska firmwareversion och build, berörd tunnel, tidpunkter samt tillgängliga diagnostik- eller kraschdata först dokumenteras. Sophos bekräftar problemet som NC-180433 och har åtgärdat det i SFOS 22.0 MR2 Build 546.

Den offentliga problembeskrivningen anger varken en särskild tunneltyp eller multicastdesign och ger ingen CLI-workaround. På en äldre SFOS 22-build ska uppgraderingsvägen kontrolleras, systemet uppdateras till MR2 Build 546 eller en nyare godkänd version och samma trafik därefter testas på nytt under kontrollerade former. Ändra inte tunnelparametrar, IPsec Acceleration eller tjänster utifrån antaganden. Om brandväggen fortsätter att krascha på MR2 eller senare ska insamlade data lämnas till Sophos Support i stället för att problemet automatiskt fortsätter att tillskrivas NC-180433.

Den normala konfigurationen och det kontrollerade acceptanstestet beskrivs i Multicast Routing i Sophos Firewall; kraschen som beskrivs här är fortfarande ett firmwarebundet specialfall.

IKEv2-paket fragmenteras

Vid det kända problemet NC-136352 kan standardprofilen för IKEv2 erbjuda så många DH-grupper att IKE-paketen blir större än 1'500 byte. Om en mellanliggande komponent kasserar fragment eller PMTU-information skickar Initiator upprepade gånger medan Responder inte ser något.

Kontrollera peer i Advanced Shell när felbilden stämmer exakt:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Erbjud därefter endast den DH-grupp som faktiskt behövs i IPsec-profilen eller betydligt färre grupper. Allmänna tcpdump-filter och PCAP-export beskrivs i Sophos Firewall tcpdump.

PPPoE-alias och IPsec Acceleration

NC-181526 påverkar SFOS 22.0 GA Respin Build 411 eller MR1 på vissa XGS Appliances: tunneln använder ett aliasgränssnitt på en PPPoE-WAN-port, är ansluten men transporterar ingen nyttotrafik när IPsec Acceleration är aktiv. XGS 88/88w, 108/108w, 118/118w och 128/128w är undantagna.

Den aktuella Sophos Known Issues List anger SFOS 22.0.2 MR2 Build 546 som fixversion. NC-181526 visas dock inte separat i den publicerade MR2-fixlistan. Upprepa därför samma testflöde efter uppgraderingen i stället för att härleda korrigeringen enbart från versionsuppgiften.

⚠️ Inaktivering av IPsec Acceleration är global, startar om alla IPsec-tunnlar och orsakar ett avbrott. Testa endast i ett underhållsfönster när kombinationen av build, maskinvara, PPPoE-alias och felbild stämmer exakt.

Följande kommandon körs i Device Console:

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

Återställ tillståndet som dokumenterades före testet om det inte sker någon förbättring. Om acceleration var aktiv, använd:

system ipsec-acceleration enable

SFOS 22.0 MR2 åtgärdar med NC-180520 ett liknande men annorlunda alias-IP-fall: XFRM-gatewayen kunde förbli oåtkomlig med aktiv Acceleration när ESP kom in via en annan WAN-port. De två Issue ID-numren får inte likställas. Ytterligare kontroller före och efter uppgradering finns i SFOS 22 Upgrade Check.

Validering och eskalering

Upprepa samma enskilda testflöde efter varje ändring och dokumentera minst följande punkter:

Tidpunkt, tunnelnamn, peer-IP, Source, Destination och Service
WebAdmin-status och ipsec statusall före och efter testet
tilldelad brandväggs- och NAT-regel
Packet Capture och räknare i båda riktningarna
returväg och fjärrregel hos motparten
ändring, resultat och förberedd rollback

Stäng därefter endast av StrongSwan-debug som aktiverades under denna procedur. Ändra inte ett befintligt läge innan ansvarig och syfte är klarlagda. Spara relevanta loggar målinriktat för Sophos Support. Spara Sophos Firewall-loggar beskriver exporten. Kontrollera större loggpaket och Packet Captures för känsliga data innan de delas.