no concurrent IPv6 for wireguard peers, bug still in 7.4beta2

borr · Wed Apr 13, 2022 12:49 am

There is no concurrent IPv6 connection for wireguard peers after 7.1rc4 routeros version, support ticket SUP-78547, tested on hap ac^2, hap ac and hex.

While IPv4 for wireguard peers working as they should (peers are able to connect to each other, LAN and WAN via default route).
You have to reenter IPv6 address via winbox or terminal for specified peer and then only this peer gains IPv6 connectivity.
LAN clients get IPv4 from DHCP and IPv6 from RA, and for them everything is fine.

/interface wireguard
add listen-port=443 mtu=1420 name=ep3 private-key="..."
add listen-port=63016 mtu=1420 name=njalla private-key="..."

/interface wireguard peers
add allowed-address=0.0.0.0/0,::/0 endpoint-address=198.167.192.13 endpoint-port=51820 interface=njalla public-key="..."
add allowed-address=10.2.1.2/32,fd02:21::2/128 interface=ep3 public-key="..."
add allowed-address=10.2.1.3/32,fd02:21::3/128 interface=ep3 public-key="..."
add allowed-address=10.2.1.4/32,fd02:21::4/128 interface=ep3 public-key="..."

/ip address
add address=10.2.0.1/24 interface=lo1 network=10.2.0.0
add address=10.2.1.1/24 interface=ep3 network=10.2.1.0
add address=10.13.37.163/24 interface=njalla network=10.13.37.0

/ipv6 address
add address=fd02:20::1 interface=lo1
add address=fd02:21::1 interface=ep3
add address=fd03:1337::163/128 advertise=no interface=njalla

/ip dhcp-client
add add-default-route=no interface=eth1 use-peer-dns=no use-peer-ntp=no

/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=njalla passthrough=no protocol=tcp tcp-flags=syn

/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=njalla passthrough=no protocol=tcp tcp-flags=syn

/ip firewall nat
add action=src-nat chain=srcnat ipsec-policy=out,none out-interface=njalla to-addresses=10.13.37.163

/ipv6 firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=njalla

/ip route
add dst-address=0.0.0.0/0 gateway=njalla routing-table=main

/ipv6 route
add dst-address=2000::/3 gateway=njalla routing-table=main

/routing rule
add action=lookup-only-in-table disabled=no dst-address=0.0.0.0/0 table=main

Sob · Wed Apr 13, 2022 2:51 am

No matter what I do, it works. Tested with CHR 7.1.5 and 7.2.1, one server and two connected clients (one another CHR and second Windows). Only problem I see is that sometimes info for peer (rx, tx, last handshake) gets stuck. It seems random. But traffic in tunnel is flowing.

jookraw · Wed Apr 13, 2022 11:03 am

any reason to you still be on 7.1rc4?

this wireguard bug was introduced in this version (7.1rc4) and was fixed in the 7.2 stable and 7.1.3 stable.

What's new in 7.2 (2022-Mar-31 12:11):
...
*) wireguard - fixed IPv6 traffic processing with multiple peers;
...

What's new in 7.1.3 (2022-Feb-11 21:20):
...
*) wireguard - fixed IPv6 traffic processing with multiple peers;

borr · Wed Apr 13, 2022 11:26 am

any reason to you still be on 7.1rc4?

this wireguard bug was introduced in this version (7.1rc4) and was fixed in the 7.2 stable and 7.1.3 stable.
What's new in 7.2 (2022-Mar-31 12:11):
...
*) wireguard - fixed IPv6 traffic processing with multiple peers;
...

What's new in 7.1.3 (2022-Feb-11 21:20):
...
*) wireguard - fixed IPv6 traffic processing with multiple peers;

I’m on 7.2.1 right now. I mean the last version when concurrent IPv6 was possible is 7.1rc4. I’ve tested all versions after. And this was not fixed.

Wed Apr 13, 2022 12:17 pm

If you are sure it has nothing to do with the config itself

Export config.
Reset device to clean config
Reapply config being careful with what is already present as default.

borr · Wed Apr 13, 2022 12:19 pm

If you are sure it has nothing to do with the config itself

Export config.
Reset device to clean config
Reapply config being careful with what is already present as default.

Done this, even netinstalled. It does not work.

Added: on two devices: netinstall, no config, hap ac2 and hex.

Sob · Wed Apr 13, 2022 11:31 pm

One more test with three CHRs:

Server:

/interface wireguard
add listen-port=12345 mtu=1420 name=wg-server private-key="server-private-key"
/interface wireguard peers
add allowed-address=fd02:21::2/128 comment=client1 interface=wg-server public-key="client1-public-key"
add allowed-address=fd02:21::3/128 comment=client2 interface=wg-server public-key="client2-public-key"
/ipv6 address
add address=fd02:21::1/64 advertise=no interface=wg-server

Client1:

