Sophos Firewall IPsec VPN Felsökning

IPsec Site-to-Site VPN märks ofta knappt så länge de fungerar. Men om en tunnel inte kommer upp, förblir instabil efter en återanslutning eller visas som ansluten utan att transportera trafik behövs en tydlig ordning för analysen. Annars är det lätt att hoppa mellan PSK, rutter, brandväggsregler och loggar utan att hitta den verkliga orsaken.

Artikeln förklarar hur du systematiskt kontrollerar IPsec-anslutningar på Sophos Firewall: först tunneluppbyggnaden, därefter de förhandlade nätverken och slutligen det faktiska paketflödet. Om en ny förbindelse mellan två platser först ska planeras eller konfigureras, börja med Konfigurera Site-to-Site IPsec VPN på Sophos Firewall. För allmänna CLI-grunder finns även Sophos Firewall CLI-felsökning: viktiga kommandon.

Innan felsökningen

Först bör du kort dokumentera utgångsläget. Detta verkar banalt, men det sparar mycket tid eftersom många IPsec-problem uppstår från asymmetriska antaganden: Den ena sidan tror att den ansluter nätverk A till nätverk B, men den andra sidan förväntar sig olika ID, olika subnät eller en annan IKE-version.

Viktiga punkter:

• Tunnelnamn: till exempel azure-vpn
• Lokal gateway: Sophos Firewalls WAN-adress eller FQDN
• Fjärrgateway: motpartens publika IP-adress eller FQDN
• IKE-version: IKEv1 eller IKEv2
• Autentisering: förhandsdelad nyckel eller certifikat
• Lokalt ID/fjärr-ID: IP-adress, FQDN eller e-postliknande identifierare
• Lokala nätverk: till exempel 172.16.10.0/24
• Fjärrnätverk: till exempel 10.20.30.0/24
• VPN-typ: policybaserad eller ruttbaserad
• Gatewaytyp: Initiate the connection, Respond only eller failover-grupp
• IPsec-profil: fas 1, fas 2, DH-grupper, PFS och livstider
• Förväntad trafik: källa, destination, port och riktning

Med policybaserad IPsec är de lokala och fjärranslutna nätverken en del av tunnelförhandlingen. Med ruttbaserad IPsec är det också viktigt vilka rutter som pekar mot tunnelgränssnittet. Om trafiken går åt fel håll trots en aktiv tunnel är IPsec-rutter, statiska rutter, SD-WAN-policyrutter eller ruttprioriteten på Sophos Firewall ofta inblandade.

Om tunneln är uppe och små tester fungerar men större överföringar fastnar bör du även kontrollera MTU och MSS. Arbetsgången finns i Kontrollera MTU och MSS vid VPN-problem på Sophos Firewall.

⚠️ Felsökningsloggar och Packet Captures kan innehålla känslig data, såsom offentliga IP-adresser, interna nätverk, värdnamn eller nyttolaster. Sådana uppgifter bör endast samlas in specifikt och under en begränsad tid och kontrolleras innan de vidarebefordras.

Diagnostisk arbetsgång

En enkel sekvens hjälper i praktiken:

1. Kommer tunneln upp? Om inte, kontrollera först IKE-version, IPsec-profil, ID:n, PSK/certifikat, NAT-T och om motparten kan nås.
2. Upprättas fas 2? Om inte, kontrollera trafikväljare, lokala och fjärranslutna nätverk, PFS och fas 2-förslag.
3. Är en säkerhetsassociation installerad? Om ja, kontrollera ipsec statusall och följ byte-räknarna.
4. Går trafik genom tunneln? Om inte, kontrollera brandväggsregler, NAT, routing, ruttprioritet, IPsec-rutter och returväg.
5. Kan du se några paket? Om det är oklart, kombinera Log Viewer och Packet Capture.

