I want my OpenWRT to use a WireGuard tunnel in combination with PBR. However, I have never got it to work correctly, always receiving timeouts. With more websites switching to IPv6 it became ever more frequent and I have a strong suspicion it happens because OpenWRT is happily giving out publc addresses from the ISP's provided batch and all my IPv6 clients are attempting to bypass the tunnel with their public IPv6 address, resulting in OpenWRT dropping those packets.
I want to test that theory by preventing this behavior. My internal clients should only receive a local IPv6 address from my router and any IPv6 connection attempt to a public address should be routed through the router's public-facing IPv6 address.
Problem is, my IPv6 skills are not high enough to know how to do so. Do I simply turn off delegation on the wan6 or lan interfaces? Do I set the prefix filter to only the ULA range? Do I need some kind of relay configuration? Masquerading?
Please help!
In the meantime I found these 2:
And it would appear that between @mk24 en @egc I can probably figure out how to make this work even with the ISP-assigned block of addresses. Still, the exact steps to follow seem to elude me at this time.
Your theory almost certainly is correct to an extent, since unless explicitly configured not to do so, both Linux and Windows will prefer IPv6 connectivity where it's available and if you have a rule sending IPv6 via the tunnel and the tunnel is not working properly with IPv6, you could expect to see exactly the symptom you're seeing.
The solution isn't to disable IPv6. It's to fix the wireguard tunnel. Is your wireguard tunnel your own private one to a peer host you control, or it is to a commercial VPN provider? Does your IPv6 connectivity actually work properly without the attempted routing via wireguard?
Not all commercial VPN providers will necessarily support IPv6 in wireguard tunnels. If they do support it, then it's just a configuration issue. If they don't support it, then you could set the network stack on your clients to prefer IPv4 connections over IPv6 connections.
Given that wireguard is a routed protocol, with explicit IP assignments on both sides, I can't really imagine how an undesired prefix would cross the tunnel.
@dl12345 Yes, my Wireguard is to a commercial provider which provides both an IPv6 entry point for my router and an IPv6 exit address on the outside. Just the one. So if I can force all my routing across the router's gateways, I can control IPv6 traffic to go either through the WAN or VPN exit.
From reading those threads I believe I need some form of NAT6 and prevent the ISP's range from being assigned.
Or it might be a simple case of setting the ISP's range as allowed IP's on the WireGuard interface, I honestly don't know.
Well, my previous setup had 8000::/1 in there but not ::/1 and it used the advanced firewall setup with all the same options. That at least did not work well.
Well, I did not technically forget it, I merely neglected to set it in its entirety.
I will set it and see what happens. That said, I still feel "safer" if there was not an ISP-assigned IP address on my host. Meaning I will continue looking for a way to do that as well, which is made harder by not knowing which search terms to use.
End to end reachability and global uniq addressing of participants in packet switched networks is a core principle.... Its the same with ipv4. But people seam to ignore that that fact because NAT have spoiled them
Not any I have seen fit to rely on thus far. So I would need NAT6?
By the way, my VPN provider gave me ::0/1 so neither ::/0 or ::/1. I am assuming that would be identical to ::/1 and the 0 is simply ignored? I have now set all 4 in my config, see what happens.
I would agree with @_bernd that, technically there should be no need for NAT66.
But in the real world, particularly where ISPs, VPN providers etc don't handle ipv6 well, sometimes NAT66 is essential for an easy and reliable life.
When I need to switch it on, I do it with this command string:
echo "set $(uci show firewall | grep "masq='1'" | sed 's/masq/masq6/')" | uci batch
Then, to test, do:
service firewall restart
If it all works, make it permanent:
echo "set $(uci show firewall | grep "masq='1'" | sed 's/masq/masq6/')" | uci batch
uci commit firewall
service firewall restart
However, even though address space is huge, /64 delegations are immensely wasteful and some ISPs are running out of their RIR registered allocation. Some share a smaller allocation within associated groups of ISP's so rather than pay for more are limiting availability to end users.
End user availability of ipv6 is on the steep part of the S curve, so pretty much exponential at the current time. Oddly, availability of services, eg web servers supporting ipv6 is pretty flat...
A question that should be asked is "Does ANY end user need the 18 quintillion individual IPv6 addresses they get with every /64 delegation?".
Unless ISPs get their act together we are heading rapidly into an ipv6 delegation crisis.
I am definitely getting a more stable connection now it seems, with less dropouts. But a downside is that I don't seem to have control over which IP they get. Which complicates giving access to certain systems on my servers.
I prefer working with static leases so I can control it from a centralized place, OpenWRT in this case. It gives my suffix to the ULA addresses but not the ISP's PD addresses. Though technically those 2-4 digit suffixes should be available.
Being unable to control the suffix has an added annoyance, as I won't be able to set them in PBR. I can set the hostname, but if I do that I need to restart PBR so it resolves the hostname to the correct address (and hope it remains stable). I can also create a firewall rule with a mac address but that would override PBR I think. And I don't believe I can add a MAC as a src for PBR rules.
