Felsökning av Sophos Firewall IPsec VPN

IPsec Site-to-Site VPN:er är ofta diskreta så länge de fungerar. Men om en tunnel inte startar, förblir instabil efter en återanslutning eller visas som ansluten men inte transporterar någon trafik, behöver man en tydlig ordning för analysen. Annars hoppar man snabbt mellan PSK, rutter, brandväggsregler och loggar utan att se den egentliga orsaken.

Artikeln förklarar hur man systematiskt kontrollerar IPsec-anslutningar på Sophos Firewall: först tunneluppbyggnaden, sedan de förhandlade näten och slutligen det faktiska paketflödet. Om en ny plats-tunnel först planeras eller sätts upp, passar först Konfigurera Sophos Firewall Site-to-Site IPsec VPN. För allmänna CLI-grunder hjälper dessutom Sophos Firewall CLI Felsökning: viktiga kommandon.

Innan felsökning

Först bör man kort dokumentera utgångsläget. Det kan verka banalt, men sparar mycket tid eftersom många IPsec-problem orsakas av asymmetriska antaganden: Den ena sidan tror att den ansluter nät A med nät B, medan den andra sidan förväntar sig andra ID:n, andra subnät eller en annan IKE-version.

Viktiga punkter:

• Tunnelnamn: azure-vpn
• Lokalt Gateway: WAN-adress eller FQDN för Sophos Firewall
• Fjärrgateway: offentlig IP eller FQDN för motparten
• IKE-version: IKEv1 eller IKEv2
• Autentisering: Fördelad nyckel eller certifikat
• Lokal ID / Fjärr-ID: IP-adress, FQDN eller e-postliknande identifierare
• Lokala nät: 172.16.10.0/24
• Fjärrnät: 10.20.30.0/24
• VPN-typ: policy-baserad eller route-baserad
• Förväntad trafik: Källa, Destination, Port och Riktning

Vid policy-baserad IPsec är de lokala och fjärrnäten en del av tunnelavtalet. Vid route-baserad IPsec är det dessutom viktigt vilka rutter som pekar mot tunnelgränssnittet. Om trafik trots aktiv tunnel går i fel riktning är ofta IPsec Routes, statiska rutter, SD-WAN Policy Routes eller Route Precedence för Sophos Firewall inblandade.

Om tunneln är uppe och små tester fungerar men större överföringar fastnar, bör man dessutom kontrollera MTU och MSS. Proceduren för detta finns i Kontrollera MTU och MSS vid VPN-problem på Sophos Firewall.

⚠️ Debug-loggar och paketfångster kan innehålla känslig information, såsom offentliga IP-adresser, interna nät, värdnamn eller användardata. Sådan data bör endast samlas in målmedvetet och tidsbegränsat samt granskas innan den delas vidare.

Diagnosväg

För praktiken hjälper en enkel ordning:

1. Kommer tunneln upp? Om inte, kontrollera först IKE-version, IPsec-profil, ID:n, PSK/certifikat, NAT-T och tillgänglighet för motparten.
2. Byggs Fas 2 upp? Om inte, kontrollera trafikväljare, lokala och fjärrnät, PFS och Fas-2-förslag.
3. Är en säkerhetsassociation installerad? Om ja, kontrollera ipsec statusall och håll koll på byte-räknare.
4. Går trafik genom tunneln? Om inte, kontrollera brandväggsregler, NAT, routing, Route Precedence, IPsec Routes och returväg.
5. Ser man paket? Om oklart, kombinera Log Viewer och Packet Capture.

Ett vanligt tankefel: En grön tunnelstatus bevisar bara att IPsec har förhandlats fram. Det bevisar inte att brandväggsreglerna är korrekta, att rutterna är rätt eller att motparten känner till returvägen.

Vilken nivå är påverkad?

Innan debug-loggar bör man grovt kategorisera problemet. Det blir då snabbare klart om man ska leta vid IKE, Fas 2, routing eller paketflöde.

