Sophos Firewall: systematische diagnose van IPsec VPN

Bij IPsec-troubleshooting is de volgorde doorslaggevend: controleer eerst IKE en de Child SA, daarna firewallregels, NAT, routing en het retourpad. Een groene tunnel bevestigt alleen de onderhandeling, niet dat gebruikersverkeer werkt.

Voor een nieuwe tunnel is Een Site-to-Site IPsec VPN op Sophos Firewall instellen het juiste beginpunt. De volgende stappen gelden voor een reeds geconfigureerde verbinding.

Wijzig globale geavanceerde instellingen zoals sessieopschoning bij failover, het anti-replayvenster, de IKEv2-cookiedrempel of het gebruik van al opgeloste peeradressen niet als eerste diagnosepoging. Globale VPN-instellingen veilig gebruiken beschrijft effect, begincontrole en rollback.

Diagnosepad

1. Tunnel blijft down: controleer IKE-versie, IPsec-profiel, gateway, Local/Remote ID, PSK of certificaat in strongswan.log.
2. Phase 1 staat, maar er is geen Child SA: vergelijk Traffic Selectors, Phase-2-proposal, PFS en subnetten.
3. Tunnel is groen: controleer met ipsec statusall of de SA ESTABLISHED is, de Child SA INSTALLED is en de bytetellers toenemen.
4. Slechts één richting telt bytes: controleer firewallregels, NAT, routing en vooral het retourpad bij de peer.
5. De oorzaak blijft onduidelijk: volg één teststroom met Log Viewer en Packet Capture.

Documenteer vooraf slechts enkele waarden: tunnelnaam, peer-IP of FQDN, IKE-versie, Local/Remote ID, lokale en remote netwerken, policy-based of route-based, IPsec-profiel en een test met Source, Destination en Service. Voorbeeld: tunnel azure-vpn, lokaal 172.16.10.0/24, remote 10.20.30.0/24.

Bij policy-based IPsec maken de netwerken deel uit van de onderhandeling. Route-based IPsec gebruikt een XFRM-interface en statische, SD-WAN- of dynamische routes. Bij een onjuist pad helpen de afzonderlijke handleidingen voor IPsec Routes en Route Precedence.

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

Vóór de CLI-diagnose toont Current activities > IPsec connections alleen de IPsec-verbindingen die op dat moment zijn opgebouwd. De lijst kan worden gefilterd op Connection name, Local server name, Local subnet, Username, Remote server/host of Remote subnet en met Refresh opnieuw worden geladen. Disconnect verbreekt de geselecteerde verbinding actief en is geen onschuldige verversing: documenteer eerst tijdstip en status en verbreek de verbinding alleen in een gepland testvenster. Deze momentopname vervangt geen controle van Child SA, logs of verkeer.

Logs en CLI controleren

Onder Site-to-site VPN > IPsec toont Show additional properties onder andere Local subnet, Remote subnet, Gateway type en Profile. Onder Profiles > IPsec profiles kunnen Phase-1- en Phase-2-waarden eveneens rechtstreeks worden vergeleken.

De belangrijkste bestanden in /log zijn:

• strongswan.log: IKE, authenticatie en Child SA’s
• charon.log: IKE-daemon
• ipsec_monitor.log: monitoring van de IPsec-service
• /log/ipsec_conn/ipsec_<connectionname>.log: Connect-, Activate- en Deactivate-acties in WebAdmin
• xfrmi.log: XFRM-interfaces
• dgd.log: Dead Gateway Detection en VPN-failover

De actuele centrale SFOS-22-loglijst noemt ipsec_monitor.log. Een oudere Sophos-pagina voor troubleshooting noemt nog strongswan-monitor.log; voor actuele SFOS-22-systemen is de nieuwere loglijst leidend.

In de Advanced Shell kan het hoofdlog live worden gevolgd of gefilterd. Als men nog niet vertrouwd is met SSH- en shelltoegang, helpt Sophos Firewall CLI-troubleshooting: belangrijke opdrachten.

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

