Sophos Firewall IPsec VPN Problemen oplossen

IPsec Site-to-site VPN’s zijn vaak onopvallend zolang ze werken. Als een tunnel echter niet omhoog komt, instabiel blijft na een herverbinding, of als verbonden wordt weergegeven maar geen verkeer transporteert, heeft u voor de analyse een schone opdracht nodig. Anders spring je snel heen en weer tussen PSK, routes, firewallregels en logs zonder de werkelijke oorzaak te zien.

In het artikel wordt uitgelegd hoe u IPsec-verbindingen op de Sophos Firewall systematisch kunt controleren: eerst de tunnelstructuur, vervolgens de onderhandelde netwerken en ten slotte de daadwerkelijke pakketstroom. Wanneer er voor het eerst een nieuwe sitetunnel wordt gepland of ingesteld, past Sophos Firewall Site-to-site instellen IPsec VPN als eerste. Voor algemene CLI-basisbeginselen helpt Sophos Firewall CLI-probleemoplossing: belangrijke opdrachten ook.

Voordat u problemen oplost

Eerst moet u de uitgangssituatie kort documenteren. Dit lijkt banaal, maar het bespaart veel tijd omdat veel IPsec-problemen voortkomen uit asymmetrische aannames: de ene kant gelooft dat het netwerk A met netwerk B verbindt, maar de andere kant verwacht verschillende ID’s, verschillende subnetten of een andere IKE-versie.

Belangrijke punten:

• Tunnelnaam: bijvoorbeeld azure-vpn
• Lokale gateway: WAN-adres of FQDN of Sophos Firewall
• Remote Gateway: openbaar IP-adres of FQDN van de externe site
• IKE-versie: IKEv1 of IKEv2
• Authenticatie: vooraf gedeelde sleutel of certificaat
• Lokale ID / Externe ID: IP-adres, FQDN of e-mailachtige identificatie
• Lokale netwerken: bijvoorbeeld 172.16.10.0/24
• Remote netwerken: bijvoorbeeld 10.20.30.0/24
• VPN-type: op beleid of op route gebaseerd
• Gatewaytype: Initiate the connection, Respond only of failovergroep
• IPsec-profiel: Fase 1, Fase 2, DH-groepen, PFS en levensduur
• Verwacht verkeer: Bron, bestemming, haven en richting

Met op beleid gebaseerde IPsec maken de lokale en externe netwerken deel uit van de tunnelonderhandelingen. Bij routegebaseerde IPsec is het ook van belang welke routes naar de tunnelinterface verwijzen. Als het verkeer ondanks een actieve tunnel de verkeerde kant op rijdt, zijn vaak IPsec Routes, statische routes, SD-WAN-beleidsroutes of de Routevoorrang van Sophos Firewall betrokken.

Als de tunnel open is en kleine tests werken, maar grotere transmissies vastlopen, moet u ook MTU en MSS controleren. De procedure hiervoor staat in Sophos Firewall Controleer MTU en MSS op VPN-problemen.

⚠️ Foutopsporingslogboeken en pakketopnamen kunnen gevoelige gegevens bevatten, zoals openbare IP-adressen, interne netwerken, hostnamen of payloads. Dergelijke gegevens mogen alleen specifiek en voor een beperkte tijd worden verzameld en gecontroleerd voordat ze worden doorgegeven.

Diagnostisch pad

Een eenvoudige reeks helpt in de praktijk:

1. Komt de tunnel eraan? Zo niet, controleer dan eerst de IKE-versie, IPsec-profiel, ID’s, PSK/certificaat, NAT-T en toegankelijkheid van het externe station.
2. Wordt fase 2 gebouwd? Zo niet, controleer dan de verkeerskiezers, lokale en externe netwerken, PFS en fase 2-voorstellen.
3. Is er een beveiligingskoppeling geïnstalleerd? Zo ja, vink ipsec statusall aan en let op de bytetellers.
4. Gaat het verkeer door de tunnel? Zo nee, controleer de firewallregels, NAT, routing, routeprioriteit, IPsec routes en retourpad.
5. Kun je pakketten zien? Indien onduidelijk, combineer Log Viewer en Packet Capture.

Een veel voorkomende misvatting: een groene tunnelstatus bewijst alleen maar dat er fundamenteel over IPsec is onderhandeld. Het bewijst niet dat de firewallregels correct zijn, dat de routes correct zijn of dat het externe station de weg terug kent.