En vanlig missuppfattning är att en grön tunnelstatus bevisar att allt fungerar. Den visar bara att IPsec har förhandlats. Den visar inte att brandväggsreglerna och rutterna är korrekta eller att motparten känner till returvägen.

Innan du byter till Advanced Shell är det värt att ta en titt på WebAdmin-listorna:

• Under Site-to-site VPN > IPsec kan du använda Show additional properties för att visa ytterligare kolumner som Local subnet, Remote subnet, Gateway type och Profile.
• Under Profiles > IPsec profiles kan du också visa ytterligare egenskaper för att jämföra fas 1- och fas 2-värden snabbare.

Det ersätter inte en logganalys, men förhindrar enkla fel: fel profil, fel gatewaytyp, samma subnät i flera tunnlar eller en tunnel som inte ingår i den förväntade failover-gruppen.

Vilken nivå är påverkad?

Innan du aktiverar felsökningsloggar bör du klassificera problemet översiktligt. Då blir det snabbt tydligt om du behöver undersöka IKE, fas 2, routing eller paketflöde.

• Tunneln förblir nere: Problemet är förmodligen med 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 uppe och nere: Fokusera på rekey, DPD, WAN-stabilitet eller förslag. Jämför tidsstämplar, DPD, livstider och WAN-händelser.
• Fas 1 är på plats, men ingen Child SA: Fokus på trafikväljare, fas 2-förslag eller PFS. Kontrollera lokala och fjärranslutna nätverk i spegelbild.
• Tunneln är grön, men byte-räknare förblir tomma: Trafiken når förmodligen inte tunneln. Kontrollera brandväggsregeln, NAT, rutt och klientgateway.
• Endast utgående byte ökar: Returvägen eller motparten saknas. Kontrollera brandväggen och rutten hos motparten samt målsystemet.
• Packet Capture visar paket utan en matchningsregel: Regelordning, zon eller tjänst matchar inte. Jämför Log Viewer, Policy Test och Rule ID.

Denna klassificering ersätter inte en detaljerad analys. Den förhindrar däremot att du söker efter ett fas 2-fel bland brandväggsreglerna eller återställer den förhandsdelade nyckeln i onödan när problemet ligger i returvägen.

Samla in loggar

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

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

Du öppnar Advanced Shell med SSH och byter till loggkatalogen vid behov:

cd /log

Liveloggen kan följas direkt:

tail -f /log/strongswan.log

Om flera tunnlar är aktiva bör du filtrera. Detta kan göras via tunnelnamnet, en peer-IP eller en typisk feltext:

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

less är ofta mer praktiskt för befintliga loggfiler:

less /log/strongswan.log

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

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

Aktivera StrongSwan-felsökning

Om den normala loggen inte räcker kan du ställa in StrongSwan-tjänsten till felsökningsläge:

service strongswan:debug -ds nosync

Kontrollera sedan om tjänsten körs i felsökningsläge:

service -S | grep strongswan

Utdata ska visa tillståndet RUNNING,DEBUG vid strongswan. Anslut sedan tunneln igen eller reproducera specifikt felet och observera loggen:

tail -f /log/strongswan.log

Samma debug-kommando inaktiverar felsökningsläget igen:

service strongswan:debug -ds nosync

⚠️ Tillåt bara felsökning att köra så länge som det verkligen behövs. IPsec-Debug kan generera stora loggfiler mycket snabbt och ta upp onödigt utrymme på brandväggen.

Fas 1: IKE, ID:n och autentisering

Om tunneln inte upprättas alls ligger orsaken vanligtvis före eller under fas 1. Gatewayerna förhandlar då ännu inte om näten för nyttotrafiken, utan först om IKE, autentisering och de båda sidornas identiteter.

Typiska orsaker:

• IKE-versionen matchar inte
• IPsec-profilen eller förslaget matchar inte
• lokalt eller fjärr-ID är annorlunda än förväntat
• Den förhandsdelade nyckeln är felaktig
• Motparten når fel publik IP-adress
• NAT-T eller portvidarebefordran för UDP 500 och 4500 är felaktig
• Certifikat, CA eller giltighet passar inte med certifikatbaserad autentisering

No IKE config found

En loggpost som no IKE config found eller NO_PROPOSAL_CHOSEN innebär ofta att Sophos Firewall inte kan hitta en lämplig IKE-konfiguration för det inkommande paketet. Detta kan bero på IKE-versionen, gatewayen, ID:n eller profilen IPsec.

Kontrollera:

• Är IKEv1 eller IKEv2 korrekt på båda sidor?
• Matchar motparten den konfigurerade fjärrgatewayadressen eller FQDN?
• Är lokal- och fjärr-ID korrekta?
• Är kryptering, autentisering, DH Group och Lifetime kompatibla?
• Använder motparten möjligen en annan publik IP-adress än den dokumenterade?

Peer authentication failed

peer authentication failed, AUTH_FAILED eller no matching peer config found tyder ofta på felaktiga ID:n eller autentiseringsuppgifter. Vid autentisering med förhandsdelad nyckel misstänks nyckeln ofta först. Det är ofta rätt, men inte alltid. Om ID:t inte stämmer kanske brandväggen inte ens kontrollerar den förväntade peer-konfigurationen.

Kontrollera:

• Lokalt ID på ena sidan motsvarar fjärr-ID på den andra sidan.
• Fjärr-ID för ena sidan motsvarar lokalt ID för den andra sidan.
• Stavning, versaler, FQDN och IP-adresser är exakt korrekta.
• Den förhandsdelade nyckeln angavs utan mellanslag i början eller slutet.
• Om det finns flera tunnlar till samma fjärrplats är det tydligt vilken anslutning som ska matchas.

Invalid HASH_V1 payload eller decryption failed

Med IKEv1 tyder meddelanden som invalid HASH_V1 payload length eller decryption failed ofta på en felaktig förhandsdelad nyckel. Med IKEv2 visas oftare AUTHENTICATION_FAILED eller AUTH_FAILED.

I praktiken bör den förhandsdelade nyckeln sättas på nytt på båda sidor i stället för att bara jämföras visuellt. Kopiering från lösenordshanterare, osynliga blanksteg och olika specialtecken är vanliga felkällor.

Fas 2: Trafikväljare och säkerhetsassociationer

Om fas 1 lyckas men fas 2 inte upprättas handlar det oftast om nätverken och Child SA. Sophos Firewall måste förhandla med motparten om vilka lokala och fjärranslutna undernät som får gå genom tunneln.

Typiska logganteckningar:

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

Kontrollera:

• Lokala och fjärranslutna nätverk konfigureras i spegelbild på båda sidor.
• Nätmask och enskilda värdobjekt är exakt korrekta.
• Det finns inga oönskade överlappningar med andra tunnlar.
• Flera fas 2-nätverk visas likadant på båda sidor.
• PFS, ESP-kryptering, autentisering och livstid hör ihop.

Exempel: Om Sophos Firewall förväntar sig 172.16.10.0/24 lokalt och 10.20.30.0/24 på distans måste motparten erbjuda exakt den omvända kombinationen, 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ätverk på den andra kan räcka för att Child SA inte ska installeras.

Tunneln är uppe men ingen trafik passerar

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

Kontrollera först statusen IPsec i Advanced Shell:

ipsec statusall

Det som är särskilt intressant är:

• Är IKE SA ESTABLISHED?
• Är Child SA INSTALLED?
• Vilka lokala och fjärrnätverk visas?
• Ökar byte-räknare i båda riktningarna?
• Ser du bara utgående byte men inga inkommande?
• Återansluts tunneln eller genomförs rekey regelbundet?

Med ruttbaserad IPsec kan du också kontrollera om XFRM tillstånd och policy överhuvudtaget är installerade:

ip xfrm state
ip xfrm policy

Om ipsec statusall visar en etablerad SA men ip xfrm state eller ip xfrm policy inte stämmer med den förväntade tunneln ligger problemet ofta inte längre i PSK eller förslaget, utan i trafikväljare, XFRM-konfiguration, rutter eller konkurrerande tunnlar.

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

Brandväggsregler

Lämpliga brandväggsregler krävs för trafik genom tunneln. Beroende på zonmodell är detta till exempel LAN till VPN, VPN till LAN eller en separat zon. Regeln måste korrekt täcka källa, destination, tjänst och riktning.

Viktigt:

• Aktivera Logga brandväggstrafik i relevanta regler.
• Kontrollera regelpositionen så att ingen mer allmän regel träder i kraft i förväg.
• Välj käll- och destinationszoner korrekt.
• För flera VPNs, använd inte objekt som är för breda om de kan matcha fel tunnel.
• Kontrollera medvetet säkerhetsfunktioner som IPS, webbfilter eller Application Control om de är aktiva i trafiken.

Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture beskriver en allmän testprocedur.

Routing och IPsec-rutter

Om brandväggen inte skickar trafik in i tunneln, kontrollera rutterna. För policybaserad IPsec kan routingtabellen IPsec också vara relevant:

ip route show table 220

Om manuell mappning är nödvändig kan en IPsec rutt på Sophos Firewall hjälpa. Om flera rutttyper konkurrerar bör du också kontrollera routingprioriteten för Sophos Firewall.

Kontrollera:

• Finns det en mer specifik statisk rutt som fångar upp trafik?
• Träder en SD-WAN-policyrutt i kraft före VPN-rutten?
• Pekar klientens gateway verkligen mot Sophos Firewall?
• Har motparten en returväg till det lokala nätverket?
• Finns det överlappande lokala och fjärrnätverk?

Med ruttbaserad VPN bör du även kontrollera XFRM-gränssnitten. Två XFRM-gränssnitt får inte konfigureras med överlappande eller identiska gränssnittsnät. Om xfrm1 och xfrm2 ligger i samma överföringsnät kan tunneln vara korrekt etablerad och ändå routa fel. Kontrollera i så fall XFRM-adresseringen under Network > Interfaces och använd unika nätverk.

Om flera IPsec-anslutningar använder samma lokala och fjärrundernät bör de inte ligga löst intill varandra. Sådana anslutningar hör hemma i en avsiktlig failover-design eller måste få en annan logik för trafikväljare och routing. Annars kan brandväggen inte på ett tillförlitligt sätt använda lämplig tunnel som förväntat.

NAT

NAT är inte i sig fel med IPsec, men måste konfigureras avsiktligt. Oavsiktlig MASQ eller en alltför bred SNAT-regel kan göra att motparten inte längre kopplar trafiken till det förväntade nätverket.

Kontrollera:

• Har en generisk MASQ-regel företräde framför en specifik VPN-NAT-regel?
• Förväntar sig fjärrparten ursprungliga IP-adresser eller översatta adresser?
• Är NAT dokumenterad på båda sidor?
• Matchar regeln NAT trafikriktningen?

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

SFOS 22: Kontrollera policybaserad IPsec och NAT noggrant

Vid uppgradering till SFOS 22 bör policybaserad IPsec kontrolleras särskilt noggrant. Sophos beskriver ett ändrat beteende för policybaserad IPsec VPN i versionsinformationen för SFOS 22. Dessutom dokumenteras NC-170917 bland de åtgärdade problemen: policybaserad IPsec-trafik kunde misslyckas när standardregeln för SNAT var konfigurerad med en statisk IP-adress i stället för MASQ.

I praktiken betyder detta: Om en policybaserad tunnel är grön efter uppgraderingen, men ingen eller endast enkelriktad trafik flyter, ska NAT inte behandlas som ett sekundärt ämne. En gammal, bred eller ovanligt anpassad standard SNAT-regel kan ändra exakt den trafik som fjärrplatsen förväntar sig med de ursprungliga nätverken.