De regels zijn alternatieven en geen aaneengesloten procedure. In less zoekt /zoekterm binnen het bestand.

StrongSwan-debug

Als het normale log onvoldoende is, noteer dan eerst de actuele status in de Advanced Shell:

service -S | grep strongswan

Als de uitvoer al een actieve debugstatus aangeeft, voer de schakelopdracht dan niet opnieuw uit. Bepaal eerst wie debug heeft ingeschakeld en waarom; de volgende procedure geldt alleen als debug aanvankelijk inactief was. De exacte statustekst kan per build verschillen.

⚠️ Laat debug slechts kort actief. De modus kan snel grote logbestanden produceren en opslagruimte innemen.

Als debug niet actief is, voer de opdracht één keer uit en controleer de nieuwe status:

service strongswan:debug -ds nosync
service -S | grep strongswan

Volg daarna strongswan.log in een tweede terminal, reproduceer het probleem precies één keer en stop tail met Ctrl+C:

tail -f /log/strongswan.log

Voer ten slotte dezelfde schakelopdracht één keer uit. De tweede regel moet bevestigen dat de eerder genoteerde normale status zonder debug is hersteld:

service strongswan:debug -ds nosync
service -S | grep strongswan

Tunnelopbouw controleren

Phase 1: IKE, ID’s en authenticatie

Als de tunnel niet tot stand komt, komen meestal IKE-versie, gateway, ID’s, proposal, PSK of certificaat niet overeen.

• no IKE config found of Remote peer is refusing our Phase 1 proposals: de firewall vindt geen passende verbinding of het profiel komt niet overeen. Controleer IKE-versie, Listening Interface, peer-adres, Local/Remote ID en profiel.
• peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found of Remote peer reports we failed to authenticate: ID’s en authenticatie komen niet overeen met de verwachte peerconfiguratie.
• invalid HASH_V1 payload length of decryption failed: bij IKEv1 vaak een onjuiste PSK; bij IKEv2 verschijnt eerder AUTH_FAILED.
• De peer bereikt een ander openbaar adres of UDP 500/4500 wordt door NAT, router of provider niet correct doorgestuurd.
• Bij certificaten komen de certificaatketen, uitgevende CA, geldigheid of verwachte ID niet overeen.

Als een certificaat vóór de vervaldatum is ingetrokken of de werking van de intrekking onduidelijk blijft, worden issuer, serienummer, thisUpdate, nextUpdate en de servicespecifieke weigering gezamenlijk gecontroleerd. De veilige procedure staat in Certificate Revocation Lists op Sophos Firewall importeren en testen.

De Local ID aan de ene zijde moet overeenkomen met de Remote ID aan de andere zijde en omgekeerd. Vergelijk eerst de ID’s en opgeslagen PSK aan beide kanten. Als de PSK moet worden gewijzigd, coördineer dit dan op beide peers in een onderhoudsvenster; onzichtbare spaties en kopiëren uit wachtwoordbeheerders zijn veelvoorkomende oorzaken. Een verkeerde ID kan peermatching verhinderen voordat de verwachte PSK wordt gecontroleerd.

Vergelijk bij Remote peer is refusing our Phase 1 proposals de Phase-1-waarden en Gateway address en Listening interface aan beide kanten. Als de waarden overeenkomen, moet de peerbeheerder de configuratie en de logs van hetzelfde tijdstip controleren aan de kant die de verbinding weigert. Laat bij Remote peer reports we failed to authenticate ook bevestigen of het verwachte ID-type afwijkt, bijvoorbeeld een IP-adres in plaats van een DNS-naam. Local ID en Remote ID moeten kruislings overeenkomen in type en waarde; corrigeer alleen de bevestigde afwijking en controleer opnieuw of de tunnel tot stand komt. Leg vóór een wijziging de eerdere waarden vast en stem de aanpassing met de peerbeheerder af in een onderhoudsvenster; herstel de gedocumenteerde toestand als er geen verbetering is. Deel geen PSK’s in logs of supportpakketten.

