Sophos Firewall IPsec VPN-problemen oplossen

IPsec Site-to-Site VPN’s vallen nauwelijks op zolang ze werken. Als een tunnel niet tot stand komt, na een herverbinding instabiel blijft of wel als verbonden wordt weergegeven maar geen verkeer transporteert, is een vaste volgorde voor de analyse nodig. Anders wordt al snel heen en weer geschakeld tussen PSK, routes, firewallregels en logs zonder de werkelijke oorzaak te vinden.

Dit artikel legt uit hoe men IPsec-verbindingen op Sophos Firewall systematisch controleert: eerst de tunnelopbouw, daarna de onderhandelde netwerken en ten slotte de daadwerkelijke pakketstroom. Voor het plannen of configureren van een nieuwe verbinding is Een Site-to-Site IPsec VPN op Sophos Firewall instellen het juiste beginpunt. Algemene CLI-basiskennis staat in Sophos Firewall CLI-troubleshooting: belangrijke opdrachten.

Voor de foutanalyse

Documenteer eerst kort de uitgangssituatie. Dit lijkt vanzelfsprekend, maar bespaart veel tijd. IPsec-problemen ontstaan vaak door asymmetrische aannames: de ene kant denkt netwerk A met netwerk B te verbinden, terwijl de andere kant andere ID’s, subnetten of een andere IKE-versie verwacht.

Belangrijke gegevens:

• Tunnelnaam: bijvoorbeeld azure-vpn
• Lokale gateway: WAN-adres of FQDN van Sophos Firewall
• Remote gateway: openbaar IP-adres of FQDN van de peer
• IKE-versie: IKEv1 of IKEv2
• Authenticatie: Preshared Key of certificaat
• Lokale ID / Remote ID: IP-adres, FQDN of een op een e-mailadres lijkende identifier
• Lokale netwerken: bijvoorbeeld 172.16.10.0/24
• Remote netwerken: bijvoorbeeld 10.20.30.0/24
• VPN-type: policy-based of route-based
• Gateway type: Initiate the connection, Respond only of failovergroep
• IPsec-profiel: Phase 1, Phase 2, DH-groepen, PFS en lifetimes
• Verwacht verkeer: bron, bestemming, poort en richting

Bij policy-based IPsec maken de lokale en remote netwerken deel uit van de tunnelonderhandeling. Bij route-based IPsec is daarnaast van belang welke routes naar de tunnelinterface wijzen. Als verkeer ondanks een actieve tunnel de verkeerde kant op gaat, zijn vaak IPsec Routes, statische routes, SD-WAN Policy Routes of de Route Precedence van Sophos Firewall betrokken.

Als de tunnel actief is en kleine tests werken, maar grotere overdrachten vastlopen, moeten ook MTU en MSS worden gecontroleerd. De werkwijze staat in MTU en MSS bij VPN-problemen op Sophos Firewall controleren.

⚠️ Debuglogs en Packet Captures kunnen gevoelige gegevens bevatten, zoals openbare IP-adressen, interne netwerken, hostnamen of payload. Verzamel deze gegevens alleen gericht en gedurende een beperkte periode, en controleer ze voordat ze worden gedeeld.

Diagnosepad

In de praktijk helpt deze volgorde:

1. Komt de tunnel tot stand? Zo niet, controleer eerst de IKE-versie, het IPsec-profiel, de ID’s, PSK of certificaat, NAT-T en de bereikbaarheid van de peer.
2. Wordt Phase 2 opgebouwd? Zo niet, controleer Traffic Selectors, lokale en remote netwerken, PFS en Phase-2-proposals.
3. Is een Security Association geïnstalleerd? Zo ja, controleer ipsec statusall en let op de bytetellers.
4. Loopt verkeer door de tunnel? Zo niet, controleer firewallregels, NAT, routing, Route Precedence, IPsec Routes en het retourpad.
5. Zijn pakketten zichtbaar? Combineer bij twijfel Log Viewer en Packet Capture.

Een veelgemaakte denkfout: een groene tunnelstatus bewijst alleen dat IPsec is onderhandeld. De status bewijst niet dat firewallregels en routes correct zijn of dat de peer het retourpad kent.

Bekijk voordat men naar de Advanced Shell gaat eerst de WebAdmin-lijsten:

