Wireguard client (minimally Android & iOS) - IPv6 traffic not passing through tunnel

DjM · Thu Nov 18, 2021 10:10 pm

Hello MikroTik forum community,

Could you, please, test if there is IPv6 communication through wireguard working for you, in scenario:

Wireguard server = MikroTik, 7.1r6
Wireguard client: Android 11 (in my case Samsung S21 latest) or iOS 15.1

Wireguard client is connecting via IPv4 to wireguard server. IPv4 communication is working through tunnel, IPv6 communication is not working through tunnel. In case that wireguard client is Windows 10, IPv6 communication is working through the wireguard VPN.

Configuration on Windows 10 client and Android / iOS clients is the same (except keys and IP/IPv6 addresses). Android and iOS clients are not able to ping IPv6 address of wireguard server through VPN. Allowed addresses on wireguard clients are: 0.0.0.0/0, ::/0

Any feedback or hints are welcomed.

Thank you

eworm · Thu Nov 18, 2021 11:25 pm

With latest releases the Wireguard interfaces do not have link local addresses. This IPv6 is completely broken with Wireguard at the moment.

DjM · Fri Nov 19, 2021 2:10 pm

Thank you for your feedback

mducharme · Fri Nov 26, 2021 8:05 am

With latest releases the Wireguard interfaces do not have link local addresses. This IPv6 is completely broken with Wireguard at the moment.

This isn't correct. IPv6 is working with wireguard for me with rc6 even without a link local. What doesn't work over wireguard is OSPFv3.

Znevna · Fri Nov 26, 2021 10:00 am

I'm sorry, WireGuard IPv6 doesn't seem "completely broken" in 7.1rc6, here, tested with Android:

WireGuard 7.1rc6 IPv6.png

Screenshot_20211126.jpg

WireGuard over IPv4 endpoints.

jookraw · Fri Nov 26, 2021 1:34 pm

For anyone with issues related Wireguard IPv6, try disabling the affected peer and enabling again, this seems to affect peers after a reboot (p.s. 7.1rc7 is also broken)

eworm · Fri Nov 26, 2021 4:58 pm

Ha, stupid me... This was bad timing.

For me this broke when updating to 7.1rc5, but I did not notice that I borked my subnets at the same time. (Note to self: 0x10 != 0xa and IPv6 has addresses with hexadecimal representation)

You are right that simple IPv6 setup over Wireguard still works as long as link local addresses are not required.

eworm · Fri Nov 26, 2021 10:16 pm

Still, there's something really bad... Is is possible that just one peer can communicate via IPv6? Looks like the turn goes to the peer enabled last.
Can anybody use IPv6 with more than one peer?

DjM · Fri Nov 26, 2021 10:34 pm

For anyone with issues related Wireguard IPv6, try disabling the affected peer and enabling again, this seems to affect peers after a reboot (p.s. 7.1rc7 is also broken)

Hello jookraw,

Thank you for the hint, disabling & enabling wireguard peer solved the issue. I will continue in testing it, let's see what surprises will be discovered.

Still, there's something really bad... Is is possible that just one peer can communicate via IPv6? Looks like the turn goes to the peer enabled last.
Can anybody use IPv6 with more than one peer?

I will test it within next days and give you a feedback.

DjM · Sat Nov 27, 2021 10:31 pm

Hello MikroTik community,

I can confirm that latest wireguard peer, which has been disabled & then enabled in ROS, is passing through IPv6 traffic. Issue is active on ROS 7.1rc5-7, I have submitted SUP-67181.

jookraw · Mon Nov 29, 2021 1:04 pm

Hello MikroTik community,

I can confirm that latest wireguard peer, which has been disabled & then enabled in ROS, is passing through IPv6 traffic. Issue is active on ROS 7.1rc5-7, I have submitted SUP-67181.

Just tested this, and the result is the same, only the peer enabled last will have IPv6 connection working.

eworm · Mon Nov 29, 2021 4:18 pm

Can you please share the ticket with me? I can see the details then.
My mail address is "mail@username.de" ... Thanks!

Znevna · Mon Nov 29, 2021 4:59 pm

The title of this topic is wrong, since it's unrelated to Android or iOS, but I've opened a ticket for this too anyway.
It seems that the last changed peer gets the allowed-address saved (=translated into wg conf) correctly while the other peers get broken allowed-address (only the IPv6 part).
And you don't have to disable/enable, just issue an enable to a peer and that one will have working IPv6, or change something in it's config, same result, basically anything that rewrites the config.
Also you can't set "::/0" from WinBox, only from CLI. I've mentioned this too.