De meldingen Error on decryption of the exchange of Information field of the IKE request is malformed or not readable wijzen in eerste instantie op verschillende preshared keys. Onderzoek de zeldzamere oorzaak die Sophos noemt pas als bevestigd is dat de PSK aan beide kanten identiek is en de fout blijft optreden: pakketten die bij de ISP of op een upstreamrouter of -firewall beschadigd raken. Controleer het betreffende pad samen met de provider of verantwoordelijke beheerder aan de hand van gelijktijdige, nauw gefilterde captures en vergelijk de WAN-MTU-/MSS-waarden met de providerspecificaties. Eén capture bewijst geen pakketbeschadiging. De bestaande handleiding voor MTU en MSS beschrijft de uitgangscontrole, een veilige test en rollback; verlaag waarden niet op vermoeden globaal. TCP MSS is geen oplossing voor fouten in de IKE-onderhandeling. Controleer captures op gevoelige gegevens voordat ze worden gedeeld.

Phase 2: Traffic Selectors en Child SA

Als Phase 1 staat maar er geen Child SA is, verschillen meestal de subnetten of Phase-2-waarden.

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• Remote peer reports INVALID_ID_INFORMATION
• afwijkende waarden bij TSi en TSr
• NO_PROPOSAL_CHOSEN na Phase 1 is up en Initiating establishment of Phase 2 SA

NO_PROPOSAL_CHOSEN alleen is niet voldoende voor de indeling: vóór Phase 1 wijst de melding op IKE-/Phase-1-waarden; na een geslaagde Phase 1 op ESP, PFS of andere Phase-2-waarden.

Voor een volledige vergelijking van de velden onder General settings, Phase 1, Phase 2 en DPD helpt IPsec-profielen op Sophos Firewall begrijpen en veilig configureren.

De netwerken moeten gespiegeld zijn. Verwacht Sophos lokaal 172.16.10.0/24 en remote 10.20.30.0/24, dan moet de peer 10.20.30.0/24 naar 172.16.10.0/24 aanbieden. Ook een /24 tegenover één host of verschillend beheerde hostobjecten kan de Child SA verhinderen.

Blijft NO_PROPOSAL_CHOSEN of Remote peer reports INVALID_ID_INFORMATION na een geslaagde Phase 1 optreden, hoewel Phase-2-Encryption, Authentication, de PFS-/DH-groep en de gespiegelde subnetten zijn vergeleken, laat de peerbeheerder dan de onderhandelingslogs van hetzelfde tijdstip aan de andere kant controleren. Geef de tunnelnaam, het tijdstip, de aangeboden selectorwaarden en de INSTALLED-status van de betreffende Child SA of selector uit ipsec statusall door; leg expliciet vast of die SA ontbreekt, in plaats van uit de fout af te leiden dat alle SA’s ontbreken. ip xfrm policy vult de controle van policies aan, maar bewijst niet dat SA’s zijn geïnstalleerd. Documenteer vóór een wijziging de eerdere waarden en de rollbackprocedure en spreek een onderhoudsvenster af. Pas daarna alleen de aangetoonde afwijking gecoördineerd aan en controleer de tunnelopbouw en dezelfde testflow opnieuw; herstel de eerdere toestand als er geen verbetering is.

Tunnel staat, maar er loopt geen verkeer

In de Advanced Shell toont deze opdracht SA’s, onderhandelde netwerken en bytetellers:

ipsec statusall

Let op ESTABLISHED, INSTALLED en de tellers in beide richtingen. Blijven beide op nul of lopen ze niet op, dan bereikt het testverkeer de tunnel waarschijnlijk niet. Neemt alleen de uitgaande kant toe, dan ontbreekt meestal het retourpad of een regel bij de peer; nemen alleen inkomende bytes toe, dan zijn de lokale route, lokale regel of het doelsysteem verdacht.

Eén teststroom volgen

Een gerichte test levert meer informatie dan meerdere parallelle pings:

• Source IP: 172.16.10.25
• Destination IP: 10.20.30.15
• Service: ICMP of TCP 443
• verwachte richting: LAN naar VPN
• verwachte regel: LAN_to_VPN_Branch

Controleer vervolgens in deze volgorde:

1. Activeer Log firewall traffic in de betrokken regel.
2. Filter Log Viewer op Source, Destination en Rule ID.
3. Start Packet Capture met host 172.16.10.25 and host 10.20.30.15.
4. Voer de test precies één keer uit.
5. Vergelijk regel, NAT Rule ID, forwarding, antwoord en bytetellers.
6. Controleer bij de peer de retourroute, remote regel en het doelsysteem.

Packet Capture gebruikt een beperkte buffer en stopt zodra deze vol is. De weergave toont onder meer Rule ID, NAT ID, Status en Reason. Tijdens een standaardcapture wordt versneld FastPath-verkeer normaal tijdelijk via SlowPath geleid. Controleer bufferstatus, filter en testtijdstip voordat u een lege of gestopte capture als bewijs voor ontbrekend verkeer beschouwt.

Als geen pakket Sophos Firewall bereikt, ligt de oorzaak ervoor, bijvoorbeeld bij de clientgateway, VLAN of lokale routing. Komt het pakket aan maar wordt het niet doorgestuurd, dan passen regel, NAT, route of een Security Feature niet. De volledige regeltest staat in Een firewallregel controleren met Log Viewer, Policy Test en Packet Capture.

Routing en XFRM

Bij policy-based IPsec maakt SFOS de VPN-routes in de backend aan. Ze staan niet in de normale routingweergave. Lees handmatige IPsec Routes en Route Precedence in de Device Console:

system ipsec_route show
system route_precedence show

De standaardvolgorde is static, sdwan_policyroute, vpn. Een ontbrekende regel in de normale weergave bewijst daarom geen routingfout. Vergelijk voor de teststroom Diagnostics > Tools > Route lookup, het firewalllog en Packet Capture.

Bij route-based IPsec hangt het pad af van het type XFRM-interface:

• Any/Any of Dual: de XFRM-interface heeft IP-adressen. Een statische, SD-WAN- of dynamische route moet extern verkeer erheen sturen.
• Concrete Traffic Selectors: SFOS maakt de statische route automatisch aan. Aan de XFRM-interface kan geen IP-adres of extra route worden toegewezen.

Controleer de interface onder Network > Interfaces en het pad onder Diagnostics > Tools > Route lookup. De Device Console toont geconfigureerde statische routes:

show static-route

Controleer XFRM-statussen in de Advanced Shell:

ip xfrm state
ip xfrm policy

Vergelijk bij meerdere XFRM-interfaces met een IP-adres ook de transitnetwerken: elke interface heeft een eigen, niet-overlappend netwerk nodig. Verschillende afzonderlijke IP-adressen zijn niet voldoende. xfrm1 met 192.168.0.1/24 en xfrm2 met 192.168.0.6/24 behoren beide tot 192.168.0.0/24; ook 192.168.0.1/16 op xfrm1 overlapt met 192.168.0.6/24 op xfrm2, omdat het /16 het /24 omvat. Deze voorbeelden tonen een fout, geen aanbevolen adressen. Het gaat om de transitnetwerken van de interfaces, niet om de beschermde LAN-netwerken in de Traffic Selectors.

⚠️ Wijziging van de XFRM-adressering kan het tunnelpad en de beheertoegang onderbreken. Leg eerst IP-adressen, prefixen en afhankelijke routes aan beide kanten vast en zorg voor onafhankelijke beheertoegang en een onderhoudsvenster. Wijzig onder Network > Interfaces alleen de betrokken interfaces met een IP-adres naar beschikbare, niet-overlappende transitnetwerken en stem de wijzigingen in peeradressering en afhankelijke routes af. Controleer daarna Route lookup, dezelfde teststroom en de bytetellers in beide richtingen. Herstel zonder verbetering de vastgelegde adressen, prefixen en routes aan beide kanten. Bij concrete Traffic Selectors blijft gelden: geen XFRM-IP-adres of extra route toewijzen.