• Onder Site-to-site VPN > IPsec kunnen via Show additional properties extra kolommen zoals Local subnet, Remote subnet, Gateway type en Profile worden weergegeven.
• Onder Profiles > IPsec profiles kunnen eveneens aanvullende eigenschappen worden getoond om de waarden van Phase 1 en Phase 2 sneller te vergelijken.

Dit gaat minder diep dan een log, maar voorkomt eenvoudige fouten: een verkeerd profiel, een verkeerd Gateway type, dezelfde subnetten in meerdere tunnels of een tunnel die geen deel uitmaakt van de verwachte failovergroep.

Welk niveau is betrokken?

Deel het probleem vóór het activeren van debuglogs globaal in. Zo wordt sneller duidelijk of de oorzaak bij IKE, Phase 2, routing of de pakketstroom ligt.

• Tunnel blijft down: waarschijnlijk ligt het probleem bij IKE, gateway, ID’s, PSK, certificaat of proposal. Bekijk strongswan.log live en vergelijk Phase 1.
• Tunnel wisselt voortdurend tussen up en down: richt de analyse op rekey, DPD, WAN-stabiliteit of proposal. Vergelijk tijdstempels, DPD, lifetime en WAN-events.
• Phase 1 staat, maar er is geen Child SA: richt de analyse op Traffic Selectors, de Phase-2-proposal of PFS. Vergelijk lokale en remote netwerken gespiegeld.
• Tunnel is groen, maar bytetellers blijven leeg: waarschijnlijk bereikt het verkeer de tunnel niet. Controleer firewallregel, NAT, route en clientgateway.
• Alleen uitgaande bytes nemen toe: het retourpad of de peer ontbreekt. Controleer remote firewall, remote route en doelsysteem.
• Packet Capture toont pakketten zonder passende regel: regelvolgorde, zone of service klopt niet. Vergelijk Log Viewer, Policy Test en Rule ID.

Deze indeling vervangt geen detailanalyse. Ze voorkomt wel dat een Phase-2-fout in firewallregels wordt gezocht of dat bij een retourpadprobleem onnodig de Preshared Key opnieuw wordt ingesteld.

Logs verzamelen

Sophos Firewall gebruikt StrongSwan voor IPsec. De belangrijkste logs staan in /log:

• strongswan.log: belangrijkste IPsec-log voor IKE, authenticatie en Child SAs.
• charon.log: log van de IKE-daemon, afhankelijk van versie en situatie nuttig.
• strongswan-monitor.log: monitoring van de IPsec-service.
• dgd.log: Dead Gateway Detection en VPN-failover.

Open via SSH de Advanced Shell en ga indien nodig naar de logdirectory:

cd /log

Het live-log kan direct worden gevolgd:

tail -f /log/strongswan.log

Filter bij meerdere actieve tunnels op tunnelnaam, peer-IP of een kenmerkende foutmelding:

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

Voor bestaande logbestanden is less vaak handiger:

less /log/strongswan.log

In less kan met /zoekterm binnen het bestand worden gezocht. grep kan ook rechtstreeks filteren:

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

StrongSwan-debug activeren

Als het normale log onvoldoende informatie geeft, kan de StrongSwan-service in debugmodus worden gezet:

service strongswan:debug -ds nosync

Controleer daarna of de service in debugmodus draait:

service -S | grep strongswan

De uitvoer moet voor strongswan de status RUNNING,DEBUG tonen. Verbind vervolgens de tunnel opnieuw of reproduceer het probleem gericht en bekijk het log:

tail -f /log/strongswan.log

Met dezelfde debugopdracht wordt de debugmodus weer uitgeschakeld:

service strongswan:debug -ds nosync

⚠️ Laat debug alleen actief zolang dit werkelijk nodig is. IPsec-debug kan snel grote logbestanden produceren en onnodig opslagruimte op de firewall innemen.

Phase 1: IKE, ID’s en authenticatie

Als de tunnel helemaal niet wordt opgebouwd, ligt de oorzaak meestal vóór of tijdens Phase 1. De gateways onderhandelen dan nog niet over de netwerken voor gebruikersverkeer, maar eerst over IKE, authenticatie en de identiteiten van beide kanten.

Typische oorzaken:

• IKE-versies komen niet overeen
• IPsec-profielen of proposals komen niet overeen
• lokale of remote ID wijkt af van de verwachting
• Preshared Key is onjuist
• de peer bereikt het verkeerde openbare IP-adres
• NAT-T of port forwarding voor UDP 500 en 4500 is niet correct
• certificaten, CA of geldigheid kloppen niet bij certificaatgebaseerde authenticatie

No IKE config found

Een logregel zoals no IKE config found of NO_PROPOSAL_CHOSEN betekent vaak dat Sophos Firewall geen passende IKE-configuratie vindt voor het binnenkomende pakket. De oorzaak kan liggen bij de IKE-versie, gateway, ID’s of het IPsec-profiel.

Controleer:

• Komt IKEv1 of IKEv2 aan beide kanten overeen?
• Komt de peer overeen met het geconfigureerde Remote Gateway-adres of FQDN?
• Kloppen de lokale en remote ID’s?
• Zijn encryption, authentication, DH Group en lifetime compatibel?
• Gebruikt de peer mogelijk een ander openbaar IP-adres dan gedocumenteerd?

Peer authentication failed

peer authentication failed, AUTH_FAILED of no matching peer config found wijst vaak op afwijkende ID’s of authenticatiegegevens. Bij een Preshared Key wordt vaak eerst de sleutel verdacht. Dat is dikwijls juist, maar niet altijd: als de ID niet klopt, controleert de firewall mogelijk niet eens de verwachte peer-configuratie.

Controleer:

• De Local ID van de ene kant komt overeen met de Remote ID van de andere kant.
• De Remote ID van de ene kant komt overeen met de Local ID van de andere kant.
• Spelling, hoofdletters, FQDN en IP-adressen komen exact overeen.
• De Preshared Key is zonder spaties aan het begin of einde ingevoerd.
• Bij meerdere tunnels naar dezelfde peer is duidelijk welke verbinding moet matchen.

Invalid HASH_V1 payload of decryption failed

Bij IKEv1 wijzen meldingen zoals invalid HASH_V1 payload length of decryption failed vaak op een onjuiste Preshared Key. Bij IKEv2 worden eerder AUTHENTICATION_FAILED of AUTH_FAILED weergegeven.

Stel de Preshared Key in de praktijk aan beide kanten opnieuw in plaats van hem alleen visueel te vergelijken. Copy-paste vanuit wachtwoordmanagers, onzichtbare spaties en afwijkende speciale tekens kosten vaak onnodig veel tijd.

Phase 2: Traffic Selectors en Security Associations

Als Phase 1 slaagt maar Phase 2 niet tot stand komt, ligt het probleem meestal bij de netwerken en de Child SA. Sophos Firewall moet met de peer onderhandelen welke lokale en remote subnetten door de tunnel mogen.

Typische logmeldingen:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi en TSr tonen andere netwerken dan verwacht

Controleer:

• Lokale en remote netwerken zijn aan beide kanten gespiegeld geconfigureerd.
• Netmaskers en afzonderlijke hostobjecten komen exact overeen.
• Er zijn geen ongewenste overlappingen met andere tunnels.
• Meerdere Phase-2-netwerken zijn aan beide kanten identiek geconfigureerd.
• PFS, ESP-encryption, authentication en lifetime komen overeen.

Voorbeeld: verwacht Sophos Firewall lokaal 172.16.10.0/24 en remote 10.20.30.0/24, dan moet de peer precies gespiegeld 10.20.30.0/24 naar 172.16.10.0/24 aanbieden. Een /24 aan de ene kant en één host of een groter netwerk aan de andere kant kan al voorkomen dat de Child SA wordt geïnstalleerd.

Tunnel staat, maar er loopt geen verkeer

Als de tunnel als verbonden wordt weergegeven maar geen verkeer doorlaat, is IPsec zelf niet automatisch de oorzaak. Meestal ligt het dan aan routing, firewallregels, NAT of het retourpad.

Controleer eerst de IPsec-status in de Advanced Shell:

ipsec statusall

Let vooral op:

• Is de IKE SA ESTABLISHED?
• Is de Child SA INSTALLED?
• Welke lokale en remote netwerken worden weergegeven?
• Lopen de bytetellers in beide richtingen op?
• Zijn alleen uitgaande bytes zichtbaar en geen inkomende?
• Wordt regelmatig opnieuw verbonden of gerekeyed?

