VPN-tunnel komt niet op of is instabiel
Een VPN-tunnel die helemaal niet opkomt, is meestal een kwestie van parameters of firewall. Een tunnel die wél opkomt maar wegvalt of half werkt, is bijna altijd MTU, NAT-timeouts of een rekey die niet lukt.
Loop je hier nu tegenaan?
Bel en leg het voor. Vaak is in tien minuten duidelijk waar het aan ligt. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Herken je dit?
- De tunnel komt niet tot stand, phase 1 of phase 2 faalt.
- De tunnel valt elke paar uur weg en komt daarna weer terug.
- De tunnel staat up maar er loopt geen verkeer.
- Kleine pakketten gaan er wel door, grote bestanden blijven hangen.
- Na een firmware-update of providerwissel is het begonnen.
Waar het meestal aan ligt
In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.
IPsec phase 1: parameters komen niet overeen
IKE-versie, encryptie, DH-groep, lifetime en identiteiten moeten aan beide kanten gelijk zijn. Eén afwijking en de onderhandeling stopt, vaak met een weinig zeggende foutmelding.
Phase 2 en selectors
Phase 1 op, phase 2 niet: meestal verschillen de traffic selectors of subnetten, of de ene kant verwacht een route-based en de andere een policy-based tunnel.
NAT-T en poorten
Zit één kant achter NAT, dan moet NAT-traversal aan en moet UDP 4500 openstaan naast 500. Bij WireGuard moet de gekozen UDP-poort doorgezet zijn naar de juiste host.
Wegvallen door NAT-timeouts
WireGuard is stil als er geen verkeer is; zonder PersistentKeepalive ruimt de NAT-tabel de sessie op en komt de tunnel pas terug bij nieuw verkeer vanaf de juiste kant.
MTU en fragmentatie
Encapsulatie kost ruimte. Zonder aangepaste MTU of MSS-clamping werkt de tunnel voor ping en SSH, maar blijft groot verkeer hangen. Het meest voorkomende "halve tunnel"-probleem.
Routing en firewall achter de tunnel
De tunnel staat up, maar er is geen route naar het andere subnet, of de firewall staat het verkeer niet toe. Een tunnel is geen route: beide moeten kloppen.
Wat ik als eerste check
Doe deze stappen zelf, of bel en dan lopen we ze samen door.
- 1
Kijk hoe ver de onderhandeling komt
Bij IPsec:
swanctl --list-sasofipsec statusall. Faalt phase 1, dan vergelijk je parameters; faalt phase 2, dan de selectors. Dat onderscheid bepaalt alles. - 2
Controleer of de UDP-poorten aankomen
Met
tcpdump -ni any udp port 500 or udp port 4500(IPsec) of de WireGuard-poort zie je of de pakketten überhaupt binnenkomen. Geen pakketten betekent firewall of NAT, niet configuratie. - 3
Test met een handshake-teller
Bij WireGuard laat
wg showde laatste handshake zien. Loopt die op tot boven de twee minuten terwijl er verkeer zou moeten zijn, dan komt de retour niet aan. - 4
Zet PersistentKeepalive op de kant achter NAT
Een waarde van 25 seconden houdt de NAT-sessie open. Dat lost het merendeel van de "valt steeds weg"-klachten bij WireGuard op.
- 5
Test de MTU door de tunnel
ping -M do -s 1300naar de andere kant en verlagen tot het lukt. Stel daarna de tunnel-MTU in en clamp de MSS. Doe dit standaard, niet alleen bij klachten. - 6
Controleer routes en policies aan beide kanten
Beide kanten moeten een route naar het andere subnet hebben en het verkeer toestaan. Bij policy-based tunnels moeten de selectors precies spiegelen.
De twee soorten VPN-problemen
Er zijn er precies twee. Of de tunnel komt niet tot stand — dan gaat het over parameters, poorten en identiteiten, en is het een kwestie van naast elkaar leggen wat beide kanten verwachten. Of de tunnel staat en het verkeer werkt niet goed — dan gaat het over MTU, routing, firewall of keepalives.
Wat tijd kost, is de verwarring tussen die twee: iemand ziet “up” staan en begint aan de tunnelparameters te sleutelen terwijl er alleen een route ontbreekt.
Koppeling met een derde partij
Het vervelendste bij VPN’s is dat je bijna nooit beide kanten beheert. Ik kan het gesprek met de engineers aan de andere kant voeren in hun taal, met de parameters erbij, zodat er niet dagenlang mails heen en weer gaan.
Veelgestelde vragen
- WireGuard of IPsec — wat kies ik?
- WireGuard als je beide kanten zelf beheert: eenvoudiger, sneller en veel minder te configureren. IPsec als je moet koppelen met apparatuur of leveranciers die alleen dat spreken, wat in de zakelijke wereld vaak het geval is. Beide zijn prima; de keuze gaat over wie er aan de andere kant zit.
- Mijn tunnel staat up, maar ik kan niets bereiken.
- Dan is de tunnel goed en de routing of firewall niet. Controleer of beide kanten een route naar het andere subnet hebben, of de firewall het toestaat, en of er geen NAT tussen zit die adressen herschrijft. Een tunnel die up staat, is nog geen pad.
- Waarom werkt SSH wel en een bestandsoverdracht niet?
- Klassiek MTU-probleem. SSH stuurt kleine pakketten, een overdracht grote. Zet de MTU op de tunnelinterface en clamp de MSS, dan verdwijnt het.
- Kun je een tunnel opzetten naar een leverancier die alleen IPsec doet?
- Ja, dat is een veelvoorkomende opdracht. Ik stem de parameters af met hun engineers, richt het aan jouw kant in en test het samen. Meestal een kwestie van uren, zolang er aan de andere kant iemand beschikbaar is.
Verwante problemen
Pakketverlies en MTU-problemen vinden
Sommige sites laden niet, VPN-verkeer hapert, grote bestanden blijven hangen: typische MTU-symptomen. Zo onderscheid je MTU van echt pakketverlies.
[MikroTik]MikroTik specialist inhuren
Hulp met MikroTik en RouterOS: firewall, BGP, VPN's, VLANs en de eigenaardigheden van fasttrack, CRS-switching en upgrades naar RouterOS 7.
Zelf geen tijd of geen zin om te blijven zoeken?
Ik kijk mee, zeg eerlijk wat er aan de hand is en los het op. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Terug naar BGP- en netwerkspecialist inhuren