DNSFilter vs VPN (+VPN Director?)

[Lynx]

What is the best way to ensure that DNS queries that arise via DNSFilter such as:

Global Filter Mode: CleanBrowsing (Family)

Get routed through the VPN thereby to safeguard against exposing DNS queries to ISP?

The only way I managed to achieve this before was to specify:

Force Internet traffic through VPN: Yes

But this breaks things like spdMerlin that want to be able to run speed tests over WAN.

Is there a way to use:

Force Internet traffic through VPN: Policy Based Routing (Strict)

such that DNSFilter queries go through the VPN rather than over WAN?

One problem seems to be the difficulty in specifying any route over VPN having the origin as the router. It seems desirable to be able to have router traffic directed to WAN or VPN depending on destination.

Is the situation the same with the VPN Director? Take the very first line 'DNS through WAN' in in the screenshot provided here:

VPN Director

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

If the first entry were to instead 'DNS through OVPM1', with Iface set to OVPN1, the user would surely expect traffic originating from the router IP to the DNS IP to go over OVPN1, right?

Or is it as for PBR that even if rules require ought to mean traffic from router goes over VPN, in practice all traffic with origin set to router IP goes over WAN regardless?

 

[eibgrad]

Whenever you use PBR, it removes the router itself from the VPN. It's just a side-effect of how the feature is implemented. But if you want to force a specific destination IP over the VPN, like those of DNS, back to the VPN, simply add those IPs as PBR rules! Just make sure to NOT qualify the rule w/ a specific source IP.

 

[Lynx]

Thanks for the helpful input. So if I put the CleanBrowsing (Family) as a destination, will that mean that the router will go via VPN in respect of its DNS lookups to that destination?

 

[eibgrad]

You can't literally use the name CleanBrowsing (Family) in the rule. You need to determine what public IP is associated w/ that name by dumping the DNSFilter from the NAT table, where a DNAT rule is created for these purposes.

iptables -t nat -vnL PREROUTING
iptables -t nat -vnL DNSFILTER

When I do so myself, I get the following.

admin@lab-merlin1:/tmp/etc# iptables -t nat -vnL PREROUTING
Chain PREROUTING (policy ACCEPT 1333 packets, 262K bytes)
pkts bytes target     prot opt in     out     source               destination    
  664 39840 GAME_VSERVER  all  --  *      *       0.0.0.0/0            192.168.63.102 
  664 39840 VSERVER    all  --  *      *       0.0.0.0/0            192.168.63.102 
    0     0 DNSFILTER  udp  --  *      *       192.168.1.0/24       0.0.0.0/0            udp dpt:53
    0     0 DNSFILTER  tcp  --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpt:53

admin@lab-merlin1:/tmp/etc# iptables -t nat -vnL DNSFILTER
Chain DNSFILTER (2 references)
pkts bytes target     prot opt in     out     source               destination    
    0     0 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            to:185.228.168.168

IOW, 185.228.168.168 is the public IP of CleanBrowsing (Family) and needs to be the destination IP.

 

[Lynx]

Thanks for that. Ah yes, I meant putting the IP in the destination.

Are DNS requests the only major traffic originating from the router itself? I don't like my ISP having visibility of my traffic. That's one reason I preferred 'Force Internet traffic over tunnel: Yes' because it meant everything defaults over VPN, but that breaks at least spdMerlin, which need WAN for its bandwidth tests for autobandwidth calculation for CAKE, etc.

Happily it seems that making the explicit rules for the DNS servers I want to use as you suggested:

CleanBrowsing 1		185.228.168.168	VPN
CleanBrowsing 2		185.228.169.168	VPN

Does seem to ensure that the DNS queries get sent over the VPN.