Bij route-based IPsec kan daarnaast worden gecontroleerd of XFRM-state en -policy zijn geïnstalleerd:

ip xfrm state
ip xfrm policy

Toont ipsec statusall een gevestigde SA, maar passen ip xfrm state of ip xfrm policy niet bij de verwachte tunnel, dan ligt het probleem meestal niet meer bij PSK of proposal. Waarschijnlijker zijn Traffic Selectors, XFRM-configuratie, routes of concurrerende tunnels.

Als de Child SA is geïnstalleerd maar de bytetellers leeg blijven, bereikt het verwachte verkeer de tunnel waarschijnlijk niet. Controleer dan het pad vóór en na IPsec.

Firewallregels

Voor verkeer door de tunnel zijn passende firewallregels nodig. Afhankelijk van het zonemodel is dat bijvoorbeeld LAN naar VPN, VPN naar LAN of een eigen zone. De regel moet bron, bestemming, service en richting correct afdekken.

Belangrijk:

• Activeer Log firewall traffic in de relevante regels.
• Controleer de regelpositie, zodat niet eerst een algemenere regel matcht.
• Selecteer de juiste bron- en bestemmingszones.
• Gebruik bij meerdere VPN’s geen te brede objecten die de verkeerde tunnel kunnen matchen.
• Controleer bewust Security Features zoals IPS, Webfilter en Application Control als deze op het verkeer actief zijn.

Een algemene controleprocedure staat in Een firewallregel testen met Log Viewer, Policy Test en Packet Capture.

Routing en IPsec Routes

Als de firewall het verkeer niet naar de tunnel stuurt, moeten de routes worden gecontroleerd. Bij policy-based IPsec kan ook de IPsec-routingtabel relevant zijn:

ip route show table 220

Als handmatige toewijzing nodig is, kan een IPsec Route op Sophos Firewall helpen. Als meerdere routingtypen concurreren, moet ook de Routing Priority van Sophos Firewall worden gecontroleerd.

Controleer:

• Is er een specifiekere statische route die het verkeer onderschept?
• Matcht een SD-WAN Policy Route vóór de VPN-route?
• Wijst de clientgateway werkelijk naar Sophos Firewall?
• Heeft de peer een retourroute naar het lokale netwerk?
• Zijn er overlappende lokale en remote netwerken?

Controleer bij route-based VPN ook de XFRM-interfaces. Twee XFRM-interfaces mogen niet met overlappende of identieke interfacenetwerken worden geconfigureerd. Als xfrm1 en xfrm2 in hetzelfde transfernetwerk liggen, kan de tunnel correct worden opgebouwd maar toch verkeerd routeren. Controleer in dat geval de XFRM-adressering onder Network > Interfaces en gebruik unieke netwerken.

Als meerdere IPsec-verbindingen dezelfde lokale en remote subnetten gebruiken, mogen ze niet zonder ontwerp naast elkaar bestaan. Zulke verbindingen horen in een bewust failover-ontwerp of hebben duidelijk verschillende selector- of routinglogica nodig. Anders kan de firewall de juiste tunnel niet betrouwbaar selecteren.

NAT

NAT is bij IPsec niet per definitie fout, maar moet bewust zijn geconfigureerd. Onbedoelde MASQ of een te brede SNAT-regel kan ertoe leiden dat de peer het verkeer niet meer aan het verwachte netwerk koppelt.

Controleer:

• Matcht een algemene MASQ-regel vóór een specifieke VPN-NAT-regel?
• Verwacht de peer originele of vertaalde IP-adressen?
• Is NAT aan beide kanten gedocumenteerd?
• Past de NAT-regel bij de richting van het verkeer?

Bij gebruik van NAT helpt het artikel NAT op Sophos Firewall begrijpen: SNAT, DNAT, MASQ en PAT.

SFOS 22: Policy-based IPsec en NAT bewust controleren

Bij upgrades naar SFOS 22 moet policy-based IPsec bijzonder zorgvuldig worden gecontroleerd. Sophos wijst in de SFOS-22-release notes op gewijzigd gedrag bij policy-based IPsec VPN. Daarnaast is in de opgeloste problemen NC-170917 gedocumenteerd: policy-based IPsec-verkeer kon mislukken als de standaard SNAT-regel met een statisch IP-adres in plaats van MASQ was geconfigureerd.

