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.
