WireGuard doet geen handshake

De tunnel komt niet tot stand. De client blijft proberen, de peer op de router laat geen enkele handshake zien, en er is geen foutmelding. Dat laatste hoort erbij: WireGuard antwoordt niet op verkeer dat het niet vertrouwt, dus een verkeerde sleutel en een gesloten poort zien er van buiten hetzelfde uit.

Komt de handshake wel en gaat er daarna niets doorheen, dan is dit het verkeerde hoofdstuk: lees VPN verbindt, maar er gaat niets doorheen.

De snelle controles, in deze volgorde

1. Wat zegt de peer? /interface wireguard peers print detail. Goed antwoord: last-handshake met een tijd van hooguit een paar minuten geleden, en rx en tx die oplopen. Een leeg last-handshake betekent dat er nog nooit contact is geweest.
2. Heeft de interface een sleutel en een poort? /interface wireguard print. Goed antwoord: een private-key en de listen-port die je verwacht, standaard 13231.
3. Komt er iets binnen op die poort? /tool torch interface=ether1 port=13231 terwijl de client probeert te verbinden. Goed antwoord: UDP-pakketten vanaf het adres van je client. Zie je niets, dan komt het verkeer niet eens bij je router en heeft sleutelwerk geen zin.
4. Laat de firewall het toe? /ip firewall filter print stats. Goed antwoord: de accept-regel met de opmerking WireGuard wg-rw heeft een teller die oploopt.
5. Klopt het endpoint? Kijk in de clientconfiguratie naar de regel Endpoint. Goed antwoord: een adres of naam die op dit moment naar je router wijst, met de goede poort erachter. Controleer met /ip cloud print wat je publieke adres werkelijk is.
6. Passen de sleutels bij elkaar? De public key in de peer op de router hoort bij de private key op de client, en andersom. Vergelijk ze teken voor teken; verwisselen is makkelijker dan het lijkt.

De gewone oorzaken

• De UDP-poort komt niet binnen. Zit er nog een router voor je, dan stopt de handshake daar. Zie Twee routers achter elkaar. Zit je achter CGNAT, dan kan er helemaal niets binnenkomen en moet de tunnel vanaf jouw kant worden opgezet.
• De public keys zijn verwisseld. Bij een tunnel tussen twee routers voer je aan elke kant de public key van de andere kant in. Zet je per ongeluk je eigen public key in je eigen peer, dan gebeurt er niets en zegt niemand iets.
• Het endpoint klopt niet meer. Een dynamisch adres is veranderd, of de DDNS-naam wijst nog naar gisteren. Zet IP Cloud DDNS aan in het onderdeel Beheertoegang en gebruik de mynetname.net-naam als endpoint.
• Geen van beide kanten belt. Bij een tunnel tussen twee routers moet minstens één kant een endpoint hebben ingevuld. Hebben ze allebei niets, dan wacht iedereen.
• De klok van de router stond in de toekomst. WireGuard houdt bij hoe nieuw een handshake is. Heeft de andere kant ooit een handshake met een veel latere tijd gezien, dan weigert hij oudere, ook al kloppen de sleutels. Zet de tijd goed en herstart de peer aan de andere kant.
• De sleutels zijn niet gegenereerd. Dan maakt RouterOS er zelf een, en klopt de public key in je clientconfiguratie niet met wat er op de router staat.

Wat de configurator hiervan weet

De sleutels worden in je eigen browser gemaakt en verlaten je computer niet. Lukt dat niet, bijvoorbeeld in een browser zonder X25519, dan zegt de sitecontrole bij de tunnel dat de sleutels ontbreken en dat je de tunnel opnieuw moet maken in een browser die het wel kan. Ontbreekt op een peer de public key, dan is dat een aparte waarschuwing.

Teken je op het netwerkbord een WireGuard-tunnel tussen twee routers en heeft geen van beide een publiek adres ingevuld, dan is dat een fout: WireGuard weet niet waar het heen moet. Vul bij minstens één router het publieke IP of de DNS-naam in. Voor de andere tunnelsoorten is de eis strenger: die willen een IP-adres en geen naam, en dat zegt de tool er ook bij.

De firewallregel voor de UDP-poort van elke WireGuard-interface wordt automatisch meegegeven, dus daar hoef je niets voor te doen. Vul je geen publiek adres of hostnaam in terwijl er road-warrior peers zijn, dan komt er een plaatshouder in de clientconfiguraties en waarschuwt de tool daarover.

Wat de tool niet kan: controleren of je poort van buiten werkelijk bereikbaar is, of je klok klopt, of de sleutel aan de overkant de goede is. Dat zijn alle drie dingen die pas blijken als het apparaat aan de lijn hangt.

Als het niet aan je router ligt

• Het netwerk van de client blokkeert UDP. Veel gastennetwerken laten alleen TCP op 80 en 443 door. Test met mobiele data.
• De provider filtert. Zeldzaam, maar bij mobiele abonnementen komt het voor.
• De klok van de client. Een telefoon met een verkeerd ingestelde datum geeft hetzelfde beeld als een router met een verkeerde klok. Zie Systeem en tijd.

Verder lezen: WireGuard, Tunnels tussen locaties en Dynamische DNS.