Enable peers' to connect to the IPv6 WAN through Wireguard's IPv4 connectivity

[ToasterDEV]

Okay, first of all thanks for the detailed answer, I'm honestly still trying to make heads or tails of it, but if I'm understanding correctly there might be an (imperfect/unstable) way to achieve things still (I'm still kind of out of my depth when it comes to IPv6, so please correct me if I'm wrong anywhere).

@mk24

So relay mode is the key. In relay mode:

• LAN-like interfaces do not have any GUA, only link-local and possibly ULA.
• LAN endpoints are advertised the wan prefix via relay, then use SLAAC to assign themselves an IP within that prefix.
• dhcpv6 may be run in server mode to configure DNS servers onto the endpoints. (odhcpd does not presently support a DNS option in relayed RAs).
• LAN endpoints use the routers link-local as their default gateway.

From what I understand here, this is what both AsusWRT/Merlin and stock OpenWRT tried to do with my PPPoE link, given that before I started tinkering around with the Interface's settings all network devices would receive an individually addressable SLAAC-assigned IP Address (albeit a /64 one, but still), being as such that they were able to both traverse and directly communicate with the global Internet even if I was to manually disable their access to the v4 section of the network.

At some point along the journey, I broke this while trying to implement NAT6 and left it unfinished, thus everything capable of holding one would now only receive a link-local address, leaving no traversal connectivity and only DNS6 capabilities on a good day since the rest of the network stack was still
expected to handle such connections.

Thing is, how can I turn this back on if needed?

@mk24

The obvious workaround for this is to NAT6 in the home router, converting the ULAs of LAN and VPN endpoints to the router's GUA. This is also not a very good solution. Some OSs will not use a ULA as a default route.

Given this was the original plan, it concerns me a little that you mention possible (I hope) edge cases where certain OSs would not accept such topology and use it, but if so, which ones should I watch out for and (possibly) find a workaround for, if I were to go this route?

@mk24

The real solution is for the road warrior to hold a GUA and use it directly to originate connections to the Internet via VPN. This is a problem with Wireguard, since the road warrior's /128 needs to be installed as an allowed_ip on the server, and when the road warrior chose it by SLAAC or privacy enhancement, the server has no way to know what IP was chosen.

This would certainly be an interesting approach, and given what you say probably the most reasonable answer (though it still would leave me concerned for how to perform Policy Based Routing without NAT6), but it leaves me wondering if perhaps a hotplug script would be able to add and/or delete the rotating addresses of each peer on the moment of the handshake, even if from my understanding this would have the potential of causing temporary disconnects for any other peer using the server.

In any case, taking into account the configurations I've shared, would this be sufficient as a starting point to proceed to any of the three scenarios? And if so, how could any of them be achieved?

In the meantime, thanks for the patience and the help!

Edit:

After sending this message I started trying to bring up manually the wan6 interface, prompted by this forum post, and after letting LuCI adapt it to the modern syntax, nothing happened.

Then, I checked again what you mentioned regarding the relay roles, and finally got it working with the following configuration:

/etc/config/network

config interface 'wan'
	option proto 'pppoe'
	option device 'eth0'
	option username '*********@*******.net'
	option password '***********'
	option ipv6 '1'

config interface 'wan6'
	option proto 'dhcpv6'
	option device '@wan'
	option reqaddress 'try'
	option reqprefix '64'

/etc/config/dhcp

config dhcp 'lan'
	option interface 'lan'
	option leasetime '12h'
	option dhcpv4 'server'
	list dhcp_option_force '114,http://status.client'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'
	option ndp 'relay'
	option start '2'
	option limit '255'
	list dhcp_option '6,192.168.1.1'
	list dhcp_option '3,192.168.1.1'
	list dhcp_option '44,192.168.1.1'
	option ra 'server'
	option dhcpv6 'server'

config dhcp 'wan6'
	option dhcpv6 'relay'
	option ra 'relay'
	option ndp 'relay'
	option master '1'
	option interface 'wan6'

After this was set, I performed a reboot and ended up with no Internet connectivity... sorta.

Turns out that for some reason, pbr ends in a segmentation fault when under these settings, and also AdGuard Home crashes when failing to create its ipset file (FATAL: preparing ipset settings: open /var/run/pbr.adguardhome.ipsets: no such file or directory), so after commenting out its variable in the config file and restarting the service, I am back online!

I think I was able to get back to Native IPv6, but for some reason each device is receiving two addresses from WAN6 and LAN, and not even the router is able to reach anywhere through IPv6, but hey, progress!