/interface wireguard
add listen-port=20183 mtu=1420 name=wg-client private-key="client1-private-key"
/interface wireguard peers
add allowed-address=fd02:21::/64 endpoint-address=<server-address> endpoint-port=12345 interface=wg-client public-key="server-public-key"
/ipv6 address
add address=fd02:21::2/64 advertise=no interface=wg-client

Client2:

/interface wireguard
add listen-port=20184 mtu=1420 name=wg-client private-key="client2-private-key"
/interface wireguard peers
add allowed-address=fd02:21::/64 endpoint-address=<server-address> endpoint-port=12345 interface=wg-client public-key="server-public-key"
/ipv6 address
add address=fd02:21::3/64 advertise=no interface=wg-client

It just works, any device can ping any other.

mboehn · Thu Apr 14, 2022 12:34 am

There is no concurrent IPv6 connection for wireguard peers after 7.1rc4 routeros version, support ticket SUP-78547, tested on hap ac^2, hap ac and hex.

I just tested this on a RB4011 running routeros 7.2 and I have the same experience. IPv4 works fine, but only the last added/updated/enabled peer gets IPv6.

[a@rb4011] /interface/wireguard/peers> print 
Flags: X - DISABLED
Columns: INTERFACE, PUBLIC-KEY, ENDPOINT-PORT, ALLOWED-ADDRESS
#   INTERFACE		PUBLIC-KEY                                    E		ALLOWED-ADDRESS         
0   WG			i.........................................I=  0		10.0.0.101/32
										2001:db8::101/128
1   WG			1.........................................0=  0		10.0.0.102/32
										2001:db8::102/128         
2   WG			j.........................................s=  0		10.0.0.103/32          
										2001:db8::103/128
3   WG			z.........................................w=  0		10.0.0.104/32          
										2001:db8::104/128
4   WG			p.........................................c=  0		10.0.0.105/32          
										2001:db8::105/128

# only 2001:db8::105 responds to ping
[a@rb4011] /interface/wireguard/peers> enable 0
# only 2001:db8::101 responds to ping
[a@rb4011] /interface/wireguard/peers> enable 1
# only 2001:db8::102 responds to ping
[a@rb4011] /interface/wireguard/peers> enable 2
# only 2001:db8::103 responds to ping
[a@rb4011] /interface/wireguard/peers> enable 3
# only 2001:db8::104 responds to ping
[a@rb4011] /interface/wireguard/peers> enable 4
# only 2001:db8::105 responds to ping

borr · Thu Apr 14, 2022 1:11 pm

Thank you Sob for this test.

What I've done: netinstalled my hex with new 7.3beta33 and added this config (there is no firewall, just allowing peers to connect and run ping tests to local fd02:21::1 and 10.2.1.1):
And still no IPv6 for peers simultaneously, only for one peer at the time, reentering ip in peer's allowed addresses enables IPv6 for this peer and disables it for the first one. IPv4 works as it should be.
I don't really get it. No ideas where is the mistake or some global missconfiguration of wireguard in my config.

export file=r1-20220414-1210 compact

/interface wireguard
add listen-port=443 mtu=1420 name=ep3
/interface wireguard peers
add allowed-address=fd02:21::2/128,10.2.1.2/32 interface=ep3 public-key=\
    "NFxnCJgrsp/o87nTEXlfyfYdzy5RpD7Ysdx0jzcpwGU="
add allowed-address=fd02:21::3/128,10.2.1.3/32 interface=ep3 public-key=\
    "I+ARcIESOKv8VFWciqwgq9YBHRYV45uGMSYsD70BqVE="
/interface bridge
add admin-mac=CC:2D:E0:0D:CA:06 arp=proxy-arp auto-mac=no name=lo1 \
    protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] name=eth1
set [ find default-name=ether2 ] name=eth2
set [ find default-name=ether3 ] name=eth3
set [ find default-name=ether4 ] name=eth4
set [ find default-name=ether5 ] name=eth5
/interface list
add name=all_input
add name=discovery
add name=mac-telnet
add name=mac-winbox
add name=local
add name=ospf_broadcast
add name=ospf_ptp
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip dhcp-server option
add code=43 name=netbios value=0x010400000002
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 lifetime=8h pfs-group=\
    none
/ip pool
add comment=64-127 name=dhcp ranges=10.2.0.64/26
add comment=64-127 name=remote ranges=10.2.1.64/26
/ip dhcp-server
add address-pool=dhcp authoritative=after-10sec-delay interface=lo1 \
    lease-time=1d name=dhcp
/port
set 0 name=serial0
/routing table
add disabled=no fib name=eth1
/interface bridge port
add bridge=lo1 ingress-filtering=no interface=eth2
add bridge=lo1 ingress-filtering=no interface=eth3
add bridge=lo1 ingress-filtering=no interface=eth4
add bridge=lo1 ingress-filtering=no interface=eth5
/ip address
add address=10.2.0.1/24 interface=lo1 network=10.2.0.0
add address=10.2.1.1/24 interface=ep3 network=10.2.1.0
/ip dhcp-client
add add-default-route=no interface=eth1 use-peer-dns=no use-peer-ntp=no
/ip dhcp-server network
add address=10.2.0.0/21 caps-manager=10.2.0.1 dhcp-option=netbios dns-server=\
    10.2.0.1 domain=idlehive.net gateway=10.2.0.1 netmask=21 ntp-server=\
    10.2.0.1
