Looks good to have encrypted DNS policy too.
Another privacy concerns though at least when trying to use Split Tunneling.
I've setup a policy for several domains (fast.com and speedtest.net among them) to be accessed via VPN.
But when I visit fast.com and speedtest.net firstly I can see the VPN provider network and VPN IP address detected by both domains, something that probably a layman would expect and at this point he/she thinks everything looks OK (no privacy leak issues, etc.).
Strange for me is that running both speed tests I can achieve my full ISP line speeds. Something that I don't expect as it is 1 Gbps. And the test servers are really close to my real location (very strange as the VPN server is in different country).
Additionally (and my big privacy concern) is that on speedtest.net for example if I look at the test details I can see my public (external) ISP IP address detected (What? How come?).
For me at this point it looks as an absolute privacy data leak and should raise a very big ALERT!
I've setup another policy for a torrent port (I don't have nor use UPnP nor NAT-PMP on the router and both are off in torrent client) and running a torrent client on a PC, it initially shows "Detected external IP. IP: "VPN IP" address" in its log but then there are many messages showing my public ISP IP address.
Looking at WireGuard Status page in Luci there are data fields showing Received/Transmitted Data. But they read a few megabytes (tests used over 1G) counted, making me think that almost 99% of the data flows via WAN interface not the VPN WG one as I expect,
simply run a tracert/traceroute from you client to speedtest.net
This is from my client in switzerland connected to my WG server in the Netherlands, you can see that the first hit is the WG subnet
PS C:\Users\egc> tracert speedtest.net
Tracing route to speedtest.net [151.101.130.219]
over a maximum of 30 hops:
1 28 ms 30 ms 32 ms 172.21.21.1
2 32 ms 30 ms 29 ms 192.168.0.1
3 * * * Request timed out.
4 40 ms 39 ms 39 ms tb-rc0001-cr101-et89-201.core.as33915.net [213.51.194.49]
5 * * * Request timed out.
It could be you are leaking IPv6 or that not all IP addresses are resolved of speedtest,net
In my case second hit is the WG subnet, first one is the router. I assume it's OK.
From Linux PC with IPv6 disabled
traceroute to speedtest.net (151.101.2.219), 30 hops max, 60 byte packets
1 OpenWrt.lan (192.168.1.1) 1.403 ms 1.315 ms 1.233 ms
2 * * 10.10.0.1 (10.10.0.1) 90.491 ms
3 * * *
4 * * *
5 * * et-0-0-18.edge7.Amsterdam1.Level3.net (213.19.194.193) 92.463 ms
6 * * *
From Windows PC IPv4 & IPv6
C:\Windows\System32>tracert speedtest.net
Tracing route to speedtest.net [2a04:4e42:400::731]
over a maximum of 30 hops:
1 Destination net unreachable.
Trace complete.
From Windows PC IPv4 & IPv6 directly to speedtest.net IPv4 address.
C:\Windows\System32>tracert 151.101.66.219
Tracing route to 151.101.66.219 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms OpenWrt.lan [192.168.1.1]
2 90 ms 45 ms 44 ms 10.10.0.1
3 44 ms 44 ms 44 ms 93-190-138-187.hosted-by-worldstream.net [93.190.138.187]
4 45 ms 46 ms 44 ms 109.236.95.226
5 * 46 ms 46 ms 5-2-3.ear4.Amsterdam1.Level3.net [212.72.41.249]
6 46 ms 46 ms 46 ms 213.19.200.114
7 47 ms 46 ms 46 ms 151.101.66.219
Trace complete.
It's the same from Android smartphone connected to WLAN (10.10.0.1 is second hit) but exactly on it I can see my external IPv4 address. As if the speedtest.net redirects the client (smartphone) to another server (domain) using WAN route that next detects my external IP.
So isn't this defeating the purpose (mainly privacy) of the VPN Split Tunneling?
This is also the problem with netflix, a redirection of netflix.com is not sufficient there is a whole bunch of other netflix domains which need to be redirected
Yep, most of them are here. www.netify.ai/resources/speedtest
I've made more tests and for my purpose it seems that currently it is better to use a policy that uses a local address (192.168.1.51 on my PC) to tunnel all the data (not only several domains) through the VPN.
Just an update. Originally my /etc/pbr.custom.user was only setup to ensure inter vlan routing was still working with pbr working as in the past this wasn't the case. Am I right in saying this isn't required any more as when I disable /etc/pbr.custom.user inter vlan routing still works. Despite this, still having the same problems with pbr not running unless VPN gateway is up.
Another update (not sure if this was obvious). Using nft -c -f /var/run/pbr.nft, I found the failure to install the fw4 nft file is caused by the rules which are the rules pushing traffic to the gateway which is down (NORDVPNTUN). Not sure what can be done about this... Also noticed that the issue occurs when Strict enforcement is set to do not enforce.
tor works with and without pbr (see curl listing in my message above).
Problem is pbr can't start with rule with tor interface due incorrect nft syntax.
You are not doing anything wrong, there seems to be a bug in that version for tor policies. I'll try to implement a fix and merge changes within 24-48 hours.
I've just compiled a build with latest PR - PBR 1.1.7-21.
I need a little help with IPv6.
My VPN now supports IPv6. I've added all the settings from VPN provider to the wireguard settings - IPv6 ULA ( IPv6: fd::xx:2/128), IPv6 DNS ( IPv6: fd::xx:1), and allowed addresses (::/0) in WG peer settings.
Then I created a policy rule for IPv6 addresses to go through WG VPN. But it still cannot work as I expect.
I suppose my IPv6 rule is not good. As one client (PC) can have multiple IPv6 addresses at the same time I've tried to list all of them in my rule (even added a rule with PD from my ISP - xxxx:85b8:22e:xxa::/64) but still the connection goes through the default WAN gateway.
How is the split tunneling (policy rule) supposed to work with IPv6 as there is no NAT similar to that used with IPv4.
Do I need to have IPv6 ULA-Prefix in OpnWrt Global network options. I removed it few months ago because I didn't use it.
For Wg ipv6 do the following
Enable masq6 on the wg firewall zone (advanced tab)
For allowed ips use 8000::/1 and ::/1 instead of ::0/0
Disable pbr and restart network and test with iplek.net if ipv6 works
For pbr with source routing of individual clients use the mac address of the client much easier
Making this change IPv6 works. But ipleak detects my public IPv6 address.
Using mac address in the rule is really simpler but I'm unable to make it work when the WAN is default gateway.
When I set WG to be default gateway everything works as I expect - both IPv4 and IPv6 detected are the ones of the VPN provider and DNS is VPN one too.