• Tunneln förblir nere: IKE, Gateway, ID:n, PSK, certifikat eller förslag Kontrollera strongswan.log live och jämför Fas 1
• Tunneln växlar ständigt mellan up och down: Rekey, DPD, WAN-stabilitet eller förslag Jämför tidsstämplar, DPD, livstid och WAN-händelser
• Fas 1 står, men ingen Child SA: Trafikväljare, Fas-2-förslag eller PFS Kontrollera lokala och fjärrnät spegelvända
• Tunneln är grön, men byte-räknare förblir tomma: Trafik når inte tunneln Kontrollera brandväggsregel, NAT, rutt och klientgateway
• Endast utgående bytes ökar: Returväg eller motpart saknas Kontrollera fjärrbrandvägg, fjärrrutt och målssystem
• Packet Capture visar paket utan passande regel: Regelordning, zon eller tjänst passar inte Jämför Log Viewer, Policy Test och Rule ID

Denna kategorisering ersätter inte en detaljerad analys. Men det förhindrar att man letar efter ett Fas-2-fel med brandväggsregler eller vid ett returvägsproblem onödigt återställer den fördelade nyckeln.

Samla loggar

Sophos Firewall använder StrongSwan för IPsec. De viktigaste loggarna finns i /log:

• strongswan.log: viktigaste IPsec-loggfilen för IKE, autentisering och Child SAs
• charon.log: Logg för IKE-demonen, användbar beroende på version och situation
• strongswan-monitor.log: Övervakning av IPsec-tjänsten
• dgd.log: Dead Gateway Detection och VPN-failover

Man öppnar via SSH Advanced Shell och byter vid behov till loggkatalogen:

cd /log

Live-loggen kan följas direkt:

tail -f /log/strongswan.log

Om flera tunnlar är aktiva bör man filtrera. Det kan göras via tunnelnamn, en peer-IP eller en typisk feltext:

tail -f /log/strongswan.log | grep -i azure-vpn

För befintliga loggfiler är less ofta bekvämare:

less /log/strongswan.log

I less kan man söka inom filen med /sökterm. Alternativt filtrerar grep direkt:

grep -i "no proposal" /log/strongswan.log

Aktivera StrongSwan-Debug

Om den vanliga loggen inte räcker kan man sätta StrongSwan-tjänsten i debug-läge:

service strongswan:debug -ds nosync

Sedan kontrollera om tjänsten körs i debug-läge:

service -S | grep strongswan

Utdata bör visa RUNNING,DEBUG för strongswan. Därefter återansluta tunneln eller medvetet återskapa felet och observera loggen:

tail -f /log/strongswan.log

Samma debug-kommando inaktiverar debug-läget igen:

service strongswan:debug -ds nosync

⚠️ Låt debug endast vara aktiv så länge det verkligen behövs. IPsec-debug kan snabbt generera stora loggfiler och onödigt ta upp lagringsutrymme på brandväggen.

Fas 1: IKE, ID:n och autentisering

Om tunneln inte byggs upp alls ligger orsaken oftast före eller under Fas 1. Då förhandlar gateways ännu inte om användardatanät, utan först IKE, autentisering och identiteterna för de två sidorna.

Typiska orsaker:

• IKE-versionen stämmer inte överens
• IPsec-profil eller förslag stämmer inte överens
• lokal eller fjärr-ID är annorlunda än förväntat
• Fördelad nyckel är felaktig
• Motparten når fel offentlig IP
• NAT-T eller portvidarebefordran på UDP 500 och 4500 är inte korrekt
• Certifikat, CA eller giltighet stämmer inte vid certifikatbaserad autentisering

No IKE config found

En loggpost som no IKE config found eller NO_PROPOSAL_CHOSEN betyder ofta att Sophos Firewall inte hittar en passande IKE-konfiguration för det inkommande paketet. Det kan bero på IKE-versionen, gateway, ID:n eller IPsec-profilen.