Voordat u overschakelt naar de Advanced Shell, is het de moeite waard om de WebAdmin-lijsten te bekijken:

• Onder Site-to-site VPN > IPsec kunt u Extra eigenschappen tonen gebruiken om extra kolommen weer te geven, zoals Lokaal subnet, Extern subnet, Gatewaytype of Profiel.
• Onder Profiles > IPsec profiles kunt u ook aanvullende eigenschappen weergeven om fase 1- en fase 2-waarden sneller te vergelijken.

Dit is niet zo diep als een logboek, maar het voorkomt triviale fouten: verkeerd profiel, verkeerd gatewaytype, dezelfde subnetten in meerdere tunnels of een tunnel die niet eens deel uitmaakt van de verwachte failovergroep.

Welk niveau wordt beïnvloed?

Voordat u debuglogboeken maakt, moet u het probleem grofweg classificeren. Hierdoor wordt het sneller duidelijk of je moet zoeken naar IKE, fase 2, routing of packet flow.

• Tunnel blijft offline: Het probleem ligt waarschijnlijk bij IKE, gateway, ID’s, PSK, certificaat of voorstel. Bekijk strongswan.log live en vergelijk fase 1.
• Tunnel schakelt voortdurend tussen omhoog en omlaag: Focus op Rekey, DPD, WAN-stabiliteit of voorstel. Vergelijk tijdstempels, DPD, levensduur en WAN-gebeurtenissen.
• Fase 1 is aanwezig, maar geen kind-SA: Focus op verkeerskiezers, fase 2-voorstel of PFS. Controleer lokale en externe netwerken in spiegelbeeld.
• Tunnel is groen, maar bytetellers blijven leeg: Verkeer bereikt waarschijnlijk de tunnel niet. Controleer firewallregel, NAT, route en clientgateway.
• Alleen uitgaande bytes nemen toe: Retourpad of extern station ontbreekt. Controleer de externe firewall, de externe route en het doelsysteem.
• Packet Capture toont pakketten zonder overeenkomende regel: Regelvolgorde, zone of service komen niet overeen. Vergelijk Log Viewer, Policy Test en Rule ID.

Deze classificatie vervangt geen gedetailleerde analyse. Dit voorkomt echter dat u met firewallregels op zoek gaat naar een fase 2-fout of dat u de vooraf gedeelde sleutel onnodig opnieuw instelt in het geval van een retourpadprobleem.

Verzamel logboeken

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

• strongswan.log: hoofd-IPsec-logbestand voor IKE, authenticatie en onderliggende SA’s.
• charon.log: Logboek van de IKE-daemon, nuttig afhankelijk van de versie en situatie.
• strongswan-monitor.log: Bewaking van de IPsec-service.
• dgd.log: Detectie van dode gateway en VPN-failover.

Open de Advanced Shell met SSH en ga indien nodig naar de logmap:

cd /log

Het livelog is direct te volgen:

tail -f /log/strongswan.log

Als er meerdere tunnels actief zijn, moet u filteren. Dit kan via de tunnelnaam, een peer-IP of een typische fouttekst:

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

Voor bestaande logbestanden is less vaak handiger:

less /log/strongswan.log

In less kunt u binnen het bestand zoeken met /suchbegriff. Als alternatief filtert grep rechtstreeks:

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

Schakel StrongSwan-foutopsporing in

Als het normale logboek niet voldoende is, kunt u de StrongSwan-service in de foutopsporingsmodus zetten:

service strongswan:debug -ds nosync

Controleer vervolgens of de service in debug-modus draait:

service -S | grep strongswan

De uitvoer moet de status RUNNING,DEBUG bij strongswan weergeven. Sluit vervolgens de tunnel opnieuw aan of reproduceer specifiek de fout en bekijk het logboek:

tail -f /log/strongswan.log

Met hetzelfde debug-commando wordt de debug-modus opnieuw uitgeschakeld:

service strongswan:debug -ds nosync

⚠️ Laat debug alleen draaien zolang het echt nodig is. IPsec-debug kan zeer snel grote logbestanden genereren en onnodige ruimte in beslag nemen op de firewall.

Fase 1: IKE, ID’s en authenticatie

