Wireguard no connect

RouterOS
1

I have a Wireguard server built on Linux Debian 12. Wireguard runs on a public dynamic IP address using the dynamis DNS server (noip.com).
There are 2x Mikrotik L009UiGS-2HaxD on different (WAN) branches.
Wireguard peer has been running on both Mikrotiks for a long time and everything works very well.
Wireguard server has been rebooted in the past and Mikrotiks connected without any problems.
Today I had to reboot the server (wireguard) again. The IP address was updated immediately, but both Mikrotiks are unavailable.

Fortunately, I have a PC on one branch where I connected via RustDesk and I saw Mikrotik in the log, every 5 seconds.
wireguard1: [peer2] 8K3g5zocezxxxxxxxxxxxxxxxxxxp7jT6UFpIVA=: Handshake for peer did not complete after 5 seconds, retrying (try 2)

I tried disabling/enabling peer, but it did not solve the problem.

On the peer, I saw that the current endpoint is fine (new, updated IP).

I rebooted Mikrotik and WG immediately connected to the server and works great.

There is no PC on the other branch and I assume that there will be a similar problem there.

AI advised me, among other things,
you need to "starve" connection tracking from the server side:

Complete silence (3 - 5 minutes): Turn off the WireGuard service on your server or completely block incoming communication from the MikroTik IP address on the server's firewall.

Why 5 minutes? You have to wait longer than the longest possible udp-stream-timeout (180s). Even though MikroTik will still send packets if the server doesn't respond at all, after a certain amount of time (depending on the RouterOS version) the system should consider the connection dead and try to re-initialize (which should also include re-processing the destination IP from DNS).

So I blocked the UDP port to the servers for 10 minutes. But it didn't help at all.

I'll be at the branch in 2 days. :face_exhaling:

EDIT:

I just did a full backup of the container (about 1 minute) and after starting the container the Mikrotik WG connected.
This means that maybe it was enough to turn off/on the container

:folded_hands:

2

Hi,

Therefore the simple conslusion is to always restart services on both ends because of TIMEOUTS.

3

Yes, this is the first rule if something doesn't work.
However, many times you have no connection with the other party.

4

That's what scripts are for.

5

I don't know what scripts you mean.
For example, reboot every night?

6

Yes, or check in netwatch script if you can ping other side of the tunnel.
If not, then in "Down" section disable/enable ( restart) the needed services or interfaces.

image
image510×478 24.4 KB