Sophos Firewall IPsec VPN troubleshooting

IPsec site-to-site VPNs vallen meestal niet op zolang ze werken. Maar wanneer een tunnel niet opkomt, na een reconnect instabiel blijft of als verbonden wordt weergegeven zonder traffic te transporteren, is een duidelijke volgorde voor troubleshooting nodig. Anders springt men snel tussen PSK, routes, firewall rules en logs heen en weer zonder de echte oorzaak te zien.

Deze handleiding laat zien hoe IPsec-verbindingen op Sophos Firewall systematisch worden gecontroleerd: eerst de tunnelopbouw, daarna de onderhandelde netwerken en ten slotte de daadwerkelijke packet flow. Voor algemene CLI-basiskennis helpt Sophos Firewall Troubleshooting: tips en trucs voor de CLI.

Voor de troubleshooting

Eerst moet de uitgangssituatie kort worden gedocumenteerd. Dat klinkt eenvoudig, maar bespaart veel tijd, omdat veel IPsec-problemen door asymmetrische aannames ontstaan: de ene kant denkt netwerk A met netwerk B te verbinden, terwijl de andere kant andere IDs, andere subnets of een andere IKE-versie verwacht.

Belangrijke punten:

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

⚠️ Debug-logs en Packet Captures kunnen gevoelige gegevens bevatten, zoals publieke IP-adressen, interne netwerken, hostnames of payload data. Zulke gegevens moeten alleen gericht en tijdelijk worden verzameld en voor het delen worden gecontroleerd.

Diagnosepad

In de praktijk helpt een eenvoudige volgorde:

1. Komt de tunnel op? Zo niet, controleer eerst IKE-versie, IPsec-profiel, IDs, PSK/certificaat, NAT-T en bereikbaarheid van de peer.
2. Wordt fase 2 opgebouwd? Zo niet, controleer traffic selectors, lokale en remote netwerken, PFS en fase-2-proposals.
3. Is een Security Association geïnstalleerd? Zo ja, controleer ipsec statusall en let op de byte counters.
4. Loopt traffic door de tunnel? Zo niet, controleer firewall rules, NAT, routing, Route Precedence, IPsec routes en retourpad.
5. Zijn packets zichtbaar? Als dat onduidelijk is, combineer Log Viewer en Packet Capture.

Een veelgemaakte denkfout: een groene tunnelstatus bewijst alleen dat IPsec is onderhandeld. Het bewijst niet dat de firewall rules kloppen, dat de routes correct zijn of dat de peer het retourpad kent.

Logs verzamelen

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

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

cd /log

Het live-log volgen:

tail -f /log/strongswan.log

Als meerdere tunnels actief zijn, moet worden gefilterd. Dat kan op tunnelnaam, peer-IP of een typische fouttekst:

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

Voor bestaande logbestanden is less vaak prettiger:

less /log/strongswan.log

In less kan met /zoekterm binnen het bestand worden gezocht. Alternatief filtert grep direct:

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

StrongSwan-debug inschakelen

Als het normale log niet voldoende is, kan de StrongSwan-service in debugmodus worden gezet:

service strongswan:debug -ds nosync

Daarna controleren of de service in debugmodus draait:

service -S | grep strongswan

De output zou bij strongswan de status RUNNING,DEBUG moeten tonen. Daarna de tunnel opnieuw verbinden of het probleem gericht reproduceren en het log bekijken:

tail -f /log/strongswan.log

Hetzelfde debugcommando schakelt de debugmodus weer uit:

service strongswan:debug -ds nosync

⚠️ Debug alleen laten draaien zolang het echt nodig is. IPsec-debug kan zeer snel grote logbestanden genereren en onnodig opslagruimte op de firewall gebruiken.

Fase 1: IKE, IDs en authenticatie

Als de tunnel helemaal niet opkomt, ligt de oorzaak meestal vóór of tijdens fase 1. Dan onderhandelen de gateways nog geen datanetwerken, maar IKE, authenticatie en de identiteiten van beide kanten.

Typische oorzaken:

• IKE-versie komt niet overeen
• IPsec-profiel of proposal komt niet overeen
• Local ID of Remote ID is anders dan verwacht
• Preshared key is fout
• peer bereikt het verkeerde publieke IP
• NAT-T of port forwarding op UDP 500 en 4500 is niet schoon
• certificaten, CA of geldigheid passen 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 packet. Dat kan liggen aan IKE-versie, gateway, IDs of IPsec-profiel.