Typiska kontrollpunkter efter en SFOS-22-uppgradering:

• Är tunneln verkligen policybaserad? Med policybaserad IPsec är lokala och fjärranslutna nätverk en del av förhandlingen. NAT kan bryta denna förväntning.
• Har standardregeln för SNAT ändrats? En statisk SNAT-IP i stället för MASQ kan få andra effekter än väntat efter en uppgradering.
• Finns det specifika VPN-NAT-regler? Dessa måste ligga ovanför allmänna SNAT- eller MASQ-regler och matcha trafikriktningen.
• Stämmer trafikväljare och NAT-objekt? Motparten måste förvänta sig antingen de ursprungliga nätverken eller de översatta nätverken, inte båda slumpmässigt.
• Visar Packet Capture förväntad käll-IP? Så här kan du se om brandväggen använder en annan källadress före tunneln.

Ett tydligt testfall består av en källa, ett mål och en tjänst. Kontrollera därefter brandväggsregeln, NAT-regeln, ipsec statusall, ip route show table 220, Packet Capture och motparten i tur och ordning. Om testet bara fungerar när NAT-regeln är inaktiverad eller flyttad ligger problemet inte i tunneluppbyggnaden utan i vägen in i tunneln.

För uppgraderingsplanering passar även Kontrollera Sophos Firewall före uppgradering till SFOS 22. För grunderna i NAT och regelordning är Förstå NAT på Sophos Firewall en bättre startpunkt.

Rekey, failover och gränssnittstillstånd

Om en tunnel fungerar först och sedan misslyckas, är den initiala konfigurationen inte alltid fel. Sedan bör du kontrollera utvecklingen över tiden:

• Trafikbaserad rekey hos tredjepartsleverantörer: Sophos Firewall förväntar sig tidsbaserad rekey. Om motparten framtvingar trafikbaserad rekey kan tunneln efter en tid fastna eller omförhandlas.
• Kollisioner vid nyckelutbyte: Om båda sidor genomför rekey samtidigt kan instabila faser uppstå. I sådana fall bör livstiderna för fas 1 och fas 2 samordnas mellan initiator och responder.
• Gränssnitt inaktiverat: Om det associerade gränssnittet inaktiveras kopplas en initierande Site-to-Site-tunnel från omedelbart. Responder- och fjärråtkomstanslutningar faller bort senast vid inaktivitet eller en DPD-timeout.
• DGD och Failover Group: För failover-scenarier, kontrollera dessutom dgd.log, gatewaystatus, primär/sekundär anslutning och identiska undernätspar.

Sådana fel upptäcks lättare med tidsstämplar än med en enskild ögonblicksbild. Vid intermittenta problem bör tunnelstatus, strongswan.log, dgd.log, WAN-händelser och applikationstest därför jämföras tidsmässigt.

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

Sophos dokumenterar NC-181526 i listan över kända problem: på vissa fysiska XGS-appliances med SFOS 22.0 GA Build 411 eller MR1 Build 490 kan en IPsec-tunnel via aliasgränssnittet på en PPPoE-WAN-port etableras men inte vidarebefordra nyttotrafik när IPsec acceleration är aktiv. XGS 88/88w, 108/108w, 118/118w och 128/128w är undantagna.

Denna punkt bör endast kontrolleras när de vanliga orsakerna inte passar. En grön tunnel utan trafik beror fortfarande oftast på regler, routing, NAT eller returvägen. Specialfallet i SFOS 22 blir mer sannolikt när samtliga följande villkor är uppfyllda:

• Sophos Firewall kör SFOS 22.0 GA Build 411 eller MR1 Build 490.
• Det är en berörd fysisk XGS-appliance och inte en av de undantagna modellerna.
• Den berörda tunneln använder ett aliasgränssnitt på en PPPoE-WAN-port.
• Tunneln upprättas, men ingen nyttotrafik passerar.
• Brandväggsregler, NAT, rutter, returväg och Packet Capture förklarar inte beteendet.
• IPsec acceleration är aktiv.

⚠️ Lösningen ändrar en global inställning och kan påverka andra IPsec-tunnlar. Dokumentera det aktuella tillståndet, genomför ändringen i ett underhållsfönster och testa den endast när felbilden stämmer exakt.

Sophos lista över kända problem anger parametern off. Den aktuella CLI-referensen för SFOS 22 dokumenterar disable; därför använder den här guiden den aktuella syntaxen och kontrollerar status före och efter ändringen:

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

Om testet inte förbättrar beteendet eller om ändringen ska återställas:

system ipsec-acceleration enable

Sophos anger SFOS 22.0.2 MR2 Build 546 som korrigering för NC-181526 i listan över kända problem. MR2 är publicerad, så en planerad uppdatering är den permanenta lösningen. Den publicerade listan över korrigeringar i MR2 anger inte ärende-ID:t separat; kopplingen till den korrigerade versionen baseras därför uttryckligen på listan över kända problem.

Praktisk kontroll:

1. Dokumentera tunnelstatus och ipsec statusall.
2. Kör Packet Capture med ett snävt käll-/destinationsfilter.
3. Kontrollera om tunneln verkligen använder ett aliasgränssnitt på en PPPoE-WAN-port.
4. Bekräfta SFOS 22.0 GA Build 411 eller MR1 Build 490 och en berörd hårdvarumodell.
5. Dokumentera status med system ipsec-acceleration show och testa ändringen endast målinriktat.
6. Jämför därefter status, byte-räknare, Packet Capture, Log Viewer och applikationstest.
7. Återställ utgångsläget med system ipsec-acceleration enable om ingen förbättring sker.

Kombinera Log Viewer och Packet Capture

Log Viewer visar vilken regel eller modul som utvärderade en anslutning. Packet Capture i WebAdmin, å andra sidan, visar om paket faktiskt anländer, vidarebefordras, släpps eller bearbetas av själva brandväggen.

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

• Käll-IP: 172.16.10.25
• Destination 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

Efteråt:

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

Interpretation:

• Inga paket kommer till Sophos Firewall: Kontrollera klient, gateway, VLAN, switch eller lokal routing.
• Paket kommer men vidarebefordras inte: Kontrollera brandväggsregeln, NAT, rutt eller säkerhetsfunktion.
• Paket skickas in i tunneln men svar saknas: Kontrollera returvägen, motparten, brandväggen hos motparten och fjärrvärden.
• Endast utgående byte i ipsec statusall: Kontrollera returväg eller fjärrpolicy.
• Endast inkommande bytes: Kontrollera lokal rutt, lokal brandväggsregel eller målsystem.

För längre paketinsamlingar eller supportärenden kan det vara lämpligt att samla in loggar målinriktat. Artikeln Spara loggar från Sophos Firewall för support och analys beskriver hur de exporteras korrekt.

Typiska felmönster

Följande felmönster avser de råa StrongSwan/Charon-loggsträngarna från strongswan.log. I WebAdmin visas ofta samma orsaker som ett översatt meddelande, till exempel no IKE config found som “Remote peer is refusing our Phase 1 proposals”, peer authentication failed som “Remote peer reports we failed to authenticate” eller traffic selectors ... inacceptable som “Remote peer reports INVALID_ID_INFORMATION”. Den som först kontrollerar WebAdmin istället för den råa loggen hittar rätt fall via denna koppling.