/ip dns
set allow-remote-requests=yes cache-max-ttl=1d servers=\
    95.215.19.53,2001:67c:2354:2::53
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=eth1 routing-table=main \
    suppress-hw-offload=no
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh port=32610
set api disabled=yes
set api-ssl disabled=yes
/ipv6 address
add address=fd02:20::1 interface=lo1
add address=fd02:21::1 interface=ep3
/ipv6 nd
set [ find default=yes ] dns=fd02:20::1
/system clock
set time-zone-name=Europe/Stockholm
/system identity
set name=r1
/system package update
set channel=testing

Config file for client 1:

[Interface]
PrivateKey = ...
Address = fd02:21::2/128, 10.2.1.2/32
DNS = 10.2.0.1

[Peer]
PublicKey = M8sxz8etMnVkwmjcsKhfC0tpIc2p4Dlatq/3KShPtys=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = server:443

Config file for client 2:

[Interface]
PrivateKey = ...
Address = fd02:21::3/128, 10.2.1.3/32
DNS = 10.2.0.1

[Peer]
PublicKey = M8sxz8etMnVkwmjcsKhfC0tpIc2p4Dlatq/3KShPtys=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = server:443

Sob · Fri Apr 15, 2022 2:29 am

You have additional config, but I don't see anything that could influence it. If you want to be sure, you could try bare-minimum config like mine (only additional thing needed would be one IP address for server, used by clients to connect to). But I don't think that's it. Next, devices listed in first post are three different architectures, so it shouldn't be that either.

Or you could try some logging and find out what exactly goes wrong, e.g.:

/ipv6 firewall mangle
add chain=prerouting in-interface=ep3 protocol=icmpv6 action=log
add chain=input in-interface=ep3 protocol=icmpv6 action=log
add chain=output out-interface=ep3 protocol=icmpv6 action=log
add chain=postrouting out-interface=ep3 protocol=icmpv6 action=log

Similarly, you can watch WG packets between clients. And also on the other side, if current OS is something that allows to sniff packets. If not, add another RouterOS client for testing. I can't say if it will lead to anything useful, but for the lack of better ideas...

foxx1337 · Sat Apr 16, 2022 1:04 am

I'm having the same problem with 7.1.5, 7.2 and 7.2.1 on hAP ac3.

rplant · Tue Apr 19, 2022 10:05 am

Hi,

/ipv6 address
add address=fd02:21::1 interface=ep3

Should perhaps be
/ipv6 address
add address=fd02:21::1/112 (maybe /120 or /124...) interface=ep3

Sob · Tue Apr 19, 2022 8:08 pm

It's problem with export, it omits mask when it's /64.

With IPv4 it's more logical, it omits /32 and it doesn't matter, because /32 is single address. But with IPv6 it shows /128, which could be safely omitted, but doesn't show /64, which can be confusing. It should be either made the same as with IPv4, or always show all masks.

Znevna · Tue Apr 19, 2022 8:57 pm

I can't understand why for some folks it works and for some it doesn't (worksforme).
Did you try to rebuild the wireguard config from scratch?

yverry · Fri Apr 22, 2022 7:34 pm

Same problem here, stucked in v7.1rc4
Could you try without any change with this version to confirm this issue ?

borr · Fri Apr 22, 2022 9:07 pm

Same problem here, stucked in v7.1rc4
Could you try without any change with this version to confirm this issue ?

I’ve told that in the first post. From 7.1rc5 version concurrent ipv6 connectivity for wireguard peers stop working. Last working version for me is 7.1rc4.

chewie198 · Sat Apr 23, 2022 7:32 am

I'm seeing the same issue on 7.3 beta 35. And no, that isn't a typo, I'm testing a private beta with support to iron out a CPU consumption bug. Have you heard anything back from support on your ticket? I'm unsure if opening my own ticket for this would be helpful since it seems like it would just be closed as a duplicate, but on the other hand, maybe it would help raise the priority of this issue. I'm not very familiar with the internal QA process at Mikrotik. If anyone has any constructive insight into the process it would be appreciated.

Znevna · Sat Apr 23, 2022 8:45 am

I've asked above too.
DID YOU TRY TO REBUILD THE WIREGUARD CONFIG FROM SRATCH?

borr · Sat Apr 23, 2022 10:56 am

I'm seeing the same issue on 7.3 beta 35. And no, that isn't a typo, I'm testing a private beta with support to iron out a CPU consumption bug. Have you heard anything back from support on your ticket? I'm unsure if opening my own ticket for this would be helpful since it seems like it would just be closed as a duplicate, but on the other hand, maybe it would help raise the priority of this issue. I'm not very familiar with the internal QA process at Mikrotik. If anyone has any constructive insight into the process it would be appreciated.