Als de tunnel helemaal niet is opgezet, ligt de oorzaak meestal vóór of tijdens fase 1. Dan onderhandelen de gateways niet over payload-netwerken, maar eerst over IKE, authenticatie en de identiteit van beide partijen.

Typische oorzaken:

• IKE-versie komt niet overeen
• IPsec-profiel of voorstel komt niet overeen
• lokale of externe ID is anders dan verwacht
• Vooraf gedeelde sleutel is onjuist
• Het externe station bereikt het verkeerde openbare IP-adres
• NAT-T of port forwarding op UDP 500 en 4500 is niet schoon
• Certificaten, CA of geldigheid komen niet overeen met certificaatgebaseerde authenticatie

Geen IKE-configuratie gevonden

Een logvermelding zoals no IKE config found of NO_PROPOSAL_CHOSEN betekent vaak dat Sophos Firewall geen geschikte IKE-configuratie voor het binnenkomende pakket kan vinden. Dit kan te wijten zijn aan de IKE-versie, de gateway, de ID’s of het IPsec-profiel.

Controleer:

• Is IKEv1 of IKEv2 aan beide kanten correct?
• Komt het externe station overeen met het geconfigureerde externe gateway-adres of met FQDN?
• Zijn lokale en externe ID correct?
• Zijn codering, authenticatie, DH Group en Lifetime compatibel?
• Gebruikt het externe station mogelijk een ander openbaar IP-adres dan gedocumenteerd?

Peer-authenticatie mislukt

peer authentication failed, AUTH_FAILED of no matching peer config found duidt vaak op niet-overeenkomende ID’s of authenticatiegegevens. Bij vooraf gedeelde sleutels wordt de sleutel vaak als eerste verdacht. Dit is vaak waar, maar niet altijd. Als de ID niet overeenkomt, controleert de firewall mogelijk niet eens de verwachte peer-configuratie.

Controleer:

• Lokale ID van de ene kant komt overeen met de externe ID van de andere kant.
• Externe ID van de ene kant komt overeen met de lokale ID van de andere kant.
• Spelling, hoofdletters en kleine letters, FQDN en IP-adressen zijn exact correct.
• De vooraf gedeelde sleutel is ingevoerd zonder spaties aan het begin of einde.
• Als er meerdere tunnels zijn naar dezelfde externe locatie, is het duidelijk welke verbinding moet worden gematcht.

Ongeldige HASH_V1-payload of decodering mislukt

Met IKEv1 duiden berichten als invalid HASH_V1 payload length of decryption failed vaak op een onjuiste vooraf gedeelde sleutel. Met IKEv2 zie je meestal AUTHENTICATION_FAILED of AUTH_FAILED.

In de praktijk moet u de vooraf gedeelde sleutel aan beide kanten opnieuw instellen in plaats van deze alleen visueel te vergelijken. Copy-paste van wachtwoordbeheerders, onzichtbare spaties of verschillende speciale tekens zijn klassieke tijdverspilling.

Fase 2: Verkeersselectors en beveiligingsassociaties

Als fase 1 succesvol is, maar fase 2 mislukt, gaat het meestal om de netwerken en de kind-SA. De Sophos Firewall moet met het externe station onderhandelen welke lokale en externe subnetten door de tunnel mogen.

Typische lognotities:

• 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 externe netwerken zijn aan beide zijden in spiegelbeeld geconfigureerd.
• Netmask en individuele hostobjecten zijn exact correct.
• Er zijn geen ongewenste overlappingen met andere tunnels.
• Meerdere fase 2-netwerken zijn aan beide zijden hetzelfde weergegeven.
• PFS, ESP-encryptie, authenticatie en levensduur werken samen.

Voorbeeld: Als Sophos Firewall 172.16.10.0/24 lokaal en 10.20.30.0/24 op afstand verwacht, moet het externe station 10.20.30.0/24 na 172.16.10.0/24 in exact spiegelbeeld aanbieden. Een /24 aan de ene kant en een enkele host of een groter netwerk aan de andere kant kunnen voldoende zijn om te voorkomen dat de onderliggende SA wordt geïnstalleerd.

De tunnel is in gebruik, maar er rijdt geen verkeer

Als de tunnel als verbonden wordt weergegeven, maar er komt geen verkeer doorheen, is IPsec zelf niet automatisch de oorzaak. Dan gaat het meestal over routing, firewallregels, NAT of het retourpad.

Controleer eerst de IPsec-status in de Advanced Shell:

