Manual

WireGuard never completes a handshake

No handshake ever arrives. WireGuard says nothing, so you have to work from the outside in yourself.

The tunnel never comes up. The client keeps trying, the peer on the router shows no handshake at all, and there is no error message. That silence is by design: WireGuard does not answer traffic it does not trust, so a wrong key and a closed port look exactly the same from outside.

If the handshake does happen and nothing passes afterwards, this is the wrong chapter: read The VPN connects but nothing passes.

The quick checks, in this order

  1. What does the peer say? /interface wireguard peers print detail. A good answer: last-handshake a couple of minutes ago at most, with rx and tx climbing. An empty last-handshake means there has never been contact.
  2. Does the interface have a key and a port? /interface wireguard print. A good answer: a private-key and the listen-port you expect, 13231 by default.
  3. Is anything arriving on that port? /tool torch interface=ether1 port=13231 while the client tries to connect. A good answer: UDP packets from your client's address. Nothing there means the traffic never reaches your router and no amount of key checking will help.
  4. Does the firewall allow it? /ip firewall filter print stats. A good answer: the accept rule commented WireGuard wg-rw has a climbing counter.
  5. Is the endpoint right? Look at the Endpoint line in the client configuration. A good answer: an address or name that points at your router right now, with the right port behind it. Check what your public address really is with /ip cloud print.
  6. Do the keys match? The public key in the peer on the router belongs to the private key on the client, and the other way round. Compare them character by character; swapping them is easier than it sounds.

The usual causes

  • The UDP port never arrives. With another router in front, the handshake stops there. See Behind two routers. Behind CGNAT nothing can arrive at all and the tunnel has to be started from your side.
  • The public keys are swapped. In a tunnel between two routers you enter the public key of the other side at each end. Put your own public key in your own peer and nothing happens and nobody says anything.
  • The endpoint is stale. A dynamic address changed, or the DDNS name still points at yesterday. Switch on IP Cloud DDNS in the Management access section and use the mynetname.net name as the endpoint.
  • Neither side dials. In a tunnel between two routers at least one side needs an endpoint filled in. With neither, both sit waiting.
  • The router's clock was in the future. WireGuard tracks how recent a handshake is. If the far end once saw a handshake with a much later time, it refuses older ones even with correct keys. Fix the time and restart the peer at the other end.
  • The keys were never generated. RouterOS then makes its own, and the public key in your client configuration no longer matches what is on the router.

What the configurator does about it

The keys are made in your own browser and never leave your computer. If that fails, in a browser without X25519 for instance, the site check on the tunnel says the keys are missing and that you should create the tunnel again in a browser that can. A peer without a public key is a separate warning.

Draw a WireGuard tunnel between two routers on the network board with no public address on either and that is an error: WireGuard does not know where to connect. Fill in the public IP or DNS name on at least one router. For the other tunnel types the requirement is stricter: they want an IP address and not a name, and the tool says so.

The firewall rule for the UDP port of every WireGuard interface is generated for you, so there is nothing to do there. Leave the public address or hostname empty while road-warrior peers exist and the client configurations get a placeholder, with a warning about it.

What the tool cannot do: check that your port is really reachable from outside, that your clock is right, or that the key on the far side is the correct one. All three only become apparent once the device is on the line.

When it is not your router

  • The client's network blocks UDP. Many guest networks pass TCP on 80 and 443 and nothing else. Test on mobile data.
  • The provider filters. Rare, but it happens on mobile subscriptions.
  • The client's clock. A phone with the wrong date gives the same picture as a router with the wrong clock. See System and time.

Further reading: WireGuard, Site to site tunnels and Dynamic DNS.

Want to try it right away? Open the configurator