Felsökning av IPsec VPN på Sophos Firewall

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.

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.
Brandväggen kraschar upprepade gånger vid multicast via VPN: Framkalla inte problemet med fler belastningstester. Dokumentera firmwareversion, tidpunkter och tillgängliga diagnostikdata; NC-180433 är åtgärdat i SFOS 22.0 MR2 Build 546.

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.

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 /suchbegriff i filen.

StrongSwan-debug

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

service -S | grep strongswan

Om RUNNING,DEBUG redan visas ska du inte köra växlingskommandot igen som en tänkt aktivering. Använd befintlig debug och stäng sedan av den enligt beskrivningen nedan.

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

Om debug ännu inte är aktiv, kör växlingskommandot, kontrollera det nya tillståndet och återskapa felet exakt en gång:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

För strongswan ska RUNNING,DEBUG visas. Därefter stänger samma kommando av debugläget igen. Det andra kommandot bekräftar återgången:

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å ena sidan måste matcha Remote ID på den andra och tvärtom. PSK bör anges på nytt på båda sidor. Osynliga blanksteg eller kopiering från lösenordshanterare är vanliga orsaker. Ett felaktigt ID kan förhindra peer-matchningen innan förväntat PSK ens kontrolleras.

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.

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 förblir tomma 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.

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

Med policy-based IPsec hanterar SFOS 22 VPN-rutterna i backend. Manuella IPsec Routes och Route Precedence kontrolleras i Device Console:

system ipsec_route show
system route_precedence show

Kommandot som är känt från äldre felsökningsflöden i Advanced Shell är inte ett tillförlitligt bevis på en policy-based tunnel i SFOS 22:

ip route show table 220

I SFOS 22 syns policy-based VPN-rutter och manuella ipsec_route-poster inte där. En post som saknas bevisar därför varken att en rutt saknas eller att ett routingfel finns.

Med route-based IPsec måste det finnas en statisk, SD-WAN- eller dynamisk rutt till XFRM-gränssnittet och passande XFRM-tillstånd. Kontrollera XFRM-gränssnittet under Network > Interfaces och vägen under Diagnostics > Tools > Route lookup. Konfigurerade statiska rutter visas i Device Console:

show static-route

XFRM-tillstånden kontrolleras i Advanced Shell:

ip xfrm state
ip xfrm policy

XFRM-gränssnitt får inte använda överlappande överföringsnät. Anslutningar med identiska lokala subnät och fjärrsubnät måste tillhöra en gemensam IPsec-failovergrupp eller använda en tydligt annorlunda logik för väljare och routing. Den länkade arbetsgången förklarar gruppordning, Health Check och det kontrollerade växlingstestet.

Kontrollera NAT efter tunneltyp

NAT är tillåtet, men måste matcha tunneltypen och adresserna som motparten förväntar sig.

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: MASQ översätter Source till XFRM-IP-adressen. Denna syns i den inre IP-headern i Packet Capture.
Route-based med specifika Traffic Selectors: Om en MASQ-regel matchar släpper brandväggen trafiken eftersom dessa XFRM-gränssnitt inte har tilldelats någon IP-adress.

Den ursprungliga och den översatta Source-adressen måste dokumenteras, tillåtas hos motparten och omfattas av 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.
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.
Flera anslutningar med samma subnät ingår inte i samma failover-grupp.
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 Build 411 eller MR1 Build 490 på vissa fysiska 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 utgångsläget om det inte sker någon förbättring:

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 av StrongSwan-debug. 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.