Je VPN-client zegt verbonden, de handshake is van een minuut geleden, en je kunt het tunneladres van de router pingen. Alleen: de NAS, de printer en de server achter die router reageren nergens op.
Dit hoofdstuk gaat over een tunnel die staat maar niets doorlaat. Komt de tunnel helemaal niet op, ga dan naar Er komt geen WireGuard-handshake. Gaat er in het geheel geen verkeer doorheen, ook niet naar de router, zie De VPN staat maar er gaat geen verkeer doorheen. Bereiken twee locaties elkaar maar één kant op, zie Twee locaties zien elkaar maar één kant op.
De snelle controles, in deze volgorde
- Weet de client waar het LAN is? Op Windows
route print, op Linuxip route, op een telefoon de routes in de VPN-app. Goed antwoord: het LAN-subnet staat erbij, via de tunnel. Staat het er niet, dan verstuurt je client de pakketten nooit en hoef je in de router niets te zoeken. - Loopt er verkeer door de tunnel?
/interface wireguard peers print. Goed antwoord:rxentxlopen op, enlast-handshakeis minder dan twee minuten oud. - Kan de router het doel bereiken?
/ping 192.168.88.10 src-address=10.10.10.1, met het tunneladres van de router als bron. Lukt dat niet, dan ligt het aan de LAN-kant en niet aan de VPN. Dit is de belangrijkste splitsing in dit hoofdstuk. - Komen de pakketten de router uit?
/tool sniffer quick interface=bridge ip-address=10.10.10.2. Zie je ze wel vertrekken en niets terugkomen, dan negeert het doelapparaat je. - Telt er een drop-regel mee?
/ip firewall filter print statsterwijl je het probeert. Een regel met een teller die precies meeloopt wijst zichzelf aan. - Wat doet het doelapparaat? Kijk naar zijn eigen firewall en zijn gateway. Ping vanaf dat apparaat terug naar het tunneladres van de client.
De gewone oorzaken, meest voorkomend eerst
AllowedIPs bevat jouw netwerk niet
Bij WireGuard bepaalt AllowedIPs in de clientconfiguratie welke bestemmingen door de tunnel gaan. Zet je in de tool Al het verkeer door de VPN uit, dan schrijft de configurator AllowedIPs = <tunnelnetwerk>, <LAN-netwerk>, en dat LAN-netwerk is alleen het untagged LAN. Staan je machines op een VLAN met een ander subnet, dan staat dat subnet niet in het bestand en verstuurt de client die pakketten gewoon over zijn eigen internetverbinding. Zet de ontbrekende subnetten er met een komma achter, of gebruik full tunnel.
De firewall van het doelapparaat zelf
Windows beschouwt 10.10.10.2 als een vreemd netwerk. De regels die bestandsdeling, RDP en printers toestaan gelden vaak alleen voor het eigen subnet. Het apparaat is dan bereikbaar met ping en verder met niets. Voeg het tunnelsubnet toe aan de toegestane bereiken op dat apparaat.
Het doelapparaat heeft de router niet als gateway
Een NAS met een eigen gateway, een server met een handmatige route of een tweede router in het LAN: het antwoord gaat dan ergens anders heen en komt nooit terug in de tunnel. Je ziet dat direct aan de sniffer-test hierboven.
Overlappende subnetten
Je zit in een café op 192.168.88.0/24 en je kantoor is ook 192.168.88.0/24. De client kiest dan zijn eigen lokale netwerk en er is geen instelling die dat repareert. Dit komt veel voor, want dat is precies het standaardbereik van RouterOS. De enige oplossing is een ander LAN-bereik kiezen; zie Adressen plannen.
Je bereikt wel de hosts, maar niet de router
Dat is een ander probleem met hetzelfde gevoel. De input-keten van de firewall laat alleen verkeer toe dat van de LAN-lijst komt. Staat de tunnel niet in die lijst, dan kun je LAN-apparaten prima bereiken maar de router zelf niet: geen WinBox, geen webinterface, en geen DNS. Dat laatste valt het hardst op, want de gegenereerde clientconfiguratie zet de DNS van de client op het tunneladres van de router.
Bij IKEv2 of L2TP: de policy dekt je LAN niet
Daar bepaalt de client wat er door de tunnel mag. Controleer /ip ipsec policy print op een dynamische regel waarin jouw LAN aan de bestemmingskant staat, en /ip ipsec active-peers print op een actieve sessie.
Wat de configurator hiervan weet
In het onderdeel WireGuard maak je een interface met een tunneladres, een UDP-poort, de schakelaar Tunnel telt als LAN (standaard aan) en de peers. Voor een road-warrior peer genereert de tool het sleutelpaar en schrijft hij een complete clientconfiguratie als extra bestand naast het script, inclusief Endpoint, DNS en AllowedIPs.
Die schakelaar Tunnel telt als LAN doet precies één ding: de WireGuard-interface wordt lid van de interfacelijst LAN. Dat is wat je toegang geeft tot de router zelf. Het verkeer naar apparaten achter de router loopt ook zonder die schakelaar, want de afsluitende drop in de forward-keten kijkt naar de WAN-lijst, niet naar de LAN-lijst. Goed om te weten als je zoekt waarom het half werkt.
De firewall krijgt automatisch een regel die de UDP-poort van elke WireGuard-interface binnenlaat. De VLAN-matrix maakt hier niets stuk: die regels staan allemaal met in-interface op een VLAN, dus ze matchen nooit op verkeer dat uit een tunnel komt. Een geïsoleerd gast-VLAN is vanaf de VPN dus gewoon bereikbaar, of je dat nu wilde of niet.
Wat de tool niet doet: de VLAN-subnetten in AllowedIPs zetten, het VPN-verkeer naar het LAN NATten, routes naar een IKEv2-client duwen buiten de mode-config om, controleren of jouw LAN-bereik botst met het netwerk waar de client toevallig zit, en iets aanraken op de client zelf. Die laatste twee zijn samen de meeste gevallen.
Als het niet aan je router ligt
Het café-wifi, het mobiele netwerk of het gastnetwerk waar je client op zit kan UDP blokkeren of subnetten hergebruiken. De VPN-app op de telefoon heeft zijn eigen routelijst. En het apparaat dat je probeert te bereiken heeft een eigen firewall die je vanaf de router niet ziet.
Verder lezen: WireGuard, VPN voor thuiswerken en Adressen plannen.