Naar de inhoud
Avanet

Sophos Firewall IPsec VPN-problemen oplossen

Sophos Firewall

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.

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.
  6. De firewall crasht herhaaldelijk bij multicast via VPN: lok het probleem niet uit met verdere belastingtests. Leg firmwareversie, tijdstippen en beschikbare diagnosegegevens vast; NC-180433 is verholpen in SFOS 22.0 MR2 Build 546.

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.

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 /suchbegriff binnen het bestand.

StrongSwan-debug

Controleer eerst de actuele status in de Advanced Shell als het normale log onvoldoende informatie geeft:

service -S | grep strongswan

Als RUNNING,DEBUG al wordt weergegeven, voer de toggle dan niet opnieuw uit als vermeende activering. Gebruik de bestaande debugmodus en schakel deze daarna uit zoals hieronder beschreven.

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

Als debug nog niet actief is, voer de toggle uit, controleer de nieuwe status en reproduceer het probleem precies één keer:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

Bij strongswan moet RUNNING,DEBUG staan. Daarna schakelt dezelfde opdracht de debugmodus weer uit; de tweede opdracht bevestigt het herstel:

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 van de ene kant moet overeenkomen met de Remote ID van de andere kant en omgekeerd. Stel de PSK aan beide kanten opnieuw in; onzichtbare spaties of copy-paste vanuit wachtwoordmanagers zijn veelvoorkomende oorzaken. Een onjuiste ID kan de peerkoppeling al verhinderen voordat de verwachte PSK wordt gecontroleerd.

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.

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 leeg, 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.

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 verwerkt SFOS 22 de VPN-routes in de backend. Handmatige IPsec Routes en Route Precedence worden gecontroleerd in de Device Console:

system ipsec_route show
system route_precedence show

De uit oudere troubleshootingprocedures bekende opdracht in de Advanced Shell is onder SFOS 22 geen betrouwbaar bewijs voor een policy-based tunnel:

ip route show table 220

Onder SFOS 22 zijn policy-based VPN-routes en handmatige ipsec_route-vermeldingen daar niet zichtbaar. Een ontbrekende vermelding bewijst daarom noch een ontbrekende route, noch een routingfout.

Bij route-based IPsec moeten een statische, SD-WAN- of dynamische route naar de XFRM-interface en passende XFRM-states aanwezig zijn. Controleer de XFRM-interface onder Network > Interfaces en het pad onder Diagnostics > Tools > Route lookup; de Device Console toont geconfigureerde statische routes:

show static-route

De XFRM-states worden gecontroleerd in de Advanced Shell:

ip xfrm state
ip xfrm policy

XFRM-interfaces mogen geen overlappende transfernetwerken gebruiken. Verbindingen met identieke lokale en remote subnetten horen in een gezamenlijke IPsec-failovergroep of vereisen duidelijk andere selector- en routinglogica. De gekoppelde procedure legt de groepsvolgorde, Health Check en de gecontroleerde omschakeltest uit.

NAT per tunneltype controleren

NAT is toegestaan, maar moet passen bij het tunneltype en de adressen die de peer verwacht.

  • 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: MASQ vertaalt de Source naar het XFRM-IP; dit is zichtbaar in de binnenste IP-header van Packet Capture.
  • Route-based met concrete Traffic Selectors: als een MASQ-regel matcht, dropt de firewall het verkeer omdat aan zulke XFRM-interfaces geen IP-adres is toegewezen.

De oorspronkelijke en vertaalde Source moeten zijn gedocumenteerd, bij de peer zijn toegestaan en een retourroute hebben. Basisprincipes en regelvolgorde staan in NAT op Sophos Firewall.

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.
  • 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.
  • Meerdere verbindingen met dezelfde subnetten staan niet in dezelfde failovergroep.
  • 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 Build 411 of MR1 Build 490 op bepaalde fysieke 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 oorspronkelijke toestand:

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 StrongSwan-debug daarna uit. 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.