Voor de praktijk betekent dit: als een policy-based tunnel na de upgrade groen is maar geen of slechts eenzijdig verkeer doorlaat, mag NAT niet als bijzaak worden behandeld. Een oude, brede of ongebruikelijk aangepaste standaard SNAT-regel kan precies het verkeer wijzigen waarvoor de peer de oorspronkelijke netwerken verwacht.

Typische controles na een upgrade naar SFOS 22:

• Is de tunnel werkelijk policy-based? Bij policy-based IPsec maken lokale en remote netwerken deel uit van de onderhandeling. NAT kan die verwachting doorbreken.
• Is de standaard SNAT-regel aangepast? Een statisch SNAT-IP in plaats van MASQ kan na een upgrade anders uitwerken dan verwacht.
• Zijn er specifieke VPN-NAT-regels? Deze moeten boven algemene SNAT- of MASQ-regels staan en bij de verkeersrichting passen.
• Komen Traffic Selectors en NAT-objecten overeen? De peer moet ofwel de oorspronkelijke netwerken ofwel de vertaalde netwerken verwachten, niet beide willekeurig.
• Toont Packet Capture het verwachte bron-IP? Zo is zichtbaar of de firewall vóór de tunnel een ander bronadres gebruikt.

Een zuivere testcase bestaat uit één bron, één bestemming en één service. Controleer vervolgens achtereenvolgens firewallregel, NAT-regel, ipsec statusall, ip route show table 220, Packet Capture en de peer. Werkt de test alleen met een uitgeschakelde of verplaatste NAT-regel, dan ligt het probleem niet bij de tunnelopbouw maar bij het pad naar de tunnel.

Voor de upgradeplanning is Sophos Firewall vóór een upgrade naar SFOS 22 controleren relevant. Voor NAT-basisprincipes en regelvolgorde is NAT op Sophos Firewall begrijpen het betere beginpunt.

Rekey, failover en interfacestatus

Als een tunnel eerst werkt en later uitvalt, hoeft de beginconfiguratie niet fout te zijn. Controleer dan het verloop in de tijd:

• Traffic-based rekeying bij andere leveranciers: Sophos Firewall verwacht tijdgebaseerde rekeylogica. Als de peer traffic-based rekeying afdwingt, kan de tunnel na verloop van tijd vastlopen of opnieuw onderhandelen.
• Key exchange collisions: als beide kanten tegelijk rekeyen, kunnen instabiele fases ontstaan. Stem in dat geval Phase-1- en Phase-2-lifetimes bewust af tussen Initiator en Responder.
• Interface uitgeschakeld: als de bijbehorende interface wordt uitgeschakeld, verbreekt een initiërende Site-to-Site-tunnel direct. Bij Responder- en Remote Access-verbindingen wordt de uitval uiterlijk bij inactiviteit of een DPD-time-out zichtbaar.
• DGD en failovergroep: controleer bij failover ook dgd.log, gatewaystatus, primaire en secundaire verbinding en identieke subnetparen.

Zulke fouten zijn beter herkenbaar aan tijdstempels dan aan één momentopname. Breng bij intermitterende problemen daarom tunnelstatus, strongswan.log, dgd.log, WAN-events en de applicatietest op dezelfde tijdlijn samen.

SFOS 22: PPPoE-WAN met aliasinterface en IPsec Acceleration

Sophos vermeldt NC-181526 in de Known Issues List: op bepaalde fysieke XGS-appliances met SFOS 22.0 GA Build 411 of MR1 Build 490 kan een IPsec-tunnel via de aliasinterface van een PPPoE-WAN-poort zijn opgebouwd, maar bij actieve IPsec acceleration geen gebruikersverkeer doorsturen. XGS 88/88w, 108/108w, 118/118w en 128/128w zijn uitgezonderd.

Controleer dit punt pas als de normale oorzaken niet passen. Een groene tunnel zonder verkeer is meestal nog steeds een probleem met regels, routing, NAT of het retourpad. Het SFOS-22-geval wordt waarschijnlijker als al het volgende samenkomt:

• Sophos Firewall draait op SFOS 22.0 GA Build 411 of MR1 Build 490.
• Het is een betrokken fysieke XGS-appliance en geen van de uitgezonderde modellen.
• De betrokken tunnel gebruikt een aliasinterface op een PPPoE-WAN-poort.
• De tunnel wordt opgebouwd, maar gebruikersverkeer blijft uit.
• Firewallregels, NAT, routes, retourpad en Packet Capture verklaren het gedrag niet.
• IPsec acceleration is actief.

⚠️ De workaround wijzigt een globale instelling en kan andere IPsec-tunnels beïnvloeden. Documenteer de actuele status, voer de wijziging in een onderhoudsvenster uit en test alleen bij een exact passend foutbeeld.

De Sophos Known Issues List noemt hiervoor de parameter off. De actuele CLI-referentie voor SFOS 22 documenteert disable; daarom gebruikt deze handleiding de huidige syntaxis en controleert men de status vóór en na de wijziging:

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

Als de test geen verbetering oplevert of de wijziging moet worden teruggedraaid:

system ipsec-acceleration enable

Volgens de Known Issues List verhelpt SFOS 22.0.2 MR2 Build 546 NC-181526. MR2 is uitgebracht; een geplande update is daarom de permanente oplossing. De gepubliceerde MR2-fixlijst noemt de issue-ID niet afzonderlijk, zodat de toewijzing van de fix hier uitdrukkelijk op de Known Issues List is gebaseerd.

Praktische controleprocedure:

1. Documenteer tunnelstatus en ipsec statusall.
2. Voer Packet Capture uit met een nauw bron- en bestemmingsfilter.
3. Controleer of de tunnel werkelijk een aliasinterface op een PPPoE-WAN-poort gebruikt.
4. Bevestig SFOS 22.0 GA Build 411 of MR1 Build 490 en een betrokken hardwaremodel.
5. Documenteer de status met system ipsec-acceleration show en test de wijziging alleen gericht.
6. Vergelijk daarna status, bytetellers, Packet Capture, Log Viewer en de applicatietest.
7. Herstel zonder verbetering de oorspronkelijke toestand met system ipsec-acceleration enable.

Log Viewer en Packet Capture combineren

Log Viewer toont welke regel of module een verbinding heeft beoordeeld. Packet Capture in WebAdmin toont daarentegen of pakketten werkelijk aankomen, worden doorgestuurd, worden gedropt of door de firewall zelf worden verwerkt.

Definieer voor IPsec-troubleshooting een zo nauw mogelijke test:

• Bron-IP: 172.16.10.25
• Bestemmings-IP: 10.20.30.15
• Service: ICMP of TCP 443
• Verwachte richting: LAN naar VPN
• Verwachte regel: LAN_to_VPN_Branch

Daarna:

1. Activeer logging in de firewallregel.
2. Filter Log Viewer op bron-IP, bestemmings-IP en module Firewall.
3. Start Packet Capture met een nauw filter, bijvoorbeeld host 172.16.10.25 and host 10.20.30.15.
4. Reproduceer de test precies één keer.
5. Controleer of pakketten aankomen, worden doorgestuurd en of antwoorden terugkomen.

Interpretatie:

• Geen pakket komt aan op Sophos Firewall: controleer client, gateway, VLAN, switch of lokale routing.
• Pakket komt aan maar wordt niet doorgestuurd: controleer firewallregel, NAT, route of Security Feature.
• Pakket wordt naar de tunnel gestuurd maar antwoord ontbreekt: controleer retourroute, peer, remote firewall of remote host.
• Alleen uitgaande bytes in ipsec statusall: controleer het retourpad of de remote policy.
• Alleen inkomende bytes: controleer lokale route, lokale firewallregel of doelsysteem.

Voor langere opnames of supportcases kan het zinvol zijn logs gericht te verzamelen. Het artikel Sophos Firewall-logs voor support en analyse opslaan beschrijft een correcte export.

Typische foutbeelden

De volgende foutbeelden verwijzen naar de ruwe StrongSwan/Charon-strings uit strongswan.log. In WebAdmin verschijnen dezelfde oorzaken vaak als vertaalde melding, bijvoorbeeld no IKE config found als “Remote peer is refusing our Phase 1 proposals”, peer authentication failed als “Remote peer reports we failed to authenticate” of traffic selectors ... inacceptable als “Remote peer reports INVALID_ID_INFORMATION”. Wie eerst WebAdmin in plaats van het ruwe log bekijkt, vindt via deze koppeling het juiste geval.

