The script runs on a desktop, NOT A ROUTER. I'm using OpenWRT.
Do you think that a script magically makes a tunnel have a gateway?
It's not Enterent.
That is not the case...of course you can send a layer 3 packet down a tunnel, ALL LAYER 3 TUNNELS WORK LIKE THIS!
Why do you think not???
It works with all other IPv4 and IPv6 providers, INCLUDING MY WORKING HURRICANE TUNNELBROKER SETUP, which forwards a /48 (for mutiple LANs), a /64 (my initial allocation) and a /128 (my side of the HE tunnel) to my border.
I just don't know anything about their script, but they mention it on their page. I'm assuming if you're not using the script, then whatever the script does, you need to manually do instead. Since the script is in a turing complete language, it could "magically" do just about anything you can do manually, including adding routes.
Yes, you can send a packet down a tunnel, but there's no reason to think that at the other end they will do anything other than drop it on the floor if you don't send it to the right place.
I have an HE tunnel set up on one server, and it's default ipv6 route looks like:
default via 2001:xxx:xxx:xxx::1 dev he-ipv6
you'll notice it has a "via" because it needs to send packets to a router, and HE gives you a gateway address in their setup page. I assume unless there's something kind of magical about your VPN software, that it also needs to hit up a gateway router whose address is provided in the 17 element response from the curl API result.
It should be noted, that this is still Work In Progress. I figured out the prefix translation part rather quickly, but without proper prefix announcements and correct dynamic routing it won't work very well.
default from 2001:470: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
Also, directly from Tunnelbroker.net's example setup page for OpenWRT:
opkg update
opkg install 6in4
uci set network.henet=interface
uci set network.henet.proto=6in4
uci set network.henet.peeraddr=xxx.xxx.xxx.xxx
uci set network.henet.ip6addr='xxxx:xxxx:xxxx:xxxx::2/64'
uci set network.henet.ip6prefix='xxxx:xxxx:xxxx:xxxx::/64'
uci set network.henet.tunnelid=xxxxxx
uci set network.henet.username=xxxxxxxxxxx
uci set network.henet.password='UPDATE_KEY_OR_PASSWORD'
uci commit network
uci set firewall.@zone[1].network='wan henet'
uci commit firewall
/etc/init.d/network restart
/etc/init.d/firewall reload
There is no gateway on a Layer 3 tunnel, the remote end simply firewalls to drop traffic on the floor, no gateway is needed, as the tunnel is between 2 points, the interface itself is the "gateway" to the VPN network. There's only one "right place" in a tunnel, the other end.
EDIT: Recall, I have a /128, a /48 and a /64 - so how would they firewall that, and how would I specify a gateway that isn't located within 2 of 3 the subnets that receive over the same tunnel???
All I can tell you is that my HE tunnel uses a via in its route setup, and it works. Perhaps the HE tunnel works without a via as well... but this does not guarantee that the VPN provider also does the same thing. Your tunnel is part of a /64 you could have 180 million other VPN subscribers all on that same /64 via a bridge... I mean, theoretically. If there's only one place in the tunnel to go, why even put ip addresses in the tunnel?
But it's easy to test, you could in fact just try manually changing your route and seeing if it changes anything. If it doesn't then maybe I'm the one confused, and if it does change something then maybe there's something else going on.
But finding out how your VPN people firewall things and whether the PD you got from the API query is in fact usable, or if it needs some kind of dhcp-pd query to be activated, or the like could be useful. I think maybe I've come to the end of what I can help you with considering that I don't also have this particular kind of VPN.
Reading up a bit about wireguard: https://www.wireguard.com/ in the plain-english description, it appears there's a step:
"Once decrypted, the plain-text packet is from 192.168.43.89. Is peer LMNOPQRS allowed to be sending us packets as 192.168.43.89?"
so the main question is whether their server is configured to allow you to send packets as addresses inside the _pd range you got from the API...
Note, the wireguard page is pretty convincing that it's a good system. It sounds quite nice. I'll look into whether I want to convert my own OpenVPN. I find OpenVPN to be a bit of a behemoth. It works, but is hard to audit.
Looking further, I see what you mean about it being a layer3 tunnel and there's no need for a gateway. the gateway is there to tell layer 2 networks how to find a layer 2 address of a gateway (by ARPing or by NDPing for the given layer 3 address) but when you're just sending layer 3 packets inside a layer 3 packet (ie. an IP packet inside a UDP packet) there's no concept of a gateway. Hadn't thought too much about it, but that makes sense.
I think it's really all down to ensuring that the _pd network is something Azire is actually letting you use / allowed subnet config as you say.
The other is this...maybe I can only send IPv6 traffic over the IPv6 endpoint address; but that seems odd, and as if their endpoint is (again, as in point 1) improperly configured.
I noticed, I see no TX on IPv6 either...even when I test making a route for the assigned /128 and ping6 from the router...this could even be in Wireguard...you mentioned:
I just mean auditing the config, not even the code. In openvpn there are many possible configs, what with all the pushing configs per client and the pushed routes and soforth