Kontrollera:

• Stämmer IKEv1 eller IKEv2 på båda sidor?
• Passar motparten till den konfigurerade fjärrgateway-adressen eller FQDN?
• Stämmer lokal och fjärr-ID?
• Är kryptering, autentisering, DH-grupp och livstid kompatibla?
• Använder motparten eventuellt en annan offentlig IP än dokumenterat?

Peer authentication failed

peer authentication failed, AUTH_FAILED eller no matching peer config found pekar ofta på icke-passande ID:n eller autentiseringsdata. Vid fördelad nyckel misstänks ofta nyckeln först. Det är ofta rätt, men inte alltid. Om ID:n inte stämmer, kontrollerar brandväggen kanske inte ens mot den förväntade peer-konfigurationen.

Kontrollera:

• Lokal ID på ena sidan motsvarar fjärr-ID på den andra sidan.
• Fjärr-ID på ena sidan motsvarar lokal ID på den andra sidan.
• Stavning, versaler och gemener, FQDN och IP-adresser stämmer exakt.
• Fördelad nyckel har angetts utan mellanslag i början eller slutet.
• Vid flera tunnlar till samma motpart är det tydligt vilken anslutning som ska matcha.

Invalid HASH_V1 payload eller decryption failed

Vid IKEv1 indikerar meddelanden som invalid HASH_V1 payload length eller decryption failed ofta en felaktig fördelad nyckel. Vid IKEv2 ser man snarare AUTHENTICATION_FAILED eller AUTH_FAILED.

I praktiken bör man sätta den fördelade nyckeln på båda sidor på nytt, istället för att bara visuellt jämföra den. Kopiera och klistra in från lösenordshanterare, osynliga mellanslag eller olika specialtecken är klassiska tidsfördröjare.

Fas 2: Trafikväljare och säkerhetsassociationer

Om Fas 1 lyckas men Fas 2 inte etableras handlar det oftast om näten och Child SA. Sophos Firewall måste förhandla med motparten om vilka lokala och fjärrsubnät som får gå genom tunneln.

Typiska loggindikationer:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi och TSr visar andra nät än förväntat

Kontrollera:

• Lokala och fjärrnät är spegelvända konfigurerade på båda sidor.
• Nätmask och enskilda värdobjekt stämmer exakt.
• Det finns inga oönskade överlappningar med andra tunnlar.
• Flera Fas-2-nät är lika avbildade på båda sidor.
• PFS, ESP-kryptering, autentisering och livstid passar ihop.

Exempel: Om Sophos Firewall lokalt förväntar 172.16.10.0/24 och fjärr 10.20.30.0/24, måste motparten exakt spegelvända erbjuda 10.20.30.0/24 till 172.16.10.0/24. Ett /24 på ena sidan och en enskild värd eller ett större nät på den andra sidan kan redan räcka för att Child SA inte installeras.

Tunneln står, men ingen trafik går

Om tunneln visas som ansluten men ingen trafik går igenom är IPsec i sig inte automatiskt orsaken. Då handlar det oftast om routing, brandväggsregler, NAT eller returvägen.

Först kontrollera IPsec-status i Advanced Shell:

ipsec statusall

Intressant är framför allt:

• Är IKE SA ESTABLISHED?
• Är Child SA INSTALLED?
• Vilka lokala och fjärrnät visas?
• Ökar byte-räknarna i båda riktningarna?
• Ser man bara utgående bytes men inga inkommande?
• Återansluts eller rekeyas det regelbundet?

Om Child SA är installerad men byte-räknarna förblir tomma når den förväntade trafiken troligen inte tunneln. Då kontrollerar man vägen före och efter IPsec.

Brandväggsregler

För trafik genom tunneln behövs passande brandväggsregler. Beroende på zonmodell är det till exempel LAN till VPN, VPN till LAN eller en egen zon. Regeln måste täcka källa, destination, tjänst och riktning korrekt.

