MikroTik

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

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

Thank you for your feedback

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.

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

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)

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.

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?

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.

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.

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.

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

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.

@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?

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?

There is no reply from MikroTik to my support ticket.

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

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

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??

...
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

...
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.

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.

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.

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.

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...

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

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.

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.

Issue persists on 7.2rc2

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!

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...

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

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

7.1.3 indeed fixes this issue for me

7.1.3 is also working for me.

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

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?

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:

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...

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.

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

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?

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

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.