V7.24 WireGuard peer is never reinstalled into the data plane after disable/enable

RouterOS General
1

Router: RB5009UPr+S+ (arm64), RouterOS 7.24 (stable, build 2026-08-14)

Summary:
After upgrading to 7.24, a WireGuard peer that is disabled and then re-enabled
is never reinstalled into the WireGuard data plane. The peer shows as enabled
in the configuration and has no inactive flag, but it behaves as if it does
not exist: no handshake initiations are ever sent for it. The only way to
recover is to remove the peer and re-create it with identical settings.

Setup:

  • Single wireguard interface (listen-port 15200) with 4 peers: two
    road-warrior peers (no endpoint) and one site-to-site peer with
    endpoint-address set to a DNS name, endpoint-port 51820,
    persistent-keepalive 25s, and multiple allowed-address subnets.
  • The site-to-site peer worked correctly before the upgrade.

Symptoms while the peer is in the broken state:

  • Peer prints as enabled (no X flag, no inactive reason shown).

  • current-endpoint-address stays empty even though the DNS name resolves
    fine with :resolve.

  • rx=0 tx=0 forever; not a single handshake initiation is sent (verified
    with /tool/sniffer filtered on the endpoint IP: zero packets in either
    direction). Other peers on the same interface keep working normally.

  • Pinging any destination inside the peer's allowed-address returns
    "126 (No error information)" (errno 126 = ENOKEY, "Required key not
    available"), i.e. the kernel has no peer owning those allowed IPs.

  • Log shows no errors for this peer at all (other peers log normal
    handshake retries).

  • At one point the peer briefly displayed the inactive reason
    "allowed-address match other peers", although its allowed-address does
    not overlap with any other peer on the interface. This reason seems
    spurious/stale.

  • What does NOT fix it:

    • Toggling the peer (disable + enable).
    • Disabling and re-enabling the wireguard interface.
    • Changing any peer property (endpoint to a literal IP, reducing
      allowed-address to a single subnet, clearing client-* fields,
      clearing peer private-key) followed by re-enable.
    • Disabling other peers on the interface.

    What DOES fix it:

    • /interface/wireguard/peers/remove the peer, then add it again with the
      exact same settings. The new entry immediately resolves the endpoint,
      sends a handshake, and passes traffic.

    Reproduction (100% on this router):

    1. Take a working peer with endpoint-address + persistent-keepalive set.
    2. Disable it, then enable it.
    3. The peer never sends another handshake; traffic to its allowed-address
      networks fails with errno 126. Only remove + re-add recovers it.
2

Kudos on the really detailed post, not only you stated your problem, you stated what doesn't fix it and what does fix it and the reproduction steps. :clap:

That's how it should be done, i would send this to their support via Jira. Hopefully they could get it resolved in the next stable release thanks for the info.

3

Wireshark or similar used?

4

Aie! That is the reason i have some problems with WG peer.
So i'll downgrade and restore last conf.

5

Great post and detail, I can reproduce this. Going to open a ticket

I also found changing a property such as endpoint port, gets it going again.

6

Just out of curiosity, does restarting the router fix it?

7

Yes, a reboot does fix it for me. I can reproduce this on an RB5009UG+S+ running RouterOS 7.24.

I have two WireGuard interfaces configured as separate VPN profiles. When switching profiles by disabling one peer/interface and enabling the other, the newly enabled peer sometimes remains stuck in this state:

Interface shows R / running

Peer is enabled, current-endpoint-address="", current-endpoint-port=0, rx=0, tx=0

No handshake occurs

The routing table, NAT, routing rule and firewall configuration are all correct. Flushing connection tracking does not help:

/ip/firewall/connection/remove [find]

Disabling/re-enabling the WireGuard peer also does not help, and neither does disabling/re-enabling the WireGuard interface.

A full router reboot immediately restores the peer and it starts handshaking normally.

However, I found that the following workaround also restores the peer without rebooting:

/interface/wireguard/peers/set [find name="peer1"] responder=yes

followed by:

/interface/wireguard/peers/set [find name="peer1"] responder=no

Immediately after toggling responder, the peer starts transmitting/receiving and the WireGuard tunnel comes back up.

So this appears to be a WireGuard peer/data-plane state issue in RouterOS 7.24 rather than a routing or conntrack problem.

8

Exact same issue!

Up to 7.24 I had the script below running all 10 minutes to fix 'stuck' wireguard peers unable to connect after changing the IP address (mostly mobile road warriors):slight_smile:

/interface/wireguard/peers/disable [/interface/wireguard/peers/find where last-handshake>5m and disabled=no]
delay 5s
/interface/wireguard/peers/enable [/interface/wireguard/peers/find where last-handshake>5m and disabled=yes]

Result after 7.24 - peers don't manage to reconnect at all. Only fix is a reboot of the WG-Server.

I realy would love to understand what causes some peers being unable to reconnect after an ip or port change from time to time. Only peers running RouterOS seem to be affected.

Peers in Linux or Android immediately reconnect no issue after an IP or Port change.

And it is not the Mikrotik Peer causing the issue, it is definitely the Mikrotik WG Server as disabling / enabling the peer on the server immediately solved the issue up to before 7.24

-Benoît-

9

Hi

I just attempted toggling the 'responder' flag at a peer and if that was not a coincidence, this re-activated that stuck peer.

10

Hey, i can confirm - i have the same issue, lost half day debugging. Rebooting helps until i change gw - then it repeats.

11

In RouterOS 7.24 a WireGuard peer that is disabled and re-enabled is not properly reinstalled into the data plane, so it shows as active but never initiates a handshake and traffic fails with ENOKEY. The quickest non-destructive fix is to toggle the responder flag:
/interface/wireguard/peers/set [find name="peer-name"] responder=yes
then immediately set it back to responder=no.
This forces the peer back into the data plane without a reboot or remove/re-add.

12 
What's new in 7.24.1 (2026-Aug-21 16:06)
 
[...]

*) wireguard - fix peer disable/enable state handling, which could leave the tunnel non-functional (introduced in v7.24);
*) wireguard - fix private key handling, including empty private keys;
13

Does the wireguard problem still or not exists in 7.24.1 ?

I have upgraded to the 7.24.1 and directly after this upgrade the wireguard client worked but on the next day it stoped working . Client connects but no rx date in wireguard on client sends.

14

Mikrotik Hap ax2, RouterOS 7.24.1
I cannot get out primary wireguard provider up and running again, after upgrading to 7.24.1, I even removed the entire configuration, generated new server config and re-created from scratch - Thus it still receives no packages.
However, I got another wireguard provider up and running, first shot :slight_smile:

15

All mine seem ok.

16

I have also problem with ax2 as wireguard client.

It can connect, sends data but not recive any data.

Of course the latest firmware build.