Controleren:

• Komt IKEv1 of IKEv2 aan beide kanten overeen?
• Past de peer bij het geconfigureerde Remote Gateway-adres of FQDN?
• Kloppen lokale en remote ID?
• Zijn Encryption, Authentication, DH Group en Lifetime compatibel?
• Gebruikt de peer mogelijk een ander publiek IP dan gedocumenteerd?

Peer authentication failed

peer authentication failed, AUTH_FAILED of no matching peer config found wijst vaak op niet-passende IDs of authenticatiegegevens. Bij Preshared Key wordt vaak eerst de sleutel verdacht. Dat is vaak juist, maar niet altijd. Als de ID niet klopt, controleert de firewall mogelijk niet eens tegen de verwachte peer-configuratie.

Controleren:

• Local ID van de ene kant komt overeen met Remote ID van de andere kant.
• Remote ID van de ene kant komt overeen met Local ID van de andere kant.
• Spelling, hoofdletters/kleine letters, FQDN en IP-adressen zijn exact gelijk.
• Preshared key is zonder spaties aan 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 foutieve Preshared Key. Bij IKEv2 ziet men eerder AUTHENTICATION_FAILED of AUTH_FAILED.

In de praktijk is het beter de Preshared Key aan beide kanten opnieuw te zetten dan hem alleen visueel te vergelijken. Copy-paste uit password managers, onzichtbare spaties of verschillende speciale tekens zijn klassieke tijdvreters.

Fase 2: Traffic selectors en Security Associations

Als fase 1 succesvol is, maar fase 2 niet tot stand komt, gaat het meestal om de netwerken en de Child SA. Sophos Firewall moet met de peer onderhandelen welke lokale en remote subnets door de tunnel mogen.

Typische logaanwijzingen:

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

Controleren:

• Lokale en remote netwerken zijn aan beide kanten spiegelbeeldig geconfigureerd.
• Netmask en afzonderlijke hostobjecten komen exact overeen.
• Er zijn geen ongewenste overlaps met andere tunnels.
• Meerdere fase-2-netwerken zijn aan beide kanten gelijk afgebeeld.
• PFS, ESP Encryption, Authentication en Lifetime komen overeen.

Voorbeeld: als Sophos Firewall lokaal 172.16.10.0/24 en remote 10.20.30.0/24 verwacht, moet de peer exact het spiegelbeeld 10.20.30.0/24 naar 172.16.10.0/24 aanbieden. Een /24 aan de ene kant en een enkele host of groter netwerk aan de andere kant kan al genoeg zijn om installatie van de Child SA te voorkomen.

Tunnel staat, maar er loopt geen traffic

Als de tunnel als verbonden wordt weergegeven maar er geen traffic doorheen gaat, is IPsec zelf niet automatisch de oorzaak. Dan gaat het meestal om routing, firewall rules, NAT of het retourpad.

Controleer eerst de IPsec-status in de Advanced Shell:

ipsec statusall

Vooral interessant:

• Is de IKE SA ESTABLISHED?
• Is de Child SA INSTALLED?
• Welke lokale en remote netwerken worden getoond?
• Stijgen de byte counters in beide richtingen?
• Zijn er alleen uitgaande bytes, maar geen inkomende?
• Wordt de tunnel regelmatig opnieuw verbonden of gerekeyed?

Als de Child SA geïnstalleerd is, maar de byte counters leeg blijven, bereikt de verwachte traffic waarschijnlijk de tunnel niet. Dan controleert men het pad vóór en na IPsec.

Firewall rules

Voor traffic door de tunnel zijn passende firewall rules nodig. Afhankelijk van het zonemodel is dat bijvoorbeeld LAN naar VPN, VPN naar LAN of een eigen zone. De regel moet source, destination, service en richting correct afdekken.

Belangrijk:

• In de relevante regels Log firewall traffic activeren.
• Regelpositie controleren, zodat geen algemenere regel eerder matcht.
• Source- en destination-zones correct kiezen.
• Bij meerdere VPNs geen te brede objecten gebruiken als ze de verkeerde tunnel kunnen matchen.
• Security Features zoals IPS, Web Filter of Application Control bewust controleren als ze op de traffic actief zijn.

Een algemene testflow staat in Firewall Rules testen met Log Viewer, Policy Test en Packet Capture.

