NAT6 doesn't seem to work at all for me. Enabling it does break the IPv6 connection for all devices. Maybe because I am using a FritzBox as cable modem infront of it. I don't know. I'll probably look for a differnt solution to route the device through a VPN as I need IPv6 for some other devices.
Passthrough works as well as native but will also break as soon as the VPN client is enabled.
Hey @bruce, I've been waiting for over half a year and I just installed the 4.7.0 firmware, the IPv6 support with WireGuard server is still broken despite this thread including all the instructions required to fix it.
Since 4.7.0 is a completely new stable release created from a different branch, I'm starting to wonder if you're fully honest here. Could you please let me talk to some of these R&D colleagues to understand what might be the problem?
Actually, with 4.7.0 things are even worse than with 4.6.8. I upgraded from 4.6.8 to 4.7.0 and now the router is generating invalid WireGuard client configurations by truncating the IP address.
Here's how the configuration address section looks like on 4.6.8:
And here's how it looks like after upgrading to 4.7.0:
Needless to say, the config doesn't work. I'll just rather stick to 4.6.8 until this is fixed because manually modifying the configuration files is a real pain.
The incorrect truncated information seems to be coming directly from the wg-server generate_peer RPC endpoint that the frontend is calling. However, I've learnt that apparently the RPC API and the UI used by GL.iNet is not open source and I don't have access to fix this problem like I've done with the earlier ones.
I've recommended GL.iNet routers to some of my friends and family, but I'm starting to regret it now. You promise quick fixes, but in reality you don't fix anything and break things even more. I may just turn into recommending against GL.iNet instead at this rate. Please get me through to whomever I need to talk to to get these things resolved.
Hi,
Terribly sorry.
For the IPv6 support of Wireguard VPN Server, this is not a bug. It is a new feature, and since the complexity of IPv6 protocol, this task is not easy, but we have been working hard for it.
VPN Client has supported IPv6.
At that time, I mentioned that this requirement/feature was already under the development plan, not in the development process. But at present, according to R&D resources and project arrangements, gradually investing resources in development for the improvement of VPN server features, not only IPv6.
Regarding the profile issue of v4.7.0, when the server generates profile, the IPv6 address is abnormal, and we have realized it. Sorry. Thank you for the feedback. This issue will improve in the next firmware version.
Hi @juhovh ,Thank you for your feedback, the feature of IPv6 support for VPN service needs to be implemented in version 4.8, it is not supported in previous versions. We are currently working on this version, please be patient!
Hi,
Sorry, this is indeed our oversight. In v4.7, we made some checks on the export of configuration files, which affected this.
We have planned to introduce full support for IPv6 in VPN in V4.8.
Thanks everyone for a quick response.
The WireGuard address getting cut should be a higher priority, since it breaks the generated QR codes regardless of it the patches above are applied, and makes it quite difficult to import the WireGuard client tunnel info. Hopefully we can get that fixed fairly quickly.
I understand that with IPv6 the feature requires testing different configurations, which takes some extra time. At the same time it's increasingly common in many countries to only provide proper IPv6 connectivity and only CG-NAT IPv4 connectivity, if even that one. I can wait for 4.8, although with the release schedule for Flint 2 it might take at least half a year, hope we can get stability to the OpenWrt 24.10 based firmware as well by then.
While working on the IPv6 support for packets inside the tunnel, you could consider exposing the ipv6_enable option in /etc/config/wireguard_server in the UI or link it to the global IPv6 setting. To my understanding it just modifies the firewall to open the UDP port through ip6tables in addition to the standard iptables, which seems fairly low risk compared to other features.
This issue is fixed on v4.7.4 (or later) firmware.
Flint 2 running 4.7.7 and Beryl AX running 4.7.4 doesn't work... It used to work using the changes @juhovh suggested, but now, even if I change those, I still can't get IPv6 to work...
Hello,
Please upgrade the Flint 2 and Beryl AX firmware to v4.8 beta, and the VPN server is native supported the IPv6.
Any news about this? https://www.reddit.com/r/GlInet/comments/1l47nc8/friendly_reminder_keep_your_glinet_routers_below/
Hello,
We are difficult to reproduce this issue, since the exit node speed is not pretty well in my place, so cannot find the speed gap of exit node between v4.6.x and v4.7.x (or v4.8.x beta).
May I know do you have two GL router, one as the hosted exit node, and another one set to go to the exit node?
If you have, could you please share two GL router with us via GoodCloud? We would like to check this issue, based on your network environment.
Just to get back to this thread on the original topic, I've upgraded my router to 4.8.0-beta7 and found the following issues:
It's possible the Network Acceleration issue had to do with something other than the router, but considering the problems disappeared almost immediately after disabling it, and the fact that the router CPU seems to be more than capable of doing routing without acceleration, I'm going to leave it off.
I've only tried WireGuard server with IPv6, but at least that one seems to be working flawlessly. We can consider the instructions on this thread to be fully outdated once 4.8.0 is out.
I see there's a couple of other improvements in the UI related to IPv6 as well, thanks for working on these even though it took a bit of time. I can see IPv6 support only getting more and more relevant in the future, with many ISPs moving to CGNAT setup, so it's an important selling point for GL.iNet.
Hello,
Thank you for your feedback.
We finally reproduced this issue through many tests.
This issue seems not reappearing 100%, the probability is low, but the IPv6 connections completely work without issue when the acceleration is disabled.
When the issue occurs, export the following results:
cat /sys/kernel/debug/hnat/all_entry
It's great news that you've been able to reproduce the acceleration issue! It's a tricky one, because sometimes the connection seems to be working fine and sometimes it's completely unusable. I suspected it might have to do with IPv6, since Google services were particularly bad and they use IPv6 everywhere.
I can play around with it a bit when I have time, happy to also send you the HNAT details whenever it happens. Might do that some other time though, since I need my connection stable for the coming days, so won't be using the acceleration.
Thanks.
It has submitted to R&D and check.
I got a bit curious about this one, and ran a connection test with my 1000/50Mbps connection with and without WireGuard, over ethernet, no hardware acceleration, 4.8.0-beta8 firmware. Got the following results:
There’s clearly some overhead with WireGuard (10% drop in DL 20% in UL), but honestly I think the router is doing a good enough job for me (the website says 900Mbps and it’s close). Haven’t tried with an old firmware lately, but the newer firmwares have enough new features and benefits to cover for it IMHO.