• no IKE config found: IKE-versie, gateway, ID’s of profiel passen niet. Vergelijk IKE-versie, Local/Remote ID en proposals.
• NO_PROPOSAL_CHOSEN: proposal mismatch. Controleer encryption, authentication, DH Group, PFS en lifetime.
• peer authentication failed: ID of authenticatie past niet. Controleer Local/Remote ID en PSK of certificaat.
• AUTH_FAILED: Preshared Key, certificaat of ID past niet. Stel PSK opnieuw in en controleer certificaatketen en ID’s.
• traffic selectors ... inacceptable: lokale en remote netwerken passen niet. Vergelijk subnetten en hostobjecten gespiegeld.
• failed to establish CHILD_SA: Phase-2-netwerken of ESP-proposals passen niet. Controleer Traffic Selectors, PFS, ESP-profiel en lifetimes.
• Tunnel groen, geen bytes: verkeer bereikt de tunnel niet. Controleer firewallregel, route, NAT en clientgateway.
• Uitgaande bytes, geen inkomende: peer of retourpad ontbreekt. Controleer remote regels, remote route en doelsysteem.
• ipsec statusall toont SAs, maar route-based verkeer stopt later: controleer XFRM-state, XFRM-policy, overlappende XFRM-netwerken, failovergroep en rekeygedrag.
• Meerdere tunnels met dezelfde subnetten: tunnels horen in een failovergroep of moeten duidelijk verschillende selector- of routinglogica hebben.
• Grote overdrachten lopen vast ondanks een actieve tunnel: richt de analyse op MTU/MSS, pakketverlies of Path MTU Discovery. MTU en MSS bij VPN-problemen controleren.
• SFOS 22, policy-based IPsec, tunnel groen, verkeer ontbreekt: NAT, standaard SNAT of Traffic Selectors passen na de upgrade niet correct. Controleer standaard SNAT, VPN-NAT-regels, MASQ, Packet Capture en de peer.
• SFOS 22.0 GA Build 411 of MR1 Build 490, PPPoE-WAN-alias, tunnel groen, geen verkeer: mogelijk Known Issue NC-181526 op betrokken fysieke XGS-appliances. Bevestig model en interfacetype; controleer pas daarna de status en test gericht system ipsec-acceleration disable.
• Herverbindingen of frequente rekeys: richt de analyse op lifetime, DPD, een instabiele verbinding of proposal. Controleer rekeytijden, DPD, WAN-stabiliteit en logs.

Praktische checklist

Direct controleren:

• Tunnelstatus en laatste foutmelding in WebAdmin noteren.
• tail -f /log/strongswan.log starten en de tunnel opnieuw verbinden.
• IKE-versie, Local ID, Remote ID en Preshared Key controleren.
• Traffic Selectors en lokale en remote netwerken gespiegeld vergelijken.
• In ipsec statusall controleren op ESTABLISHED, INSTALLED en bytetellers.

Als de tunnel staat:

• Firewallregels in beide richtingen controleren.
• Logging in de betrokken regels activeren.
• Log Viewer filteren op bron, bestemming en Rule ID.
• Packet Capture met een nauw filter uitvoeren.
• NAT-regels en Route Precedence controleren.
• Bij route-based VPN ip xfrm state, ip xfrm policy en XFRM-interfacenetwerken controleren.
• Bij meerdere vergelijkbare tunnels de failovergroep en kolommen Local/Remote subnet tonen.
• Bij SFOS 22 met policy-based IPsec standaard SNAT, specifieke VPN-NAT-regels en het verwachte bron-IP controleren.
• Bij SFOS 22.0 GA Build 411 of MR1 Build 490 met PPPoE-WAN-alias controleren of hardwaremodel en foutbeeld exact bij NC-181526 passen.
• Het retourpad bij de peer bevestigen.

Voor support of langere analyse:

• Debug slechts kort activeren en daarna weer uitschakelen.
• Relevante logs veiligstellen.
• Tijdstip, tunnelnaam, peer-IP, bron, bestemming en testprocedure documenteren.
• Gevoelige gegevens vóór het delen controleren.

Veelgestelde vragen