Ah ok, now I think we're on the same page. Unfortunately I didn't understand what you meant when you used the word "it" in "do it again" sorry for the confusion.
Now that you have a delegated prefix, you need to advertise a prefix on your LAN, and then your LAN clients will pick up an ipv6 address in that range, and then your router can route those sources down the VPN tunnel. That's not exactly trivial.
Part of the issue is I don't know what their script already does and what it doesn't do.
Can you connect to the VPN and then output result of
ip -6 addr show
it's fine to obscure some portion of the IP addresses but we'll need to be able to at least understand which ones come from Azire and which from HE and detect which prefixes are on what interfaces etc.
I already have a delegated prefix from Hurricane on my LAN, there's only one spot in LuCI to add an "IPv6 Routed Prefix..." on LAN so, do I have to use the CLI to add another prefix???
I haven't used a script. I took the provided information from curl and added it to my OpenWRT router...no scripts are in use, everything done from the results above (and the additional info using list=1 now) and placed in LuCI.
Ah ok. So, question for you, do you want HE and your VPN simultaneously active? How will your clients choose which IP addresses to use? What traffic should pass over the VPN and what over the HE?
Simplest thing would be to route everything over the VPN, and drop the HE, and then there's no conflict... and you could just plop the Azire delegated prefix into LUCI or whatever.
more complicated thing: you want to somehow choose one vs another route on a per connection basis using some kind of policy...
Well, think about a device on your LAN, say a windows desktop machine. It sees two prefixes advertised and generates at least 2 public IPv6 addresses.
Now you go to that machine and try to surf something... which ipv6 address will it choose as its source address?
Suppose it chooses an ipv6 address in the HE range, and it is trying to connect somewhere. Suppose your policy is that this connection should go over the VPN... well it won't because the VPN probably won't accept packets whose source address comes from your HE range....
so, again I ask, how do you want to handle having two prefixes on your LAN? are you OK with only some stuff going over the VPN randomly based on whatever ip address the windows/android/whatever client chooses to use as its source?
The topic over here: Multi-homed IPv6 with dynamic addresses has touched on similar issues, but it also led to no clear solution. The issue is that such configurations with multi-homed ipv6 are ... shall we say fairly tricky to get right, unless you have a commercial IP Transit connection and BGP or some such thing which will happily accept packets from anywhere.
I'm IPv6 certified...I'm 100% aware of the issue you're trying to describe, which is why I PREFERRED NAT66 for this problem. The same issue occurs in IPv4 with interfaces possessing multiple addresses. Nothing new.
I wouldn't prefer to setup a PD, but you are.
I noted that I'd setup NAT66. Since I'm aware of the issues you describe. I will handle the issues for each LAN device - for others, it's probably good to note for those not familiar, though.
I've now added the PD to my LAN. The LuCI display is distorted, but I believe it's issuing two PDs now.
Good, so now I think rather than NAT66 what you probably need here is NPT6 so that when you want something to go over the VPN you change only the prefix on the source address, and then policy-route it down the VPN.
The topic I pointed to above should give you some pointers on setting up NPT6, @jtsn posted some scripts there to set it up, he may have some useful pointers as to how to do it.
I don't think an additional PD can be added to a LAN. I may test adding a static route for the VPN subnet and forwarding it downstream, or on another LAN without IPv6 setup.
in my LUCI config on the LAN it says that it will sub-allocate a sub-prefix of every public prefix so I think maybe what you need is a new "WAN6vpn" interface that physically binds to the VPN tunnel's device, and then have that set up with a public prefix, and then maybe, hopefully but i'm not sure, the public prefix will be advertised on your LAN.
Then, using NETMAP target in custom firewall script you should be able to get the NPT working. See how it goes!
I have setup the PD on a subnet wihtout IPv6 and enabled forwarding, it's not working.
ip -6 route add default from 2a03:xxxx:xxxx:xxxx::/64 dev azire_wireguard
I see no RX traffic on the interface, even when attempting a ping from the Internet (that could be their inbound firewall, though). I'll have to inquire with them.
I'm not sure you realize, it's a Wireguard tunnel. And now that I'm using PD, my SRC IPs are not in the subnet anymore, remember?
So, can't use a "gateway IP."
Read the rule, it says 'from.' All my IPv6 rules are woreded EAXCTLY like this:
default from 2001:xxxx:xxxx:xxxx::/64 dev 6in4-henet proto static metric 1024 pref medium
default from 2001:xxxx:xxxx::/48 dev 6in4-henet proto static metric 1024 pref medium default from 2a03:xxxx:xxxx:xxxx::/64 dev azire_wireguard metric 1024 pref medium
2001:xxxx:xxxx:xxxx::/64 dev 6in4-henet proto kernel metric 256 pref medium
2001:xxxx:xxxx:xxxx::/64 dev br-lan proto kernel metric 256 pref medium
I don't need a table, as when I looked at my main table (above), all IPv6 rules already specified the SRC IPs. Therefore, the syntax above is accurate and showing on my route table.
ok, so I guess the "from" syntax is something I'm not familiar with, but it still seems to me that you want to specify some IP address that your wireguard provider should give you as the gateway, so that you're passing packets to some router in your provider's network.
For example, from the comprehensive 17 element list their API returns, you should get something like:
"ipv6_gw": "2a03:8600:1001:1060::1",
and that would be the address to give in the "via" portion of the route.
I think the result is different. With the rule you will send all traffic with that source prefix via the wireguard VPN. But in the case with source specific routing more specific routes (if there are any) will take precedence.
Well the end result should be that your azire_wireguard interface has the ipv6 address given in the "endpoint_ipv6_addr": "2a03:8600:1001:1337::1081" type entry, and the LAN or additional second LAN or whatever devices have IP prefix from the _pd entry. The LAN devices use your router as their "via", and your router uses the given GW from the API is its via.
Well, I suspect maybe their script figures it out by doing some curl request and plugs it in?
In any case, if a packet hits your router and needs to go to the wide internet, and needs to go over the VPN, you can't just broadcast it down the VPN tunnel... it needs to be sent to a router and so you'd probably want something like:
ip -6 route add default from 2a03:xxxx:xxxx:xxxx::/64 via GATEWAY_FROM_CURL_HERE dev azire_wireguard
and then your router is forwarding your packet to the VPN provider's router that was given to you in the API results and I'd expect a better result.