Als meerdere verbindingen dezelfde lokale en externe netwerken als alternatieve paden gebruiken, moeten selectie en failover expliciet zijn. Plaats policy-based verbindingen en route-based verbindingen met concrete Traffic Selectors in dezelfde IPsec-failovergroep. Any/Any XFRM-tunnels kunnen in plaats daarvan via SD-WAN-routes omschakelen; de gekoppelde procedure beschrijft volgorde, Health Check en gecontroleerde omschakeltest.

NAT per tunneltype controleren

NAT is toegestaan, maar vervangt geen route. Controleer eerst of het pad van de oorspronkelijke of vertaalde bestemming de juiste tunnel kiest en daarna of de peer de werkelijk gebruikte adressen verwacht.

Als lokale en externe netwerken identiek zijn, volstaat één SNAT-opmerking niet. NAT gebruiken voor overlappende IPsec-netwerken beschrijft de volledige gespiegelde procedure voor adressering, tunnel, regels en routing.

• Policy-based met SNAT: de bedoelde SNAT-regel vereist Outbound interface Any. De standaard SNAT-regel met concrete WAN-poorten matcht policy-based IPsec-verkeer niet.
• Route-based met Any/Any of Dual: de XFRM-interface heeft een IP-adres en vereist een expliciete route. Bepaal uit de matchende NAT-regel en Packet Capture of en hoe vertaling plaatsvindt; leid dit niet alleen uit het tunneltype af.
• Route-based met concrete Traffic Selectors: SFOS maakt de route automatisch aan en wijst geen IP-adres toe aan de XFRM-interface. MASQ naar een vermeend XFRM-IP is daarom geen betrouwbare diagnose; controleer de oorspronkelijke en vertaalde Source en de matchende NAT Rule ID.

Documenteer de oorspronkelijke en vertaalde Source, sta deze waar nodig toe op de peer en zorg voor de retourroute. NAT op Sophos Firewall beschrijft de basisprincipes en regelvolgorde.

Instabiliteit en bijzondere gevallen in SFOS 22

Als verkeer pas later stopt, vergelijk dan tijdstempels in tunnelstatus, strongswan.log, dgd.log, WAN-events en de applicatietest. Veelvoorkomende oorzaken zijn:

• De andere leverancier gebruikt traffic-based Rekeying; Sophos Firewall ondersteunt time-based Rekeying.
• Bij policy-based IPsec beëindigt een idle-time-out op de externe firewall de verbinding na inactiviteit. Vergelijk samen met de peerbeheerder de time-out van de betrokken VPN-verbinding met het tijdstip van verbreken. Noteer vóór wijziging de eerdere waarde en het toepassingsbereik; schakel bij een bevestigde oorzaak de idle-time-out van die verbinding bij de peer uit tijdens een afgesproken testvenster. De verbinding kan daardoor tijdens inactiviteit blijven bestaan. Wacht vervolgens de eerder problematische inactieve periode af en controleer dezelfde teststroom, tunnelstatus en bytetellers. Herstel zonder verbetering de eerdere peerinstelling. Dit is geen wijziging van globale SFOS-time-outs, Key Lifetimes of DPD.
• Beide kanten rekeyen tegelijk. Stem de Phase-1- en Phase-2-Key Lifetimes van Initiator en Responder bewust af.
• De toegewezen interface is uitgeschakeld. Initiator-tunnels verbreken direct, Responder-tunnels uiterlijk na inactiviteit of een DPD-time-out.
• Grote overdrachten mislukken ondanks een werkende kleine test; controleer dan MTU en MSS.

Herhaalde firewallcrashes bij multicast via VPN

Als de crashes samenvallen met multicastverkeer door een VPN-tunnel, leg dan eerst de firmwareversie en build, de betrokken tunnel, de tijdstippen en beschikbare diagnose- of crashgegevens vast. Sophos bevestigt dit probleem als NC-180433 en heeft het verholpen in SFOS 22.0 MR2 Build 546.

