I have configured wireguards on two mikrotiks, one as a server and the otehr as a client.
The Client is on a dynamic IP and everytime the client goes offline, the server is not picking the new IP after the client has booted up.

The tunnel is only coming back to life if I didable the tunnel on the mikrotik (server side)

Kindly assist on how best I can resolve this problem.

Check on client peer side if Persistent Keepalive is set (typical: set it to 25s = 00:00:25).

The Server does not pickup the new address, its the client that has to establish the handshake, well if there is a certain gap in time anyway.
Post both full configs to see what may be causing the issue.

/export file=anynameyouwish (minus router serial number, any public WANIP information, vpn keys etc.)

i had a similar problem with WG client config on mikrotik router with VPN provider where when my WAN IP changed (sometimes it is a private ip given out by ISP modem DHCP for short duration before a public IP(passthrough) is provided by ISP fiber modem). WG client connections which are relatively idle cannot connect again to VPN provider even though default route is valid and working(disabling WG does not work. router has to be rebooted). the active connection WG clients (data being sent in the tunnel) seem to work.

what i tried:
tried increasing firewall udp-timeout to 30 since persistent keep alive was 25s. did not help much.
now, i have a DHCP Client script which will disable wireguard if the WAN IP is private and enable it when WANIP is public IP so that WG clients always deal with public IP.

teleport is this still an issue with 7.16.2?
timing issues were resolved to my knowledge and if not we should know about it and report to Mikrotik to fix.

yes am on latest stable 7.16.2 and have support request open. my case may be a bit different in the sense that a private WAN ip comes in the mix which breaks tunnel(non internet rout-able) and mikrotik WG client does not reconnect once public WAN IP is assigned.

Hi Colleagues

I tried the solutions which you had mentioned here but still the problem is occuring. However, I tried to set up a scheduler to be refreshing wireguard interface by disabling and enabling it within 2 seconds. Still more this is working on some of the peers but not the rest.

so I wanted your help on how I can set up my scheduler to be disabling and enabling the actual peers for 2 seconds every 1 hour just to check if the IP has chanfed on the client side. since the problem is that everytime the mikrotik on the client side goes offline, the server is not renewing the same.

below is the command that I have typed manually and I would want to put it into a scrip or scheduler. so I need someone to type the command for me so that I can add it to the scheduler.

[admin@Wireguard-VPN-Concentrator] > interface/wireguard/peers/disable 0

You still have not posted both configs...

Hi all

I just wanted to add that I've been suffering the same or a very similar issue.

My configuration is:

• Android telephone with Wireguard client

• RouterOS 7.18.2 (stable) - recently upgraded. I used to have an older version

My issue is that, sometimes, a configured tunnel suddenly stops working without doing any configuration change.

When the issue occurs, the tunnel appears to be up, and I can see regular handshakes, but only few bytes appear as transferred.

I tried to configure the same tunnel with "WG Tunnel" app instead of the official Wireguard app, but the problem persisted.

I also tried to upgrade the Mikrotik routerOS and restart the router, but the tunnel was still not working.


Until now, my workaround was to create a new tunnel or to update the keys of the tunnel, but today I've discovered that it's enough with going to the Mikrotik router, disable the tunnel and enable it again. After doing that, the tunnel magically works again.

There is a responder checkbox in winbox I think, try checking that, and see if the issue persists.
.........

There is a responder checkbox in winbox I think, try checking that, and see if the issue persists.
.........
Screenshot 2025-03-29 212138.png

Thanks, I didn't know about this option.

Indeed, looking at the documentation, it seems like I should check it for my use case:

responder (yes | no; Default: no)
Specifies if peer is intended to be connection initiator or only responder. Should be used on WireGuard devices that are used as "servers" for other devices as clients to connect to. Otherwise router will all repeatedly try to connect "endpoint-address" or "current-endpoint-address".

I've checked it for all my tunnels. Immediately after doing it, they stopped working. After some disabling and enabling the tunnels in the router, they are working again now. We will see...