ipsec statusall

Wat vooral interessant is, zijn:

• Is IKE SA ESTABLISHED?
• Is het kind SA INSTALLED?
• Welke lokale en externe netwerken worden weergegeven?
• Stijgen de bytetellers in beide richtingen?
• Zie je alleen uitgaande bytes en geen inkomende?
• Wordt er regelmatig opnieuw aangesloten of opnieuw ingetoetst?

Met routegebaseerd IPsec kunt u ook controleren of de XFRM-status en het beleid überhaupt zijn geïnstalleerd:

ip xfrm state
ip xfrm policy

Als ipsec statusall een gevestigde SA toont, maar ip xfrm state of ip xfrm policy niet overeenkomt met de verwachte tunnel, ligt het probleem vaak niet langer bij PSK of voorstel, maar bij verkeerskiezers, XFRM-configuratie, routes of concurrerende tunnels.

Als de onderliggende SA is geïnstalleerd maar de bytetellers leeg blijven, bereikt het verwachte verkeer de tunnel waarschijnlijk niet. Vervolgens controleer je het pad voor en na IPsec.

Firewallregels

Voor het verkeer door de tunnel zijn passende firewallregels vereist. Afhankelijk van het zonemodel is dit bijvoorbeeld LAN tot VPN, VPN tot LAN of een aparte zone. De regel moet correct betrekking hebben op bron, bestemming, service en richting.

Belangrijk:

• Activeer Log firewallverkeer in de relevante regels.
• Controleer de regelpositie zodat er vooraf geen algemene regel meer van kracht wordt.
• Selecteer de bron- en bestemmingszones correct.
• Wanneer u meerdere VPN’s gebruikt, gebruik dan geen objecten die te breed zijn als deze in de verkeerde tunnel passen.
• Controleer bewust beveiligingsfuncties zoals IPS, webfilters of Application Control of deze actief zijn in het verkeer.

Test firewallregel met Log Viewer, Policy Test en Packet Capture beschrijft een algemene testprocedure.

Routing en IPsec Routes

Als de firewall geen verkeer de tunnel in stuurt, controleer dan de routes. Voor op beleid gebaseerde IPsec kan de IPsec-routeringstabel ook relevant zijn:

ip route show table 220

Als handmatig in kaart brengen noodzakelijk is, kan een IPsec route op de Sophos Firewall helpen. Als meerdere routeringstypen met elkaar concurreren, moet u ook de routeringsprioriteit van Sophos Firewall controleren.

Controleer:

• Is er een specifiekere statische route die verkeer onderschept?
• Wordt een SD-WAN-beleidsroute van kracht vóór de VPN-route?
• Verwijst de clientgateway echt naar Sophos Firewall?
• Heeft het externe station een retourroute naar het lokale netwerk?
• Zijn er overlappende lokale en externe netwerken?

Bij routegebaseerd VPN moet u ook de XFRM-interfaces controleren. Twee XFRM-interfaces mogen niet worden geconfigureerd met overlappende of identieke interfacenetwerken. Als xfrm1 en xfrm2 zich in hetzelfde overdrachtsnetwerk bevinden, kan de tunnel netjes tot stand worden gebracht en toch een onjuiste route volgen. Controleer in dit geval de XFRM-adressering onder Network > Interfaces en gebruik unieke netwerken.

Als meerdere IPsec-verbindingen dezelfde lokale en externe subnetten gebruiken, mogen ze niet losjes naast elkaar liggen. Dergelijke verbindingen horen thuis in een doelbewust failover-ontwerp of moeten een andere selector-/routeringslogica ontvangen. Anders kan de firewall de juiste tunnel niet op betrouwbare wijze gebruiken zoals verwacht.

NAT

NAT is niet fundamenteel verkeerd met IPsec, maar het moet bewust worden geconfigureerd. Onbedoelde MASQ of een SNAT-regel die te breed is, kan ertoe leiden dat het externe station het verkeer niet langer aan het verwachte netwerk toewijst.

Controleer:

• Heeft een generieke MASQ-regel voorrang op een specifieke VPN NAT-regel?
• Verwacht het externe station originele IP-adressen of vertaalde adressen?
• Is NAT aan beide kanten gedocumenteerd?
• Komt de NAT-regel overeen met de richting van het verkeer?

