In the recent days, I realized my ISP offered IPv6 natively when my wan6 interface displayed an address.
After making sure I [re]enabled ICMPv6, etc., I was able to get an IPv6 /64 natively on LAN!
I even played around with getting IPv6 to a downstream ISP-provided router. I delegated a /62 to the interface/VLAN from wan6 and enabled DHCPv6, the device received a /63 PD and assigned a /64 each to its LAN and WAN, and made a Kernel route to the /63 via the other router's WAN link local IPv6 addresd - success!
Now Wireguard...I have a peer that only has a static IPv6 address at the hosting company. I noticed that the connection, even after reboots, chooses to establish a connection thru the 6in4 tunnel interface.
I can't yet remove or disable the tunnel, it is in use (good for static IPv6 addressing)
Removing the IP moved it to another interface...but that interface is assigned a Public IP from the tunnel's PD
I can make a route with a highermetric...I tested this...and yes the link local is static...but the ISP could have a failure, swap equipment, etc.
So perhaps someone knows how WG selects the interface...?
If I understand properly, you have 2 IPv6 interfaces. One 6in4 and one wan6. The wg peer is only ipv6 and you want it to connect on the OpenWrt from the wan6 interface, not 6in4. So far so good.
Are you using a hostname in peer address or the ipv6?
And you use the wan6 address to connect, but you worry that if it goes down you won't be able to fail over to the 6in4?
Chances are that if the wan6 has an issue, wan will have too, so 6in4 will not be available.
You can always use dyndns and change it to 6in4 when wan6 goes down
That's what I want to do. It's currently using the 6in4 tunnel and IP and PDs.
Huh?
I think you misunderstand. I want my WG interface to use native IPv6 on wan6 instead of the 6in4 to reach my peer at the hosting company. I see no way to set that except to make a route to the /128 with a higher metric than the Kernel made for WG automatically via the 6in4 tunnel.
Are you saying just setup DDNS on the far end and have it initiate connections?
The whole reason I had to use IPv6 anyways...was one end needed (I prefered one end have) a static IP (preferably not tunneled).
I think I misunderstood your concern. Is the problem that your OpenWrt is using as source IPv6 address for the wireguard tunnel the one of the 6in4, rather than the wan6? I thought that the problem was the opposite. Then scratch what I said before. This should be fixed with proper routing. Doesn't the 6in4 have higher metric (=lower precedence) than the wan6?
For IPv6 the metric doesn't matter much, routing decisions are based on the longest prefix match of your interfaces - to break out of that, you have to set up explicit routing tables/ policy based routing.
Right, since the ipv6 in OpenWrt is configured for source routing, it will always use the gateway corresponding to the address it uses as source.
I did a test and adding a static route for a specific host, in the main routing table nothing fancy, does the trick and changes routing via the desired interface.
I'm a little lost or maybe you agreed but missed the problem...maybe it's not really an issue (but I definitely want a native 1500 MTU and want to use my native interface IPs, so I definitely consider it an issue)...so let me describe and then get to what [at least as I can determine] is the issue I'm trying to solve.
I have 2 sets of IPv6 default routes - as @trendy notes, they are setup by SRC IP:
The 6in4 routes with its PDs as the SRC - metric 1024
The route via wan6 for native IPv6 - with its subnet noted as the SRC - metric 512
default from 2001:xxx:xxx:xxx::/64 dev 6in4-henet proto static metric 1024 pref medium
default from 2001:xxx:xxxx::/48 dev 6in4-henet proto static metric 1024 pref medium
default from 2xxx:xxxx:xxxx:xxxx::/56 via fe80::xxxxexxxx:xxxx:xxxx dev eth1 proto static metric 512 pref medium
In fact, ip route get fails unless I specify a SRC IPv6 address. Now - I have a WG interface whose remote peer is IPv6. Why does WG create a route to the /128 of the remote via 6in4 and not wan6?
xxxx:xxxx:xxxx:xxxx::x/128 dev 6in4-henet proto static metric 1024 pref medium
The only way I've been able to fix it was to make a route for:
xxxx:xxxx:xxxx:xxxx::x/128 dev <wan6> via <link_local_of_ISP_router> metric 512
When adding that route, after a few minutes - Wireguard started using wan6.
But why does WG use 6in4 initially...or even better...is there some way to change that?
Should I change a metric - and WG will then pick the other?
I assume any software using on my router will do this too, so it would be a concern again for other software that doesn't allow me to bind to an interface/IP
Ummmm...I must be horrible at explaining...covered that...it presents 2 possible problems:
And:
So basically, another software or another WG tunnel could do the same thing...next time it could be an address I don't know beforehand.
So, I tried to changed wan6's gateway metric setting - it didn't work
So I changed the tunnel's metric...but...
default from 2001:xxx:xxx:xxx::/64 dev 6in4-henet proto static metric 256 pref medium
default from 2001:xxx:xxxx::/48 dev 6in4-henet proto static metric 256 pref medium
default from 2xxx:xxxx:xxxx:xxxx::/56 via fe80::xxxxexxxx:xxxx:xxxx dev eth1 proto static metric 512 pref medium
And:
xxxx:xxxx:xxxx:xxxx::x/128 dev 6in4-henet proto static metric 256 pref medium
You mean if the ISP's link local changes (i.e. the physical ISP gateway device - my orginal concern)...?
That's the only static thing I don't control that could change. The only route6 I made was for the /128 (the /128 is a static IP, that's why I'm using it).
EDIT...but in that case wan6 would likely be down and the 6in4 metric will take presedence...?
If you are concerned that the IPv6 address of your remote wg endpoint changes, the easy solution would be to widen the route6 (to cover the whole data centre/ hoster). After all it shouldn't be much of a problem if connections to other servers in that data centre would be locked to the ISP IPv6 interface and not your he_net one - or do I miss the finer points of the problem?
If we wouldn't talk about connections initiated by your router itself, but a(n ethernet) client behind it, I'd simply filter out the he_net tunnel from that interface, but on the router you have to play with the routing (either the broad route6 approach or more fine grained policy based routing rules).
I'm concered my ISP would pull thier router...invalidating my wan6 route.
But that would only be temporary now that I think...and the 6in4 route would take over until I notoced.
Yea, I think you're missing the concern. You're troubleshooting the wrong end. But I understand, that's usually what we manipulate when helping others with WG.
The other concern is...it appears I'll have have to do this for any software on the OpenWrt that doesnt specify a bind IP/interface
EDIT: @trendy have you ever tried to set an IP with the WG listen port (dont think this will work in this case, but curious)?
No, I think it binds to all interfaces and I haven't seen any way to change that.
You could try to omit the link local IPv6 address as gateway. In the route6 use target and interface. Then it should use the gateway of the interface. If something breaks on wan6 and it goes down, the route is retracted and you will access it via 6in4.
Yea, I agree, and this actually makes sense to work should work if I keep the link local. If the link local neighbor disappears, then 6in4 should take over.
Link local addresses (like all IPv6 addresses) are layer 3 by the way.
And it should work:
uci add network route6
uci set network.@route6[-1].target='2a00:1450:4001:809::200e'
uci set network.@route6[-1].interface='wan6'
uci commit network
service network restart
as I also have a link local as gateway:
default from 2a0f:XXXX:XXXX:7500::/56 via fe80::30 dev pppoe-wan proto static metric 512 pref medium
2a00:1450:4001:809::200e dev pppoe-wan proto static metric 512 pref medium
...
root@magiatiko:[~]#ip -6 route get 2a00:1450:4001:809::200e
2a00:1450:4001:809::200e from :: dev pppoe-wan proto static src 2a0f:XXXX:XXXX:75:c477:c29c:130e:e988 metric 512 pref medium
In case it doesn't work due to broadcasting network, non ppp, use the option for source address in the static route.