De openbare probleembeschrijving noemt geen specifiek tunneltype of multicastontwerp en geeft geen CLI-workaround. Controleer bij een oudere SFOS 22-build het upgradepad, werk bij naar MR2 Build 546 of een nieuwere goedgekeurde versie en test hetzelfde verkeer daarna gecontroleerd opnieuw. Wijzig tunnelparameters, IPsec Acceleration of services niet op basis van een aanname. Als de firewall ook met MR2 of nieuwer blijft crashen, moeten de verzamelde gegevens aan Sophos Support worden verstrekt in plaats van het probleem automatisch aan NC-180433 te blijven toeschrijven.

De normale configuratie en gecontroleerde acceptatietest worden uitgelegd in Multicast Routing op Sophos Firewall; de hier beschreven crash blijft een firmwaregebonden uitzonderingssituatie.

IKEv2-pakketten worden gefragmenteerd

Bij Known Issue NC-136352 kan het standaard IKEv2-profiel zoveel DH-groepen aanbieden dat IKE-pakketten groter worden dan 1'500 bytes. Als een tussenliggend component fragmenten of PMTU-informatie verwerpt, blijft de Initiator verzenden terwijl de Responder niets ontvangt.

Controleer bij precies dit foutbeeld de peer in de Advanced Shell:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Bied daarna in het IPsec-profiel alleen de werkelijk benodigde DH-groep of aanzienlijk minder groepen aan. Algemene tcpdump-filters en PCAP-export staan in Sophos Firewall tcpdump.

PPPoE-alias en IPsec Acceleration

NC-181526 betreft SFOS 22.0 GA Respin Build 411 of MR1 op bepaalde XGS Appliances: de tunnel gebruikt een aliasinterface van een PPPoE-WAN-poort, is verbonden, maar transporteert bij actieve IPsec Acceleration geen gebruikersgegevens. XGS 88/88w, 108/108w, 118/118w en 128/128w zijn uitgezonderd.

De actuele Sophos Known Issues List noemt SFOS 22.0.2 MR2 Build 546 als fixversie; in de gepubliceerde MR2-fixlijst staat NC-181526 echter niet afzonderlijk. Herhaal na de update daarom dezelfde teststroom in plaats van de fix uitsluitend uit de versieaanduiding af te leiden.

⚠️ Het uitschakelen van IPsec Acceleration is globaal, start alle IPsec-tunnels opnieuw en veroorzaakt een onderbreking. Test alleen bij een exact passende combinatie van build, hardware, PPPoE-alias en foutbeeld in een onderhoudsvenster.

De volgende opdrachten worden uitgevoerd in de Device Console:

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

Herstel zonder verbetering de vóór de test genoteerde status. Als acceleration actief was, gebruik dan:

system ipsec-acceleration enable

SFOS 22.0 MR2 verhelpt met NC-180520 een vergelijkbaar maar ander alias-IP-geval: de XFRM-gateway kon bij actieve Acceleration onbereikbaar blijven als ESP via een andere WAN-poort binnenkwam. De twee issue-ID’s mogen niet worden gelijkgesteld. Aanvullende controles voor en na de update staan in de SFOS 22 Upgrade Check.

Controle en escalatie

Herhaal na elke wijziging dezelfde afzonderlijke teststroom en documenteer ten minste de volgende punten:

1. Tijdstip, tunnelnaam, peer-IP, Source, Destination en Service
2. WebAdmin-status en ipsec statusall vóór en na de test
3. toegewezen firewall- en NAT-regel
4. Packet Capture en tellers in beide richtingen
5. retourroute en remote regel bij de peer
6. wijziging, resultaat en voorbereide rollback

Schakel daarna alleen StrongSwan-debug uit die tijdens deze procedure is geactiveerd. Wijzig een vooraf bestaande status niet voordat eigenaar en doel duidelijk zijn. Verzamel relevante logs gericht voor Sophos Support; Sophos Firewall-logs opslaan beschrijft de export. Controleer grotere logpakketten en captures vóór het delen op gevoelige gegevens.