Viktigt:

• Aktivera Log firewall traffic i de relevanta reglerna.
• Kontrollera regelposition så att ingen allmännare regel träder i kraft först.
• Välj källa och destinationszoner korrekt.
• Använd inte för breda objekt vid flera VPN:er om de kan matcha fel tunnel.
• Kontrollera säkerhetsfunktioner som IPS, webbfilter eller applikationskontroll medvetet om de är aktiva på trafiken.

En allmän kontrollprocedur beskrivs i Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Routing och IPsec Routes

Om brandväggen inte skickar trafiken i tunneln kontrollerar man rutterna. Vid policy-baserad IPsec kan dessutom IPsec-routingtabellen vara relevant:

ip route show table 220

Om en manuell tilldelning behövs kan en IPsec Route på Sophos Firewall hjälpa. Om flera routingtyper konkurrerar bör man dessutom kontrollera Routing Prioritet för Sophos Firewall.

Kontrollera:

• Finns det en mer specifik statisk rutt som fångar upp trafiken?
• Träder en SD-WAN Policy Route i kraft före VPN-rutten?
• Visar klientgateway verkligen till Sophos Firewall?
• Har motparten en returväg till det lokala nätet?
• Finns det överlappande lokala och fjärrnät?

NAT

NAT är inte i sig fel vid IPsec, men det måste vara medvetet konfigurerat. Oavsiktlig MASQ eller en för bred SNAT-regel kan leda till att motparten inte längre tilldelar trafiken till det förväntade nätet.

Kontrollera:

• Träder en generisk MASQ-regel i kraft före en specifik VPN-NAT-regel?
• Förväntar motparten original-IP-adresser eller översatta adresser?
• Är NAT dokumenterat på båda sidor?
• Passar NAT-regeln till trafikens riktning?

Om NAT är inblandat hjälper artikeln Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

SFOS 22: Policy-baserad IPsec och NAT medvetet kontrollera

Vid uppgraderingar till SFOS 22 bör policy-baserad IPsec kontrolleras särskilt noggrant. Sophos påpekar i SFOS-22-release-noterna ett ändrat beteende vid policy-baserad IPsec VPN. Dessutom dokumenteras i de åtgärdade problemen NC-170917: Policy-baserad IPsec-trafik kunde misslyckas om standard-SNAT-regeln var konfigurerad med en statisk IP-adress istället för MASQ.

För praktiken betyder det: Om en policy-baserad tunnel efter uppgraderingen är grön men ingen eller bara ensidig trafik flyter, bör NAT inte behandlas som ett sidotema. En gammal, bred eller ovanligt anpassad standard-SNAT-regel kan exakt förändra den trafik som motparten förväntar sig med de ursprungliga näten.

Typiska kontrollpunkter efter en SFOS-22-uppgradering:

• Är tunneln verkligen policy-baserad?: Vid policy-baserad IPsec är lokala och fjärrnät en del av förhandlingen. NAT kan bryta denna förväntan.
• Har standard-SNAT-regeln anpassats?: En statisk SNAT-IP istället för MASQ kan efter en uppgradering ha andra effekter än förväntat.
• Finns det specifika VPN-NAT-regler?: Dessa måste stå ovanför allmänna SNAT- eller MASQ-regler och passa till trafikens riktning.
• Stämmer trafikväljare och NAT-objekt överens?: Motparten måste antingen förvänta sig originalnäten eller de översatta näten, inte båda av en slump.
• Visar Packet Capture den förväntade käll-IP:n?: Så ser man om brandväggen använder en annan källadress före tunneln.

Ett rent testfall består av en källa, ett mål och en tjänst. Därefter kontrollerar man i tur och ordning brandväggsregel, NAT-regel, ipsec statusall, ip route show table 220, Packet Capture och motpart. Om testet bara fungerar med inaktiverad eller flyttad NAT-regel ligger problemet inte vid tunneluppbyggnaden utan vid vägen in i tunneln.