Als het om NAT gaat, zal het artikel NAT op Sophos Firewall u helpen begrijpen: SNAT, DNAT, MASQ, PAT.

SFOS 22: Beleidsgericht IPsec en NAT bewust controleren

Bij het upgraden naar SFOS 22 moet beleidsgebaseerde IPsec bijzonder zorgvuldig worden gecontroleerd. Sophos wijst in de release notes van SFOS 22 op een veranderd gedrag voor op beleid gebaseerde IPsec VPN. Bovendien is het volgende gedocumenteerd in de opgeloste problemen NC-170917: Op beleid gebaseerd IPsec Verkeer kan mislukken als de standaard SNAT-regel is geconfigureerd met een statisch IP-adres in plaats van MASQ.

In de praktijk betekent dit: Als een beleidsmatige tunnel na de upgrade groen is, maar er geen of slechts éénrichtingsverkeer stroomt, mag NAT niet als secundair onderwerp worden behandeld. Een oude, brede of ongewoon aangepaste standaard SNAT-regel kan precies het verkeer veranderen dat het externe station verwacht met de oorspronkelijke netwerken.

Typische controlepunten na een SFOS 22-upgrade:

• Is de tunnel echt op beleid gebaseerd? Met op beleid gebaseerd IPsec maken lokale en externe netwerken deel uit van de onderhandeling. NAT kan deze verwachting doorbreken.
• Is de standaard SNAT-regel aangepast? Een statisch SNAT IP in plaats van MASQ kan na een upgrade andere effecten hebben dan verwacht.
• Zijn er specifieke VPN NAT-regels? Deze moeten hoger zijn dan de algemene SNAT- of MASQ-regels en overeenkomen met de richting van het verkeer.
• Komen verkeerskiezers en NAT-objecten overeen? De externe site moet de originele netwerken of de vertaalde netwerken verwachten, en niet beide willekeurig.
• Toont Packet Capture het verwachte bron-IP? Zo kunt u zien of de firewall vóór de tunnel een ander bronadres gebruikt.

Een schone testcase bestaat uit een bron, een doel en een dienst. Vervolgens controleert u achtereenvolgens de firewallregel, NAT-regel, ipsec statusall, ip route show table 220, Packet Capture en het externe station. Als de test alleen werkt als de NAT-regel is uitgeschakeld of verplaatst, ligt het probleem niet bij het tot stand brengen van de tunnel, maar bij het pad naar de tunnel.

Voor upgradeplanning is Sophos Firewall vóór SFOS 22 Upgrade controleren ook geschikt. Voor NAT-basisprincipes en regelvolgorde is NAT begrijp Sophos Firewall een beter beginpunt.

Opnieuw sleutelen, failover en interfacestatus

Als een tunnel eerst werkt en vervolgens mislukt, is de initiële configuratie niet altijd verkeerd. Vervolgens moet u de voortgang in de loop van de tijd controleren:

• Op verkeer gebaseerd opnieuw sleutelen voor externe providers: Sophos Firewall verwacht op tijd gebaseerde logica voor opnieuw sleutelen. Als de externe locatie een op verkeer gebaseerde hersleuteling afdwingt, kan de tunnel na een tijdje vastlopen of opnieuw onderhandelen.
• Sleuteluitwisselingsbotsingen: Als beide partijen tegelijkertijd opnieuw sleutelen, kunnen er onstabiele fasen optreden. In dergelijke gevallen moeten de levens van Fase 1 en Fase 2 bewust worden gecoördineerd tussen de initiatiefnemer en de hulpverlener.
• Interface uitgeschakeld: Als de bijbehorende interface is uitgeschakeld, wordt de verbinding tussen een site-naar-site-tunnel onmiddellijk verbroken. Responder- en RAS-verbindingen worden uiterlijk door inactiviteit of een DPD-time-out opgemerkt.
• DGD en failovergroep: Controleer voor failoverscenario’s bovendien dgd.log, gatewaystatus, primaire/secundaire verbinding en identieke subnetparen.

Dergelijke fouten zijn gemakkelijker te detecteren met behulp van tijdstempels dan met behulp van een enkele momentopname. Daarom moet u bij periodieke problemen de tunnelstatus, strongswan.log, dgd.log, WAN-gebeurtenissen en het testen van applicaties combineren.

SFOS 22: PPPoE-WAN met aliasinterface en IPsec Versnelling

