Because of the allowed-address.
Let us know if it works after you clean it up!
I set the allowed-address of all peers on that Wireguard interface to the proper /32 and /128. Otherwise the same config as above.
This did not change anything for me. Still only the last modified/enabled client works over IPv6.
Test setup:
Windows notebook, Wireguard client running.
Continuously running ICMP pings to the IPv4 and v6 address of the WG interface.
IPv4 always works, IPv6 only if it is the last one that was modified. As soon as I disable/enable another peer (thus the peer for the test device is not the last-modified one) IPv6 ping times out.
(same behavior with Android clients as well)
Edit: @borr is also reporting the same with their config in the v7.1.3 release thread: http://forum.mikrotik.com/t/v7-1-3-is-released/156021/1
Yeah same, I tried to change some stuff around too but the problem persists even with 7.1.3.
Same: 7.1.3 on an RB4011 (arm) and only the last one enabled is working. I figured it was some internal firewall tracking issue. I have limited firewall rules, so I know its not what I might be doing there. ![]()
EDIT: Looks like it will be fixed in 7.2rc4?
*) wireguard - fixed IPv6 traffic processing with multiple peers;
EDIT: Version 7.2rc4 doesnât seem to have fixed it. It still only seems to work with whatever the last enabled peer was. ![]()
Just wanted to say thank you, thank you, thank you for this. This bug is still around in 2025, on 7.17.2. I was so skeptical that just toggling âenabledâ on a peer would fix it, but thatâs really all it took.
Actually, I didnât read this whole thread carefully enough, and discovered that Iâm experiencing the same problem as everyone else: only one Wireguard peer (the one most recently marked âEnabledâ) can connect over IPv6 at a time. This is in the latest stable RouterOS (7.18.2), over three and a half years since this thread was originally posted.
Can someone at Mikrotik comment on the status of this issue? Many thanks for all your hard work and community engagement.
Itâs probably a misconfiguration from your side (there is no bug). You may check whether you have overlapping address ranges between your peersâ Allow Addresses values. Thatâs a common mistake.
You may check whether you have overlapping address ranges between your peersâ Allow Addresses values. Thatâs a common mistake.
I stand corrected; that was absolutely it. Thanks for the speedy reply, and sorry for the radio silence.
Not sure if this will help anyone else, but my problem was that I specified a broad subnet on the âAllowed Addressesâ config option for each wireguard peer in ROS (and in some cases, on the âAddressâ config option of the wg interface on the peer itself). So, for instance, I had /64 in all of the lines below instead of /128:
> /interface/wireguard/peers/print
Columns: INTERFACE, PUBLIC-KEY, ENDPOINT-PORT, ALLOWED-ADDRESS
# INTERFACE PUBLIC-KEY ENDPOINT-PORT ALLOWED-ADDRESS
0 wg1 <REDACTED> 0 192.168.2.2/32 fd2a:959b:fa76:e8ff:9104:bac9:e89d:cda8/64
1 wg1 <REDACTED> 0 192.168.2.3/32 fd2a:959b:fa76:7c75:1e04:0ad8:5e60:c773/64
2 wg1 <REDACTED> 0 192.168.2.4/32 fd2a:959b:fa76:014b:273d:5f6e:18f8:e325/64
Thatâs why everything worked for IPv4 but not IPv6, and why cycling any given peer off and on caused it to work and others to fail. Switching those subnets to /128 indeed fixed the problem.