This topic was prompted that once again I was asked why VPN-Policy-Routing is not in the official repo and when I originally sent a PR, it wasn't accepted due to lack of IPv6 support.
The outcome of this topic as I see it would be:
Understanding how VPR should attempt to affect IPv6 traffic
A few IPv6 experts testing the app when the above is implemented to confirm it's working as expected.
I don't have a lot of expertise in IPv6, so I'll just paste a quote from the VPR thread:
So if a user has IPv6 supported by ISP and he.net tunnel and a few IPv6-capable VPN tunnels, for legacy IP I can configure ipsets and iptables rules to route specific addresses/ports/domains via specific tunnel.
What should be the expected behaviour for IPv6 in this case? Is it reasonable to expect VPR to alter the IPv6 traffic same way? Is there anything VPR can do to make IPv6 traffic flow according to user-selected policies?
I would also like other IPv6 users/experts to participate in this thread in addition to @slh.
Given all the hard work @stangri has put into this... happy to provide some testing endpoints... if a minimal scope is defined ( tunnel types supported - aka what are the one or two most common use cases - ip6ip6 anyone? )... that should expedite things.
I guess Network Prefix Translation is one solution if you get a large IPv6 prefix from the VPN provider. You need a /64 for a LAN.
With fewer addresses you probably need to use NAT66 instead.
It's used when selecting source address according to RFC 3484. The target address should already be selected and it will be used when selecting the source address.
BTW ip addrlabel on the router will only affect locally generated traffic and not forwarded traffic.
the main issue with ipv6 as I see it is that a multi-homed network will cause clients to have addresses on several prefixes. when the client wants to talk to the internet it chooses an IP address to use as its source address for its packets. once it does this, the WAN connection must be the one from which the prefix comes, (barring any high end business class contract where the ISP allows traffic from various sources).
So basically the router has no choice... the only way the router can affect this is to do network prefix translation, or God forbid NAT66.
so the question is, what should VPR do with packets from the LAN?
IMHO any VPN that assigns less than a /60 is broken and you should go elsewhere (this is likely ALL of them). if they assign a /60 then at most you need NPT.
If I wanted a VPN type service I would rent a digital ocean droplet or the like and install wireguard to roll my own, for various reasons including security.
Technically it's not true, because to run a service you don't need a /32.
A /64 or even a /128 is enough to run a service.
It should be clarified that NAT6 aka NAT66 is enabled/disabled globally.
Currently NAT6 is broken on the level of fw3 service.
While IPv6 masquerading, which relies on NAT6, may be enabled per firewall zone.
For WireGuard I can see only the peer's own IP address/netmask.
I used these utilities for testing:
ifconfig
ip address show
ip route show table all
It doesn't matter whether I enable route_allowed_ips or not.
Are you sure it is possible get anything else?
Please, provide an example configuration so we can find common ground.
Perhaps my system is a bit too old:
# uname -a
Linux vgrouter 4.14.63 #0 Thu Aug 16 07:51:15 2018 mips GNU/Linux
# opkg list-installed wireguard
wireguard - 0.0.20190601-1
This is what bugs me. That's why I suppose that NPTv6 - and not NAT6 - is the solution for multi-homing. It lets clients handle only 1 IP address while also lets router do load balancing with any rule we'd like.
I don't see why this would be bad. Having clients with 2 or more GUA + ULA and handling routing with no way of customizing it is anything from good.