DjM · Tue Nov 30, 2021 10:55 pm

@eworm:
I have send you details via email.

@Znevna:
Thank you for useful review & feedback, technically it sounds reasonable for me. Let's see what will be the feedback from MikroTik.
Can you share your SUP number, please?

jookraw · Thu Dec 02, 2021 2:47 pm

bad news, in the 7.1 (testing) the issue still here...
did anyone recieved any reply from Mikrotik on the support tickets about this bug?

DjM · Fri Dec 03, 2021 1:49 pm

There is no reply from MikroTik to my support ticket.

Znevna · Fri Dec 03, 2021 2:22 pm

Chill, I'm sure they've seen it.
SInce v7 went "rc" I bet they had a little flood of incoming tickets (watching the numbers from my tickets since a few days ago, the numbers increased with 100 in under 24 hours).
I'd say that they sort the issues reported and reply to the most "critical" ones first, and also, try to look into the most critical ones first.
I don't imagine they have hundreds of devs looking all over the code for every tiny bug.
It'll get fixed I'm sure

jookraw · Tue Dec 21, 2021 3:51 pm

just tested the 7.1.1 and the issue is still here... so we are being ignored by Mikrotik

anav · Tue Dec 21, 2021 4:02 pm

just tested the 7.1.1 and the issue is still here... so we are being ignored by Mikrotik

No Mr Impatient, they have a ton of reported bugs to work through??

jookraw · Tue Dec 21, 2021 5:13 pm

...
No dipshit, they have a ton of reported bugs to work through, did you have a terrible childhood??

1st, give some respect, and look for your language.

I don't care if they have "too much work", this is not excuse, I and others have reported this issue since 7.1rc5, ignored since then.
Silence means being ignored, they even have not ack the ticket opened by me, but have replied to other ticket related to another issue.

btw on 7.2rc1 it is still also broken

anav · Tue Dec 21, 2021 5:47 pm

...
No Mr Impatient! they have a ton of reported bugs to work through,?
1st, give some respect, and look for your language.

I don't care if they have "too much work", this is not excuse, I and others have reported this issue since 7.1rc5, ignored since then.
Silence means being ignored, they even have not ack the ticket opened by me, but have replied to other ticket related to another issue.

btw on 7.2rc1 it is still also broken

noted and modified..............
Yes, but Im not the one who is so entitled (how dare they ignore the great jookraw),
When you get off the pedestal, then perhaps one will get a modicum of respect.

noradtux · Tue Dec 21, 2021 7:26 pm

I also see this issue after upgrading from rc4 to rc5. I have one wg interface on my rb5009 with two Linux systems as peers. Sniffing on both peers and pinging both from the router I see echo-requests for both peers arriving on the peer that established its wireguard tunnel last.

xtaz · Tue Dec 21, 2021 8:57 pm

This has been driving me mad trying to get wireguard to work with IPv6. I could get it to work with one peer but as soon as I added a second peer IPv6 stopped working.

I can see that the release notes for 7.2rc1 says "wireguard - fixed IPv6 LL address generation" so does this not fix the problem then as I see people saying it still doesn't work in the rc.

noradtux · Tue Dec 21, 2021 9:43 pm

This has been driving me mad trying to get wireguard to work with IPv6. I could get it to work with one peer but as soon as I added a second peer IPv6 stopped working.

I can see that the release notes for 7.2rc1 says "wireguard - fixed IPv6 LL address generation" so does this not fix the problem then as I see people saying it still doesn't work in the rc.

Nope, LL addresses where an other issue.

jookraw · Wed Dec 22, 2021 1:19 pm

I've opened a new ticket yesterday, this time with 7.2rc1 on the title. Mikrotik replied in less than 12h, thanking the report and saying that it will be solved in coming versions, so, there is a light in the end of the tunnel, just idk how long that tunnel is...

noradtux · Wed Dec 22, 2021 6:35 pm

Yesterday I got basically the same reply to my ongoing ticket. So they are working on it

aglabs · Fri Dec 31, 2021 8:25 pm

Thanks to the folks in this thread for their research. Finding this thread saved me from a massive headache. Opened a case as well. Hope a fix is released soon.

grisu48 · Thu Jan 06, 2022 9:56 am