There is no replays after they said that they are not able to reproduce it on a similar configuration. I’ve send them some details, config exports, supout.rif files, repeat it after new ros version. And still no replay from them after. So I just stop posting to support and started post here.

Yes, I’ve tried rebuilding wireguard config from the scratch. Actually it were my first thoughts. But for me the only working solution to this bug is just to downgrade straight to 7.1rc4 and everything is starting to work without any doing from me (resetting the config, downgrading and importing config).

yverry · Sat Apr 23, 2022 6:44 pm

Yup and like me you try each beta/rc/stable version if that solve the problem.
From my side I run ipv6 only on wireguard.

I've re-read the whole post and we are in the same situation, just waiting next release and burning a candle ...

npeca75 · Sun Apr 24, 2022 12:49 am

hi to all

since 7.1.5 works for me
12 total WG peer
9 MT
3 ubuntu
hub is CHR/esxi
whole NMS is on pure IPv6
total of 98 device behind 9 MT

so it is stable and reliable

yverry · Sun Apr 24, 2022 11:34 am

Hi,

Nice to ear. Could you post piece of your config?
I guess we do WireGuard in other way than you. For example one interface per tunnel?

Thanks

npeca75 · Sun Apr 24, 2022 8:02 pm

Hi,

Nice to ear. Could you post piece of your config?
I guess we do WireGuard in other way than you. For example one interface per tunnel?

Thanks

Sorry to disappoint you, but, after all, you are right, sort of ...
out of curiosity, i tested same config transfered to RB750gr3 and, god damn it
no joy

working exactly as described in posts above, only last peer is working
tested on 7.2.1 and 7.3b

back to CHR and WG network is UP
one WG interface, multiple peers

edit: i tried to tracert directly from central MT what is happening with IPv6 and, to my surprise, every ! IPv6 is routed to last (working) peer, looks like last peer take precedence in routing table
central MT is ::/112 and allowed address in peers are ::/128
but, again, same config work as expected on CHR

Znevna · Sun Apr 24, 2022 8:08 pm

So the fix wasn't applied to all platforms?

Sob · Sun Apr 24, 2022 10:09 pm

I tried minimal config on RB450 (mipsbe, same as hap ac mentioned in first port) and it still works. Complete config:

/ip dhcp-client
add interface=ether1
/ipv6 dhcp-client
add interface=ether1 request=address
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
add allowed-address=2001:db8:450::183/128 interface=wireguard1 public-key="bN..."
add allowed-address=2001:db8:450::184/128 interface=wireguard1 public-key="aA..."
add allowed-address=2001:db8:450::10/128 interface=wireguard1 public-key="eQ..."
/ipv6 address
add address=2001:db8:450::1/112 advertise=no interface=wireguard1

All three connected clients are pinging 2001:db8:450::1 at the same time. Mask /112 is inspired by @npeca75, previous /64 was ok too. I tried WG using both IPv4 and IPv6 transport, in case there could be any difference there, but it works with both.

borr · Sun Apr 24, 2022 11:32 pm

Sob, could you please test with two wireguard interfaces where the first one is default gateway and the second one is used for incoming connections? Please look into my first post.

Sob · Sun Apr 24, 2022 11:59 pm

I can add one, but it's just routing between two interfaces, right? There's nothing special about that.

Sob · Mon Apr 25, 2022 2:11 am

RB450, ROS 7.2.1, same config as yours from first post, I only added lo1 interface as empty bridge, and had just two peers on ep3. Running ping from both to fd02:20::1, fd02:21::1 and 2001:db8:1:2:3:4:5:6 (random address assigned to remote device connected to njalla tunnel), everything works at the same time. Same for pings from the remote device and from this router to both peers. Enabling or disabling peers, restarting router, I can't find a way to break it.

npeca75 · Fri Apr 29, 2022 6:35 am

well, same with latest beta

rb760
"central" MT could ping all peers from /112
but "side" peers could not reach other peers
and only last peer could ping "central" MT
so confusing

back to CHR
everything is working

config was imported line by line to 760, so no chance for bad binary backup/restore

Znevna · Fri Apr 29, 2022 6:38 am

ok, so it's still a problem on mmips and arm?

borr · Fri Apr 29, 2022 4:58 pm

Yes, it seems so. Same for me.

vaizki · Fri Apr 29, 2022 5:17 pm

I am also seeing this with 7.2.1 on RB1100AHx4 (arm). Only the last IPv6 works.

My WG config was created fresh on 7.2.1 as I upgraded this box from v6 straight to 7.2.1 (and there is no WG on v6).

yverry · Thu May 05, 2022 10:13 pm

7.2.3 nothing new, rollback done :'(

borr · Sat May 14, 2022 5:14 pm