För uppgraderingsplaneringen passar dessutom Kontrollera Sophos Firewall före SFOS 22-uppgradering. För NAT-grunderna och regelordningen är Förstå NAT på Sophos Firewall den bättre starten.

SFOS 22: PPPoE-WAN med Alias-gränssnitt och IPsec-acceleration

Om en IPsec-tunnel är ansluten efter en uppgradering till SFOS 22.0 GA eller SFOS 22.0 MR1 men ingen trafik vidarebefordras, kan det i vissa uppsättningar finnas ett ytterligare specialfall. Sophos listar i listan över kända problem NC-181526: På XGS-hårdvara kan IPsec-tunnlar på alias-gränssnitt av en PPPoE-WAN-port byggas upp men inte vidarebefordra någon användartrafik om IPsec acceleration är aktiv.

Denna punkt bör endast kontrolleras om de vanliga orsakerna inte passar. En grön tunnel utan trafik är oftast fortfarande ett regel-, routing-, NAT- eller returvägsproblem. SFOS-22-specialfallet blir mer sannolikt om alla följande punkter sammanfaller:

• Sophos Firewall körs på SFOS 22.0 GA eller SFOS 22.0 MR1.
• Det handlar om XGS-hårdvara.
• Den berörda tunneln använder ett alias-gränssnitt på en PPPoE-WAN-port.
• Tunneln byggs upp men användartrafik uteblir.
• Brandväggsregler, NAT, rutter, returväg och Packet Capture förklarar inte beteendet.
• IPsec acceleration är aktiv.

Som en tillfällig lösning är det dokumenterat att inaktivera IPsec acceleration:

system ipsec-acceleration off

Detta bör inte användas som ett generellt IPsec-tuning-kommando. Ändringen bör göras i ett underhållsfönster eller en dokumenterad supportprocess, med före-/efter-test och tydlig koppling till det berörda felbilden. Sophos listar SFOS 22.0.2 MR2 som fix-version för detta kända problem. Om denna version är godkänd för den berörda miljön är en planerad uppdatering renare än en permanent bortglömd tillfällig lösning.

Praktisk kontrollprocedur:

1. Dokumentera tunnelstatus och ipsec statusall.
2. Utför Packet Capture med snäv käll-/destinationsfilter.
3. Kontrollera om tunneln verkligen använder ett alias-gränssnitt på en PPPoE-WAN-port.
4. Notera aktiv SFOS-version och hårdvarumodell.
5. Testa ändring av IPsec acceleration endast målmedvetet och dokumenterat.
6. Efter testet jämför byte-räknare, Packet Capture, Log Viewer och applikationstest.

Kombinera Log Viewer och Packet Capture

Log Viewer visar vilken regel eller modul som har bedömt en anslutning. Packet Capture i WebAdmin visar däremot om paket verkligen anländer, vidarebefordras, slängs eller hanteras av brandväggen själv.

För IPsec-felsökning bör man definiera ett så snävt test som möjligt:

• Käll-IP: 172.16.10.25
• Destinations-IP: 10.20.30.15
• Tjänst: ICMP eller TCP 443
• Förväntad riktning: LAN till VPN
• Förväntad regel: LAN_to_VPN_Branch

Därefter:

1. Aktivera loggning i brandväggsregeln.
2. Filtrera Log Viewer med käll-IP, destinations-IP och modul Firewall.
3. Starta Packet Capture med snäv filter, till exempel host 172.16.10.25 and host 10.20.30.15.
4. Återskapa testet exakt en gång.
5. Kontrollera om paket anländer, vidarebefordras och om svar kommer tillbaka.

Tolkning:

• Inget paket anländer till Sophos Firewall: Kontrollera klient, gateway, VLAN, switch eller lokal routing
• Paket anländer men vidarebefordras inte: Kontrollera brandväggsregel, NAT, rutt eller säkerhetsfunktion
• Paket skickas i tunneln, svar saknas: Kontrollera returväg, motpart, fjärrbrandvägg eller fjärrvärd
• Endast utgående bytes i ipsec statusall: Kontrollera returväg eller fjärrpolicy
• Endast inkommande bytes: Kontrollera lokal rutt, lokal brandväggsregel eller målssystem

För längre inspelningar eller supportfall kan det vara meningsfullt att samla loggar målmedvetet. Artikeln Säkra Sophos Firewall-loggar för support och analys beskriver en ren export.

Typiska felbilder

• no IKE config found: IKE-version, gateway, ID:n eller profil stämmer inte Jämför IKE-version, lokal/fjärr-ID och förslag
• NO_PROPOSAL_CHOSEN: Förslagsmismatch Kontrollera kryptering, autentisering, DH-grupp, PFS och livstid
• peer authentication failed: ID eller autentisering stämmer inte Kontrollera lokal/fjärr-ID och PSK/certifikat
• AUTH_FAILED: Fördelad nyckel, certifikat eller ID stämmer inte Sätt PSK på nytt, kontrollera certifikatkedja och ID:n
• traffic selectors ... inacceptable: lokala och fjärrnät stämmer inte Jämför subnät och värdobjekt spegelvända
• failed to establish CHILD_SA: Fas-2-nät eller ESP-förslag stämmer inte Kontrollera trafikväljare, PFS, ESP-profil och livstider
• Tunnel grön, inga bytes: Trafik når inte tunneln Kontrollera brandväggsregel, rutt, NAT och klientgateway
• Utgående bytes, inga inkommande: Motpart eller returväg saknas Kontrollera fjärrregler, fjärrrutt och målssystem
• Stora överföringar fastnar trots aktiv tunnel: MTU/MSS, paketförlust eller Path-MTU-Discovery Kontrollera MTU och MSS vid VPN-problem
• SFOS 22, policy-baserad IPsec, tunnel grön, trafik saknas: NAT, standard-SNAT eller trafikväljare stämmer inte efter uppgradering Kontrollera standard-SNAT, VPN-NAT-regler, MASQ, Packet Capture och motpart
• SFOS 22, PPPoE-WAN-alias, tunnel grön, ingen trafik: möjligt känt problem med IPsec acceleration Kontrollera gränssnittstyp, SFOS-version och system ipsec-acceleration off endast målmedvetet
• Återanslutningar eller frekventa rekeys: Livstid, DPD, instabil linje eller förslagstema Kontrollera rekey-tider, DPD, WAN-stabilitet och loggar

Praktisk checklista

Kontrollera omedelbart:

• Notera tunnelstatus och senaste felmeddelande i WebAdmin.
• Starta tail -f /log/strongswan.log och återanslut tunneln.
• Kontrollera IKE-version, lokal ID, fjärr-ID och fördelad nyckel.
• Jämför trafikväljare respektive lokala och fjärrnät spegelvända.
• Kontrollera ipsec statusall för ESTABLISHED, INSTALLED och byte-räknare.

Om tunneln står:

• Kontrollera brandväggsregler i båda riktningarna.
• Aktivera loggning på de berörda reglerna.
• Filtrera Log Viewer med källa, destination och Rule ID.
• Utför Packet Capture med snäv filter.
• Kontrollera NAT-regler och Route Precedence.
• Vid SFOS 22 med policy-baserad IPsec kontrollera standard-SNAT, specifika VPN-NAT-regler och förväntad käll-IP.
• Vid SFOS 22 med PPPoE-WAN-alias kontrollera om IPsec-acceleration-känt problem passar.
• Bekräfta returväg på motparten.

För support eller längre analys:

• Aktivera debug endast kort och inaktivera sedan igen.
• Säkra relevanta loggar.
• Dokumentera tid, tunnelnamn, peer-IP, källa, destination och testprocedur.
• Granska känslig data innan den delas vidare.

FAQ