Routing en IPsec routes

Als de firewall de traffic niet de tunnel in stuurt, controleer de routes. Bij policy-based IPsec kan ook de IPsec-routingtabel relevant zijn:

ip route show table 220

Als een handmatige toewijzing nodig is, kan een IPsec route op Sophos Firewall helpen. Als meerdere routingtypen concurreren, controleer ook de Route Precedence van Sophos Firewall.

Controleren:

• Is er een specifiekere statische route die de traffic opvangt?
• Gaat een SD-WAN Policy Route vóór de VPN-route?
• Wijst de client-gateway echt naar Sophos Firewall?
• Heeft de peer een retourroute naar het lokale netwerk?
• Zijn er overlappende lokale en remote netwerken?

NAT

NAT is bij IPsec niet principieel fout, maar moet bewust geconfigureerd zijn. Onbedoelde MASQ of een te brede SNAT-regel kan ervoor zorgen dat de peer de traffic niet meer aan het verwachte netwerk koppelt.

Controleren:

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

Als NAT betrokken is, helpt NAT op Sophos Firewall begrijpen: SNAT, DNAT, MASQ, PAT.

Log Viewer en Packet Capture combineren

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

Voor IPsec-troubleshooting moet een zo smal mogelijke test worden gedefinieerd:

Daarna:

1. Logging in de firewall rule activeren.
2. Log Viewer filteren op Source IP, Destination IP en module Firewall.
3. Packet Capture starten met een smal filter, bijvoorbeeld host 172.16.10.25 and host 10.20.30.15.
4. Test precies één keer reproduceren.
5. Controleren of packets aankomen, doorgestuurd worden en of antwoorden terugkomen.

Interpretatie:

Voor langere captures of supportcases kan het zinvol zijn logs gericht te verzamelen. Sophos Firewall logs voor support en analyse opslaan beschrijft de schone export.

Typische foutbeelden

Praktische checklist

Direct controleren:

• Tunnelstatus en laatste foutmelding in WebAdmin noteren.
• tail -f /log/strongswan.log starten en tunnel opnieuw verbinden.
• IKE-versie, Local ID, Remote ID en Preshared Key controleren.
• Traffic selectors of lokale en remote netwerken spiegelbeeldig vergelijken.
• ipsec statusall op ESTABLISHED, INSTALLED en byte counters controleren.

Als de tunnel staat:

• Firewall rules in beide richtingen controleren.
• Logging op de betrokken regels activeren.
• Log Viewer filteren op source, destination en Rule ID.
• Packet Capture met smal filter uitvoeren.
• NAT-regels en Route Precedence controleren.
• Retourroute op de peer bevestigen.

Voor support of langere analyse:

• Debug slechts kort activeren en daarna weer uitschakelen.
• Relevante logs opslaan.
• Tijd, tunnelnaam, peer-IP, source, destination en testverloop documenteren.
• Gevoelige gegevens controleren voordat ze gedeeld worden.

FAQ

Waarom is de IPsec tunnel groen, maar loopt er geen traffic?

Een groene tunnelstatus betekent alleen dat IPsec is onderhandeld. Firewall rules, NAT, routing, Route Precedence, IPsec routes en het retourpad van de peer kunnen nog steeds fout zijn.

Welk log is het belangrijkst voor IPsec op Sophos Firewall?

In de praktijk is strongswan.log het belangrijkste bestand. Afhankelijk van het foutbeeld kunnen ook charon.log, strongswan-monitor.log en dgd.log helpen.

Wanneer moet StrongSwan-debug worden ingeschakeld?

Debug is zinvol wanneer het normale log niet genoeg informatie geeft. Het moet alleen gericht en kort worden ingeschakeld, omdat er veel meer logdata ontstaat.

Wat betekent traffic selectors inacceptable?

De netwerken die beide kanten voor fase 2 willen onderhandelen, passen niet bij elkaar. Lokale en remote subnets, hostobjecten en meerdere fase-2-items moeten exact worden vergeleken.

Wat betekent AUTH_FAILED?

AUTH_FAILED wijst op een authenticatieprobleem. Vaak zijn Preshared Key, Local ID, Remote ID of certificaten niet identiek aan wat de peer verwacht.

Bronnen

• Sophos Community: Troubleshooting site-to-site IPsec VPN issues
• Sophos Support: KBA-000006520
• Sophos Docs: Packet capture