updated to 7.3beta40 – wireguard peers still cannot use IPv6 simultaneously

npeca75 · Sat May 14, 2022 8:49 pm

well
there is no other way

my recipe for WG Mgmn network:
1 pcs of old plain rb750 with
OpenWRT 19.07.10,
custom compiled with WG, no Luci, no WIFI

this way, approx 15 pcs of WG peer with avg 2-3 mbps traffic working very well
Network is designed for two way SNMP, SSH, Winbox and (T)ftp, Monitoring and management
after one week, i could say this is very stable setup

pros:
old rb750 reused, no e-waste
OpenWRT is stable and does not suffer from config damage on reboot
15-20% CPU does not produce so much heat

cons:
rb750 is weak for normal WG use, so site2site and similar demanding setups wont work on this old piece of HW
but for proof of concept it is so cool

reused MT HW

borr · Thu May 19, 2022 4:16 pm

Good news, everyone!

Support answered that they were able to reproduce the issue and hopefully issue will be sorted shortly.

Znevna · Thu May 19, 2022 4:41 pm

Did they mention something about architecture? because it seems fixed in arm64 already..

borr · Thu May 19, 2022 5:03 pm

No, nothing specific.

borr · Wed Jun 08, 2022 1:48 am

hap ac^2, hex r3 updated to 7.4beta2 – wireguard peers still cannot use IPv6 simultaneously, the bug is not fixed yet

badmonkey · Sun Jun 12, 2022 3:05 pm

hap ac^2, hex r3 updated to 7.4beta2 – wireguard peers still cannot use IPv6 simultaneously, the bug is not fixed yet

Just updated to stable 7.3.1 on ac2 and found this bug. IPv6 only works for the peer which was enabled or modified last. Lovely.

Znevna · Mon Jun 13, 2022 9:47 pm

Hard to follow this issue around, there's at least another topic about it: viewtopic.php?t=180482
I've copied my working config from arm64 to arm and indeed it seems to be still broken.
So my assumption that the fix wasn't applied to all platforms was correct.
Behaviour is the same:

arm-wireguard-peerbug.PNG

You ping :13 and you get a wrong reply obviously from :12

harenber · Tue Jun 21, 2022 5:02 pm

After trying for hours, I found this forum post here. My server is a RB4011iGS+ (so arm architecture) and with a colleague, I could verify that only the last enabled peer can ping over IPv6. What a bug.... Tried 7.3.1 and 7.2.3.

DarkNate · Wed Jun 22, 2022 1:58 am

Same problem on fresh netinstalled v7.3.1 on RB3011.

Sometimes the clients are IPv6 reachable, sometimes they are not. It is completely random. IPv4 works fine.

Znevna · Wed Jun 22, 2022 8:56 am

It's not random, the last changed peer works.
Support said it'll be fixed in one of the future versions.
It's already fine on CHR and arm64 afaik.

mantouboji · Tue Aug 09, 2022 8:30 pm

still in 7.4.1

mrizvic · Tue Aug 23, 2022 1:30 pm

Just upgraded to 7.5rc1 and stil I cant reach any IPv6 address via wireguard.
I even created firewall rules in input and forward chains (IPv4 and IPv6) to see if there is any traffic via wireguard interface but there is none - that goes for IPv6 pings.

Can I do anything in order to help debugging / resolving this issue?

      routerboard: yes
        board-name: hAP ac^3
             model: RBD53iG-5HacD2HnD
     serial-number: E7290ECAF7F2
     firmware-type: ipq4000
  factory-firmware: 6.46.8
  current-firmware: 7.3.1
  upgrade-firmware: 7.5rc1

/ip firewall filter
add action=accept chain=input in-interface=wireguard1
add action=accept chain=forward in-interface=wireguard1
add action=accept chain=forward out-interface=wireguard1

/ipv6 firewall filter
add action=accept chain=input in-interface=wireguard1
add action=accept chain=forward in-interface=wireguard1
add action=accept chain=forward out-interface=wireguard1

/ip address
add address=aaa.bbb.ccc.1/24 interface=bridge network=aaa.bbb.ccc.0
add address=xxx.yyy.zzz.1/24 interface=wireguard1 network=xxx.yyy.zzz.0

/ipv6 address
add address=2xxx:xxxx:xx00::1 interface=bridge
add address=2xxx:xxxx:xx20::1 advertise=no interface=wireguard1

Even torch doesnt show anything

[admin@MikroTik-hAP-ac3] > /tool/ torch wireguard1 src-address=10.0.0.0/8
Columns: MAC-PROTOCOL, SRC-ADDRESS, TX, RX, TX-PACKETS, RX-PACKETS
MAC-PROTOCOL  SRC-ADDRESS   TX       RX      TX-PACKETS  RX-PACKETS
ip            10.xxx.xxx.x  5.1kbps  832bps           2           2
                            5.1kbps  832bps           2           2

[admin@MikroTik-hAP-ac3] > /tool/ torch wireguard1 src-address6=0::/0