Do the following tests demonstrate this sufficiently (I'm on LTE 4G, hence the private IP addresses - I never get a proper public IP):

admin@RT-AX86U-4168:/tmp/home/root# traceroute 185.228.169.168

traceroute to 185.228.169.168 (185.228.169.168), 30 hops max, 38 byte packets
1  10.8.1.1 (10.8.1.1)  50.737 ms  51.771 ms  48.861 ms
2  5.226.136.129 (5.226.136.129)  47.980 ms  52.685 ms  45.971 ms

5.226.136.129 <-- belongs to VPN provider

By comparison, the route to 8.8.8.8 just goes over WAN:

admin@RT-AX86U-4168:/tmp/home/root# traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1  192.168.8.1 (192.168.8.1)  0.744 ms  0.880 ms  0.780 ms
2  *  *  *
3  192.168.213.21 (192.168.213.21)  49.673 ms  48.856 ms  39.932 ms

Here is a tcpdump on the router on tun11 having issued an nslookup from my desktop computer:

admin@RT-AX86U-4168:/tmp/home/root# tcpdump -vpni tun11 |grep -i 185.228.168.168

tcpdump: listening on tun11, link-type RAW (Raw IP), capture size 262144 bytes
    10.8.1.4.37354 > 185.228.168.168.53: 44207+ PTR? 168.168.228.185.in-addr.arpa. (46)
    185.228.168.168.53 > 10.8.1.4.37354: 44207 1/0/0 168.168.228.185.in-addr.arpa. PTR family-filter-dns.cleanbrowsing.org. (95)
    10.8.1.4.49356 > 185.228.168.168.53: 27370+ A? www.try.com. (29)
    10.8.1.4.49356 > 185.228.168.168.53: 28138+ AAAA? www.try.com. (29)
    185.228.168.168.53 > 10.8.1.4.49356: 27370 5/0/0 www.try.com. CNAME proxy-ssl.webflow.com., proxy-ssl.webflow.com. CNAME proxy-ssl-geo.webflow.com., proxy-ssl-geo.webflow.com. A 3.248.8.137, proxy-ssl-geo.webflow.com. A 52.49.198.28, proxy-ssl-geo.webflow.com. A 52.212.43.230 (137)
    185.228.168.168.53 > 10.8.1.4.49356: 28138 2/1/0 www.try.com. CNAME proxy-ssl.webflow.com., proxy-ssl.webflow.com. CNAME proxy-ssl-geo.webflow.com. (171)

 

[eibgrad]

Are DNS requests the only major traffic originating from the router itself? I don't like my ISP having visibility of my traffic. That's one reason I preferred 'Force Internet traffic over tunnel: Yes' because it meant everything defaults over VPN, but that breaks at least spdMerlin, which need WAN for its bandwidth tests for autobandwidth calculation for CAKE, etc.

When NOT using PBR, the router itself remains bound to the VPN by all its processes for all internet-bound traffic. It is, after all, the actual OpenVPN client and is only allowing clients on the LAN behind it to leverage the tunnel for their own purposes.

However, once PBR is active, the router removes itself from the VPN and defaults back to the WAN for all those same processes. As I said, that's simply the way its been implemented. But that can have negative consequences, such DNS leaks. It's unfortunate, but users just need to be aware of this behavior when it comes to using or not using PBR and adjust accordingly.

So yes, this can affect *any* internet-bound traffic initiated by the router, from whatever processes, be it DNSMasq or additional firmware features.

 

[Lynx]

Yes. So with PBR default is WAN and exceptions have to be made for VPN. I would rather have it the other way round. Seems more logical to me. Is that achievable in Asus Merlin without heavy script stuff?

If I set force internet traffic to yes, then that gives me the desirable VPN default, but that breaks spdMerlin which expects to be able to access WAN. I like spdMerlin because it helps regulate my bandwidth settings for CAKE for my bandwidth fluctuating 4G connection.

Is there a workaround for that I wonder? I mean can I set router to default to VPN and yet somehow make an exception for spdMerlin?

 

[eibgrad]

You can't change the behavior of the GUI in this respect. You'd have to script your own PBR to achieve the opposite behavior.

That said, it is possible to force all traffic over the VPN, yet route specific destination IPs over the WAN using static routes. Perhaps that will be sufficient for the purposes of spdMerlin (I've never used it). You just have to identify the public IPs it uses.

 

[Lynx]

Ah yes static routes in the OpenVPN config? I've done that before using something like:

route 192.168.8.1 255.255.255.255 net_gateway

That sets up WAN route to my modem.

spdMerlin uses speedtest.net but it has an autoserver selection so might be too complicated to set up this way.

I'm sure there's some form of elegant solution here.

 

[eibgrad]

speedtest.net is NOT the public IP that matters. It's the *servers* it accesses that need to be bound to the WAN. And so yes, that makes it tricky to configure.