Als er na het upgraden naar SFOS 22.0 GA of SFOS 22.0 MR1 een IPsec-tunnel is aangesloten maar er geen verkeer wordt doorgestuurd, kan er bij bepaalde instellingen sprake zijn van een extra speciaal geval. Sophos heeft NC-181526 in de lijst met bekende problemen: Op XGS-hardware kunnen IPsec-tunnels tot stand worden gebracht op aliasinterfaces van een PPPoE WAN-poort, maar kunnen geen nuttig verkeer doorsturen als IPsec versnelling actief is.

Dit punt mag alleen worden gecontroleerd als de normale oorzaken niet passen. Een groene tunnel zonder verkeer is meestal nog steeds een regel-, routerings-, NAT- of retourpadprobleem. Het speciale geval van SFOS 22 wordt waarschijnlijker als al het volgende samenkomt:

• Sophos Firewall draait op SFOS 22.0 GA of SFOS 22.0 MR1.
• Dit is XGS-hardware.
• De betrokken tunnel gebruikt een aliasinterface op een PPPoE WAN-poort.
• De tunnel wordt gebouwd, maar er is geen nuttig verkeer.
• Firewallregels, NAT, routes, retourpad en Packet Capture verklaren het gedrag niet.
• IPsec versnelling is actief.

Het deactiveren van IPsec-versnelling wordt gedocumenteerd als een tijdelijke oplossing:

system ipsec-acceleration off

Dit mag niet worden gebruikt als een generieke IPsec-afstemmingsopdracht. De wijziging hoort thuis in een onderhoudsvenster of een gedocumenteerd ondersteuningsproces, met voor/na-testen en een duidelijke toewijzing aan het betreffende foutpatroon. Sophos vermeldt SFOS 22.0.2 MR2 als de fixversie voor dit bekende probleem. Als deze versie wordt uitgebracht voor de getroffen omgeving, is een geplande update schoner dan een permanent vergeten oplossing.

Praktische testprocedure:

1. Documenttunnelstatus en ipsec statusall.
2. Voer Packet Capture uit met een smal bron-/bestemmingsfilter.
3. Controleer of de tunnel daadwerkelijk een aliasinterface op een PPPoE WAN-poort gebruikt.
4. Noteer de actieve SFOS-versie en het hardwaremodel.
5. Wijzigingen in de IPsec-versnelling mogen alleen gericht en gedocumenteerd worden getest.
6. Vergelijk na de test de byteteller, Packet Capture, Log Viewer en de applicatietest.

Combineer Log Viewer en Packet Capture

De Log Viewer laat zien welke regel of module een verbinding heeft geëvalueerd. Packet Capture in WebAdmin laat daarentegen zien of pakketten daadwerkelijk aankomen, worden doorgestuurd, gedropt of door de firewall zelf worden verwerkt.

Voor IPsec-probleemoplossing moet u een zo smal mogelijke test definiëren:

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

Daarna:

1. Schakel inloggen in de firewallregel in.
2. Filter Log Viewer met bron-IP, bestemmings-IP en module Firewall.
3. Start Packet Capture met een smal filter, bijvoorbeeld host 172.16.10.25 and host 10.20.30.15.
4. Herhaal de test precies één keer.
5. Controleer of pakketten binnenkomen, worden doorgestuurd en of er antwoorden terugkomen.

Interpretatie:

• Er komt geen pakket aan op Sophos Firewall: Controleer client, gateway, VLAN, switch of lokale routering.
• Pakket arriveert maar wordt niet doorgestuurd: Controleer firewallregel, NAT, route of beveiligingsfunctie.
• Pakket wordt naar de tunnel gestuurd, antwoord ontbreekt: Controleer de retourroute, het externe station, de externe firewall of de externe host.
• Alleen uitgaande bytes in ipsec statusall: Controleer het retourpad of het externe beleid.
• Alleen binnenkomende bytes: Controleer de lokale route, lokale firewallregel of doelsysteem.

Voor langere opnames of ondersteuningsgevallen kan het zinvol zijn om specifiek logboeken te verzamelen. Het artikel Sophos Firewall Back-up maken van logbestanden voor ondersteuning en analyse beschrijft de schone export.

Typische foutpatronen

De volgende foutpatronen verwijzen naar de ruwe StrongSwan/Charon-logregels 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 in WebAdmin kijkt in plaats van in het ruwe logbestand, vindt via deze koppeling het bijbehorende geval.