Znevna · Tue Aug 23, 2022 2:11 pm

Nah, my ticket is still open.

yverry · Wed Aug 31, 2022 11:05 pm

no surprise, 7.5 STABLE doesn't fix our issue :'(

yverry · Sun Sep 11, 2022 9:39 pm

hey,

and..... 7.6beta6 doesn't fix our issue

:'(

Wed Sep 14, 2022 4:12 pm

Thank you very much for your information. We are aware of the issue of concurrent IPv6 peers in the latest v7.x version. Hopefully fix will be available shortly.

Znevna · Thu Sep 15, 2022 10:00 am

Yet my reopened ticket SUP-67315 regarding this was closed with resolution "done" on 19.08.2022.
As mentioned in the reopening, it seems that the initial fix was applied only to arm64?

vergessen · Sat Oct 29, 2022 11:21 am

Is there any hope for this issue being resolved? It continues to impact on rb4011. Is this just going to be one of those if you don’t like it upgrade your hardware to a newer setup?

skocdopolej · Fri Dec 02, 2022 2:48 am

Hi,

any update?

Where can I track support tickets related to this bug? I could't find any here: https://help.mikrotik.com/servicedesk/s ... all&page=1

borr · Fri Dec 02, 2022 3:46 pm

It's closed because they unable to reproduce it

the ticket is SUP-78547

Hi,

any update?

Where can I track support tickets related to this bug? I could't find any here: https://help.mikrotik.com/servicedesk/s ... all&page=1

skocdopolej · Fri Dec 02, 2022 11:44 pm

We'll see if support ignores me too.

Ticket SUP-99987

DarkNate · Tue Dec 06, 2022 12:31 am

Definitely not working as of 7.6 stable netinstall.

skocdopolej · Tue Dec 06, 2022 11:55 am

Hello,

Thank you for the report. Unfortunately, this is a known issue with no solution yet. Hopefully the issue can be resolved in future RouterOS releases.

Znevna · Tue Dec 06, 2022 4:07 pm

Odd responses, they fixed it for arm64 and x86, they should apply the same fix, sheesh.
Weird.

skocdopolej · Tue Dec 06, 2022 7:06 pm

IPQ-4019 SoC (hAP ac3) is also ARM architecture.

Does anyone know if hAP ax3 is affected by this bug?

yverry · Sat Dec 31, 2022 12:53 pm

Hi there,

on my hex S no news under the last day of 2022.
7.6 -> broken
7.7rc3 -> broken

:-/

rollback ok (as usual)

vergessen · Sat Dec 31, 2022 4:54 pm

interesting they can fix it for other(newer) hardware but some how it just can’t be fixed on arm.

Znevna · Sun Jan 01, 2023 5:31 pm

I can no longer test this, I've tried, they did nothing.
My production routers are still on v6, so no wireguard.
And at home I've switched my main router to OpenWrt again, they deal with IPv6 way better, over all.

Ivotje · Thu Jan 19, 2023 11:01 pm

Got it working on v7.7! (RB4011)

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1

/interface wireguard peers
add allowed-address=172.16.x.xx/32,fd03:1::xx/128 comment=MacBook interface=wireguard1 public-key="$mykey"

/ipv6 address
add address=fd03:1::1 advertise=no interface=wireguard1

/ipv6 firewall nat
add action=masquerade chain=srcnat out-interface=ether1-internet

/ipv6 firewall filter
add action=accept chain=forward in-interface=wireguard1 log=yes out-interface=ether1-internet
OR
add action=accept chain=forward in-interface=wireguard1 log=yes out-interface-list=WAN

I think what most missed is the forward rule, but if you disable it, it's not working, if enabled I get a 10/10 score on http://test-ipv6.com just like if I'm on wifi!
Thanks for the OP for the first part of the config

Znevna · Thu Jan 19, 2023 11:03 pm

Probably you misunderstood the topic.
The issue we're talking about in here presents itself when you have more than one peer.

Ivotje · Thu Jan 19, 2023 11:23 pm

What are you quotiing whole preceding post for? Does it help answering? Use "Post Reply" button. When you talk to somone do you repeat what was said before answering?

Ah, misunderstood.
Have multiple peers configured, but had only one connected.
But I see, connecting 2 clients, will break IPv6

hci · Sat Feb 04, 2023 12:18 am

Just spent some time getting wireguard working with iphone and an IPv6 address on MikroTik 7.7 ARM. Was very impressed how well it worked. But then it just quit. Spent hours and could not figure out why it quit.

I am guessing it is due too my adding additional peers?

Is this a bug MikroTik is working on? Any chance 7.8beta3 fixes this?

Sat Feb 04, 2023 10:00 am

Most likely ip address conflict with peers.
Start new thread with config exported minus serial and private keys.

Znevna · Sat Feb 04, 2023 10:12 am

Don't bother, it only works in arm64 and maybe x86 builds.

vergessen · Sun Feb 05, 2023 2:11 pm

There is no hope of this being fixed for arm. All tickets are closed as previously fixed. The main read in here is unless you’re on the newest arm64 stuff they don’t care and will never address this issue. Best solution find a second device to host wireguard, mdns, whatever else MikroTik won’t include or acknowledge.

hci · Mon Feb 06, 2023 11:26 pm

Appears to work on CHR which would be x86. Disappointing it does not work on ARM though.

DarkNate · Tue Feb 07, 2023 8:16 pm

There is no hope of this being fixed for arm. All tickets are closed as previously fixed. The main read in here is unless you’re on the newest arm64 stuff they don’t care and will never address this issue. Best solution find a second device to host wireguard, mdns, whatever else MikroTik won’t include or acknowledge.

Doesn't work on arm64, arm and TILE in my testing on v7.7 stable.

Znevna · Fri Feb 10, 2023 4:56 pm

On what device it works for you? And what did you test exactly?

Znevna · Sun Feb 19, 2023 3:41 pm

There is no hope of this being fixed for arm. All tickets are closed as previously fixed. The main read in here is unless you’re on the newest arm64 stuff they don’t care and will never address this issue. Best solution find a second device to host wireguard, mdns, whatever else MikroTik won’t include or acknowledge.
Doesn't work on arm64, arm and TILE in my testing on v7.7 stable.

Works fine on arm64.

arm64-wg-v7.8beta2-001.JPG

natman · Tue Apr 04, 2023 7:45 am

Facing similar issue in Ax3 also which is arm64. Is there a way to force wireguard end point to resolve only ipv4? Mine is dynamic ip, use mikrotik cloud service and it sync ipv6 too. So my dns resolve to ipv6 most of the time and no traffic go through.

Tue Apr 04, 2023 7:56 am

Disable ip6 ?

Znevna · Tue Apr 04, 2023 12:37 pm

Facing similar issue in Ax3 also which is arm64. [...]

That's in no way similar to the issue discussed in this topic.
Allow your wireguard to work on IPv6 too, or disable IPv6 access to MikroTik IP Cloud in order for it to use IPv4 only:
- disable IP Cloud so that the current entries are removed;
- add cloud2.mikrotik.com to an address list:

/ipv6 firewall address-list add address=cloud2.mikrotik.com list=ipcloud

- drop that list in the output chain:

/ipv6 firewall raw add action=drop chain=output dst-address-list=ipcloud

- enable IP Cloud.

natman · Tue Apr 04, 2023 2:41 pm

Allow your wireguard to work on IPv6 too, or disable IPv6

Already ipv6 must be enabled, since from my iphone I can connect to wireguard using ipv6, but other peers not working. If i manually use ipv4 address in endpoint, then it's working fine.

I will add ipv6 firewall rule like you mentioned, thanks a lot.

Znevna · Tue Apr 04, 2023 2:46 pm

I don't fully understand your issue then.
Some peers can connect to your IPv6 endpoint and others can't? Or?

natman · Tue Apr 04, 2023 3:08 pm

Yes only one peer can successfully connect using ipv6, but others are working only through ipv4 endpoint.

Tue Apr 04, 2023 3:32 pm

One peer and one peer only ?
Or only one at a time ?
The latter indicates a problem in your allowed addresses on the peer definitions.

foxx1337 · Fri May 05, 2023 2:08 am

Problem still manifests on 7.9 and hap ac3.

It's only one peer, the last one who had its config saved on the mikrotik.

yuhuan417 · Fri May 05, 2023 2:45 pm

I submitted a support ticket today and the engineer provided me with a 7.10 alpha version that has fixed the issue. Tested on my hap ac^2. Stay tuned.

Znevna · Fri May 05, 2023 3:45 pm

My ticket from 2021, November 29th, that was closed and reopened and closed again, just received an update that there's a fix incoming, also.
Snappy development.
Thank you, MikroTik!

Fri May 05, 2023 3:48 pm

That's intermittent development, then ?

vergessen · Sun May 07, 2023 2:00 pm

Interesting I see a report of this working correctly. I am running the current alpha and the same issue persists on a rb4011.

1 peer set up. IPV6 works as expected. Add a second peer only the most recent peer gets ipv6. The rest of the peers do not. I have tested every devices configuration on their own as a single peer and ipv6 works with all of them. I don’t have this issue on a rb5009

yuhuan417 · Mon May 08, 2023 6:34 am

The engineer give me this 7.10 alpha version for arm, try at your own risk: https://box.mikrotik.com/d/cbe208b89a0d43efb787/

Interesting I see a report of this working correctly. I am running the current alpha and the same issue persists on a rb4011.

1 peer set up. IPV6 works as expected. Add a second peer only the most recent peer gets ipv6. The rest of the peers do not. I have tested every devices configuration on their own as a single peer and ipv6 works with all of them. I don’t have this issue on a rb5009

vergessen · Mon May 08, 2023 2:56 pm

Using the latest I received from support the issue is resolved on my system. All peers get the correct IPv6 assigned and work as expected.

mvdnes · Mon May 08, 2023 9:34 pm

The problem is still occuring on mmips (Hex S) on 7.9 stable.
Hopefully this platform might also be fixed on 7.10.

npeca75 · Wed May 10, 2023 9:55 pm

Using the latest I received from support the issue is resolved on my system. All peers get the correct IPv6 assigned and work as expected.

yes, it is working , at least tested on MMIPS

mantouboji · Wed May 24, 2023 8:06 am

it works in 7.10beta0

badmonkey · Mon Jun 19, 2023 5:27 pm

Just upgraded to 7.10 stable
And immediately my client (phone) ipv6 on Wireguard stopped working

Playing about I discovered it is the same situation as before; only the most recently enabled peer will work.
That is, with my configuration which set on router "allowed addresses" for the peers to be a /64 address, same as that set in the ipv6 pool dedicated to the Wireguard interface.
So I have "allowed address" ipv6 set to 1111

3333:4444::/64 for each peer, and my expectation was the peer could pick any /128 address after that prefix it liked, and so long as no peer clashed it should work.
I emphasize: this did and does work, but only in the context of the same bug discussed this thread...

Now I played around a bit on 7.10 and discovered I can only get the bug to be 'fixed' if I have "allowed addresses" set to a /128. Only then does it not matter if the peer is most recently enabled.

I also can't get say a /80 prefix to work at all, recent enabled or not.

What gives? Is Wireguard supposed to only work for unique unchangeable allowed addresses? If so why does it work with the /64 at all?

mantouboji · Mon Jun 19, 2023 7:44 pm

I also can't get say a /80 prefix to work at all, recent enabled or not.

What gives? Is Wireguard supposed to only work for unique unchangeable allowed addresses? If so why does it work with the /64 at all?

In my case, the "allowed address" of every peer at RB4011 are /32 and /128, and at every client ( iPad, Linux, iPhone, etc) use /24 and /64 . works very well.

截屏2023-06-20 00.40.19.png

badmonkey · Wed Jun 21, 2023 3:12 pm

In my case, the "allowed address" of every peer at RB4011 are /32 and /128, and at every client ( iPad, Linux, iPhone, etc) use /24 and /64 . works very well.

So you are allowing /128 at the router but setting /64 at the client peer? I had sort of assumed the peer had to be more specific not less.
Your peers all have the same interface address for ipv6 as fd80:28:602:1::/64 is that right?

I am trying to do the opposite, where the client peer might choose any /128 IP from an allowed /64.

The puzzling this is it does seem to work but brings this thread's bug back to life. I.e. one peer can connect but only to the most recently enabled one.

mantouboji · Thu Jun 22, 2023 8:18 am

It's true.

RB4011 as a hub, services for several clients, and according to the basic theory of wireguard, the hub should assign every client's "allowed-address" to a host address, like a /32 and a /128 .

And looks from the client side, the hub have a subnet and all clients in it , so must set the self address of every client to an address with net mask, like /24 and /64.

In my case , RB4011 wg4 interface have address 192.168.22.1/24 and fd80:28:602:1::1/64, and every client use address 192.168.22.1xx/24 and fd80:28:602:1::1xx/64 .

Here is the configuration of one clients as sample, an iPhone , itself address is .105/24 and ::105/64, the "allowed-address" is 0.0.0.0/0 and ::/0 , since it use the wireguard as a default gateway.

natman · Sun Jun 25, 2023 10:49 am

Need a help!

My isp moved to CGNAT and gives IPv6. So wireguard stopped working due to private ipv4.

Then I blocked ipv4 cloud and enabled only ipv6 cloud using the firewall tip given by @Znevna so that dns will resolve to ipv6.

I started configuring local ipv6 to the wireguard interface and peers. In the client side(iPhone) without doing any changes the previous config based on ipv4 is connected successful. I was under the impression, that client side too needs ipv6.

So question I've is now, does ipv6 config is needed in the wireguard server in mikrotik side? Or just making ipv6 based dns endpoint itself enough?

mantouboji · Sun Jun 25, 2023 10:57 am

So question I've is now, does ipv6 config is needed in the wireguard server in mikrotik side? Or just making ipv6 based dns endpoint itself enough?

For IPv6 there is no any diffenrent to IPv4. but maybe a smaller MTU is helpful ( I use 1380 ) .

And, don't forgot to open UDP port of wireguard in /ipv6/firewall/filter/ . for me. it like this:

/ipv6/firewall/filter/print
8 ;;; Inner WG
chain=input action=accept protocol=udp dst-port=13231 log=no log-prefix=""

Znevna · Fri Aug 04, 2023 1:32 pm

They fixed it again in v7.11rc2 viewtopic.php?p=1017059#p1017059

What's new in 7.11rc2 (2023-Aug-03 10:50):
[...]
*) wireguard - fixed peer IPv6 "allowed-address" usage;

Who is online