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
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?
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.
I will test it within next days and give you a feedback.
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.
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.
@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?
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
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.