• no IKE config found: IKE-versie, gateway, ID’s of profiel komen niet overeen. Vergelijk de IKE-versie, lokale/externe ID en voorstellen.
• NO_PROPOSAL_CHOSEN: Voorstel komt niet overeen. Controleer codering, authenticatie, DH Group, PFS en levensduur.
• peer authentication failed: ID of authenticatie komt niet overeen. Controleer lokale/externe ID en PSK of certificaat.
• AUTH_FAILED: Vooraf gedeelde sleutel, certificaat of ID komen niet overeen. PSK opnieuw instellen, certificaatketen en ID’s controleren.
• traffic selectors ... inacceptable: Lokale en externe netwerken passen niet. Vergelijk subnetten en hostobjecten in spiegelbeeld.
• failed to establish CHILD_SA: Fase 2-netwerken of ESP-voorstellen passen niet. Controleer verkeerskiezers, PFS, ESP-profiel en levensduur.
• Tunnel groen, geen bytes: Verkeer bereikt de tunnel niet. Controleer firewallregel, route, NAT en clientgateway.
• Uitgaande bytes, geen inkomend: Afstandsstation of retourpad ontbreken. Controleer regels op afstand, route op afstand en doelsysteem.
• ipsec statusall toont SA’s, maar routegebaseerd verkeer stopt later: Controleer XFRM-status, XFRM-beleid, overlappende XFRM-netwerken, failovergroep en rekey-gedrag.
• Meerdere tunnels met dezelfde subnetten: Tunnels horen in een failovergroep of moeten duidelijk verschillende selector-/routeringslogica ontvangen.
• Grote overdrachten lopen vast ondanks een actieve tunnel: Focus op MTU/MSS, pakketverlies of pad-MTU-ontdekking. Controleer MTU en MSS op VPN-problemen.
• SFOS 22, op beleid gebaseerd IPsec, tunnel groen, verkeer ontbreekt: NAT, standaard SNAT of verkeerskiezers passen niet goed bij elkaar na de upgrade. Controleer standaard SNAT, VPN NAT-regels, MASQ, Packet Capture en extern station.
• SFOS 22, PPPoE-WAN-alias, tunnel groen, geen verkeer: Mogelijk bekend probleem met IPsec-versnelling. Test alleen het interfacetype, de SFOS-versie en system ipsec-acceleration off specifiek.
• Opnieuw verbinding maken of regelmatig opnieuw sleutelen: Focus op levensduur, DPD, onstabiele lijn of voorstelonderwerp. Controleer rekey-tijden, DPD, WAN-stabiliteit en logs.

Praktische checklist

Controleer onmiddellijk:

• Noteer de tunnelstatus en de laatste foutmelding in WebAdmin.
• Start tail -f /log/strongswan.log en sluit de tunnel opnieuw aan.
• Controleer de IKE-versie, lokale ID, externe ID en vooraf gedeelde sleutel.
• Vergelijk verkeerskiezers of lokale en externe netwerken in spiegelbeeld.
• Controleer ipsec statusall voor ESTABLISHED, INSTALLED en byteteller.

Wanneer de tunnel gesloten is:

• Controleer firewallregels in beide richtingen.
• Schakel inloggen op de betreffende regels in.
• Filter Log Viewer met Bron, Bestemming en Rule ID.
• Voer Packet Capture uit met een smal filter.
• Controleer NAT-regels en routeprioriteit.
• Voor routegebaseerde VPN, controleer ip xfrm state, ip xfrm policy en XFRM-interfacenetwerken.
• Toon failovergroep en lokale/externe subnetkolommen voor meerdere vergelijkbare tunnels.
• Voor SFOS 22 met op beleid gebaseerde IPsec controleer de standaard SNAT, specifieke VPN NAT-regels en het verwachte bron-IP.
• Controleer voor SFOS 22 met PPPoE-WAN-alias of het bekende probleem met IPsec-versnelling past.
• Bevestig de terugreisroute op het externe station.

Voor ondersteuning of langere analyse:

• Activeer debug slechts kort en deactiveer deze vervolgens weer.
• Maak een back-up van relevante logboeken.
• Documenttijd, tunnelnaam, peer-IP, bron, bestemming en testprocedure.
• Controleer gevoelige gegevens voordat u deze deelt.

Veelgestelde vragen