I have the same issue (only one IPv6 wireguard peer active at the same time) and am glad to see, that this will be solved in an upcoming release.

noradtux · Fri Jan 28, 2022 2:06 pm

Issue persists on 7.2rc2

anav · Fri Jan 28, 2022 3:21 pm

I've opened a new ticket yesterday, this time with 7.2rc1 on the title. Mikrotik replied in less than 12h, thanking the report and saying that it will be solved in coming versions, so, there is a light in the end of the tunnel, just idk how long that tunnel is...

S being the operative letter!

hcuk94 · Fri Feb 04, 2022 10:39 am

I am so glad I found this thread!
I've been going round in circles for hours trying to figure out what I've done wrong - and eventually came to the conclusion that only one IPv6 peer could work at any one time, but still figured it was my issue.
Found this thread and am incredibly relieved at least to know I'm in good company.. lets hope MT manage a fix soon...

aglabs · Mon Feb 21, 2022 7:20 pm

7.1.3 seems to fix this for me, hope everyone else having same luck

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

noradtux · Mon Feb 21, 2022 7:29 pm

7.1.3 indeed fixes this issue for me

DjM · Mon Feb 21, 2022 7:50 pm

7.1.3 is also working for me.

Thank you for all forum members who tested & supported to get this bug fixed

psiwray · Tue Feb 22, 2022 9:08 am

I just upgraded to 7.1.3 but the issue is still there for me. I have four peers over two WireGuard tunnels. First one that I enable has IPv6 working fine, then I enable a second one and it stops working. What did you do to test that the setup was now working with the new release?

fruel · Tue Feb 22, 2022 9:52 pm

I still have the same issue. Only the client that was enabled last works.

Clients also connect over IPv6 to the Wireguard server.
As shown I also tried different settings for "allowed addresses"

Configuration:

# feb/22/2022 20:45:44 by RouterOS 7.1.3
# software id = W604-HIX1
#
# model = RB4011iGS+
# serial number = 
/interface wireguard add listen-port=51820 mtu=1420 name=wg-test private-key="..."

/interface wireguard peers
add allowed-address=172.27.11.2/32,fd00:11::2/128 comment="Client A" interface=wg-test public-key="..."
add allowed-address=0.0.0.0/0,::/0 comment="Client B" interface=wg-test public-key="..."
add allowed-address=172.27.11.4/32,fd00:11::4/128 comment="Client C" interface=wg-test public-key="..."
add allowed-address=0.0.0.0/0,::/0 comment="Client D" interface=wg-test public-key="..."
add allowed-address=0.0.0.0/0,::/0 comment="Client E" interface=wg-test public-key="..."

/ip address add address=172.27.11.1/24 interface=wg-test network=172.27.11.0
/ipv6 address add address=fd00:11::1 advertise=no interface=wg-test 
/ipv6 firewall nat add action=masquerade chain=srcnat out-interface=!wg-test src-address=fd00:11::/64
/ipv6 firewall filter add action=accept chain=input dst-port=51820 protocol=udp

eworm · Tue Feb 22, 2022 11:01 pm

You can not set allowed-address=0.0.0.0/0,::/0 on the peer that acts as the server. The symptoms are the same, but this is configuration issue. Only define the addresses and networks that are accessible on or behind the peer...

404Network · Tue Feb 22, 2022 11:19 pm

Hold on lets be accurate.
You cannot have duplication of peer IP addresses, within the allowed IPs, for a single WG interface.

Fruel how will the router know which peer address to pick for 0.0.0.0/0
I Will tell you it will pick the first on on the list and the other peers will never be chosen.

Znevna · Tue Feb 22, 2022 11:24 pm

What a mess of a config.
"Check yer peers". I'll add this to my sig.

fruel · Wed Feb 23, 2022 1:09 am

Ah of course, makes much more sense that way. Will change that, thanks!
(I had the proper adresses in there at some point before this IPv6 bug was introduced...)

What a mess of a config.

Just because of the addresses or is there something else?

Znevna · Wed Feb 23, 2022 7:18 am

Because of the allowed-address.
Let us know if it works after you clean it up!

fruel · Wed Feb 23, 2022 10:09 pm

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: viewtopic.php?t=183474#p915168

psiwray · Thu Feb 24, 2022 8:40 am

Yeah same, I tried to change some stuff around too but the problem persists even with 7.1.3.

Mantic · Wed Mar 09, 2022 7:23 pm

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.

Who is online