• no IKE config found: IKE-version, gateway, ID:n eller profil matchar inte. Jämför IKE-version, lokalt/fjärr-ID och förslag.
• NO_PROPOSAL_CHOSEN: Förslaget matchar inte. Kontrollera kryptering, autentisering, DH Group, PFS och Lifetime.
• peer authentication failed: ID eller autentisering matchar inte. Kontrollera lokalt/fjärr-ID och PSK eller certifikat.
• AUTH_FAILED: Förhandsdelad nyckel, certifikat eller ID matchar inte. Ange PSK på nytt och kontrollera certifikatkedjan och ID:n.
• traffic selectors ... inacceptable: Lokala nätverk och fjärrnätverk passar inte. Jämför subnät och värdobjekt i spegelbild.
• failed to establish CHILD_SA: Fas 2-nätverk eller ESP-förslag passar inte. Kontrollera trafikväljare, PFS, ESP-profil och livstider.
• Grön tunnel, inga byte: Trafiken når inte tunneln. Kontrollera brandväggsregel, rutt, NAT och klientgateway.
• Utgående byte, inga inkommande: Motparten eller returvägen saknas. Kontrollera reglerna och rutten hos motparten samt målsystemet.
• ipsec statusall visar SAs, men ruttbaserad trafik slutar senare: Kontrollera XFRM-tillstånd, XFRM-policy, överlappande XFRM-nätverk, failover-grupp och omnyckelbeteende.
• Flera tunnlar med samma subnät: Tunnlar hör till en failover-grupp eller måste ha en tydligt åtskild logik för trafikväljare och routing.
• Stora överföringar hänger sig trots en aktiv tunnel: Fokusera på MTU/MSS, paketförlust eller Path MTU Discovery. Kontrollera MTU och MSS för VPN-problem.
• SFOS 22, policybaserad IPsec, grön tunnel, trafik saknas: NAT, standard-SNAT eller trafikväljare stämmer inte korrekt efter uppgraderingen. Kontrollera standard-SNAT, VPN-NAT-regler, MASQ, Packet Capture och motparten.
• SFOS 22.0 GA Build 411 eller MR1 Build 490, PPPoE-WAN-alias, grön tunnel, ingen trafik: Möjligt känt problem NC-181526 på berörda fysiska XGS-appliances. Bekräfta modell och gränssnittstyp och testa först därefter system ipsec-acceleration disable målinriktat.
• Återanslutningar eller täta rekey-händelser: Fokusera på livstider, DPD, instabil anslutning eller förslag. 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 anslut tunneln igen.
• Kontrollera IKE-version, lokalt ID, fjärr-ID och förhandsdelad nyckel.
• Jämför trafikväljare eller lokala och fjärranslutna nätverk i spegelbild.
• Kontrollera ipsec statusall för ESTABLISHED, INSTALLED och byteräknare.

När tunneln är uppe:

• Kontrollera brandväggsreglerna i båda riktningarna.
• Aktivera loggning på de berörda reglerna.
• Filtrera Log Viewer med källa, destination och Rule ID.
• Kör Packet Capture med ett smalt filter.
• Kontrollera NAT-regler och ruttföreträde.
• För ruttbaserade VPN, kontrollera ip xfrm state, ip xfrm policy och XFRM gränssnittsnätverk.
• För flera liknande tunnlar, visa kolumner för failover-grupp och lokalt/fjärrundernät.
• För SFOS 22 med policybaserad IPsec kontrollera standard-SNAT, specifika VPN-NAT-regler och förväntad käll-IP.
• För SFOS 22.0 GA Build 411 eller MR1 Build 490 med PPPoE-WAN-alias, kontrollera om hårdvarumodellen och felbilden stämmer exakt med NC-181526.
• Bekräfta returvägen hos motparten.

För support eller längre analys:

• Aktivera debug endast en kort stund och inaktivera det sedan igen.
• Säkerhetskopiera relevanta loggar.
• Dokumentera tid, tunnelnamn, peer-IP, källa, destination och testsekvens.
• Kontrollera känslig information innan du delar.

FAQ