Comments on The frustrating RouterOS–WireGuard VPN peering bug

Be civil and read the entire article first. This is not a support forum. Comments from new contributors are moderated. English only.

Leave a comment

Required. Optional. E.g. your homepage, Twitter. or Email required unless anonymous. Not published or shared. Reuse to be recognized as the same commenter.
Plain-text only. Begin lines with a > character to quote.

All VPNs are hard to debug, specially on an appliance unlike a Linux or BSD host. That said, Mikrotik’s response time for fixing the bug is remarkably good compared to the apathy of Ubiquiti.


Thanks for the time to troubleshoot and send the bug report to MT.


Looks like this bug still persists in RouterOS 7.6 when restoring from a backup. After struggling to figure out why my Wireguard clients couldn't connect after restoring from backup, I stumbled upon your blog post. And sure enough an export of the config from the CLI showed that empty string was being used for endpoint-address! Do you have the ticket number for this bug with MikroTik? Do you want to add this to it? Or should I file a new issue?

Jacob, I didn’t receive a bug or ticket number from MikroTik. The web UI works for me now. Was the issue present in your exported backup?


I did not export a CLI dump, but only had a saved binary config database that I restored. I have submitted ticket SUP-99349 with the following content:

I was using RouterOS 7.6 and the hAP ac2 locked up and wouldn’t recover after power cycle. I cleared the configuration and restored from backup of the same version already on the NAND.

Upon restore of the database, my Wireguard peers could not connect. After some searching I can across this blog article[1] that referred to an issue in WebFig where the endpoint-address parameter saved an empty string instead of null, and therefore disabled incoming connections as an empty string IP address is not possible.

Sure enough, with /interface/wireguard/peers export I saw endpoint-address="" on my peer definitions. In Winbox there was also no indication that this parameter was set to empty string. I clicked the down arrow on the parameter (add), and then the up arrow on the parameter (remove), and saved. This fixed the problem by unsetting the parameter. I suppose this would also have been fixed for all of my peering connections from the CLI with /interface/wireguard/peers set [find] !endpoint-address.

The blogger stated it was fixed in 7.6, but apparently wasn’t, or at least the database restore wasn’t fixed for this parameter.

Please fix this with the database restore operation. Thanks!



hi here thanks for this article that shows the fast reaction speed of mikrotik. I use wireguard on a 2004 router that still not so easy to configure but works very well


Thanks for this post! Saved me from many more hours of troubleshooting...

OMG thankyou for posting this, I had so much trouble trying to debug the connection on my WG connection, I kept seeing RX errors on a peer and no traffic passing, as soon as I enabled and disabled the "Endpoint" settings in Winbox (Port had a 1 in it when I enabled it for some reason) traffic started passing again.

My MT has only ever been configured using winbox and is currently on 7.7 for anyone interested.


It seems to me that if an endpoint address is set on both peers, then the peers will refuse a handshake from address different that that.

This is not conformant to WireGuard's standard implementation, which instead supports roaming by design. It makes failover much more complicated, as you need to set up multiple peers, and then dynamically switch the allowed IPs from over one to the other.

It doesn't look like this is documented anywhere.

Has anyone else observed this behaviour?