WireGuard misroutes some IPv6 subnets to the wrong peer

RouterOS RouterOS beta
1 
# sep/18/2022 20:56:14 by RouterOS 7.6beta6
# software id = C0G8-ZJRZ
#
# model = RouterBOARD D52G-5HacD2HnD-TC
# serial number = ...
/interface wireguard
add listen-port=51820 mtu=1420 name=myvpn
/interface wireguard peers
add allowed-address=fd07:a3d6:156f:1::/64 comment=wrench interface=myvpn public-key=\
    "..."
add allowed-address=fd07:a3d6:156f:3::2/128 comment=sixty-four endpoint-address="" interface=myvpn public-key=\
    "..."
add allowed-address=fd07:a3d6:156f:3::3/128 comment=sweet interface=myvpn public-key=\
    "..."

For some reason, apparently, all packets destined to fd07:a3d6:156f:1::/96 (that is, from fd07:a3d6:156f:1::0000:0000 to fd07:a3d6:156f:1::ffff:ffff) are routed to the last peer (named sweet), even though it should be routed to wrench. Packets to fd07:a3d6:156f:1:0:1:0:1, for example, are correctly routed to wrench.

I made this conclusion because whenever I try to send a packet to fd07:a3d6:156f:1::/96, tx counter for sweet increases, as if MikroTik tries to do a handshake with that peer. Handshake eventually fails though, and WireGuard interface tx drop counter increases.

Also, disabling sweet “fixes” the problem, and packets start to get routed to wrench correctly for all destination addresses.

I had this problem with 7.5, and 7.6beta6 hasn’t changed anything.

2

yay, another topic for the same issue…
http://forum.mikrotik.com/t/no-concurrent-ipv6-for-wireguard-peers-bug-still-in-7-4beta2/157296/1

3

Perhaps that issue is related, but in my case, it’s more complicated than “the last changed peer works”.

4

Sure, same bug though.

5

cancel ipv6 :slight_smile:

6

It got finally fixed in 7.10! (currently in beta)

*) wireguard - fixed IPv6 traffic processing with multiple peers;