Routing DNS over VPN

[Lynx]

I want to use NordVPN for VPN + CleanBrowsing for DNS.

I have set Accept DNS Configuration to: DISABLED

In VPN I have set Policy Rules (Strict)

And have entered only:

LAN	192.168.1.0/24		VPN
Modem	192.168.1.0/24	192.168.8.1	WAN

Under WAN I have tried setting DNS to manual and entered the CleanBrowsing DNS server addresses.

I fail leak tests, but shouldn't the above policy rules mean that the DNS requests to CleanBrowsing are sent via the VPN tunnel, i.e. from 192.168.1.1 through VPN?

Further thought: perhaps I am being dumb. Just because CloudFlare shows up on DNS leak test sites doesn't mean that the DNS requests are not going through my VPN does it?

How do I test to verify that the DNS requests are indeed being routed via the VPN?

As long as DNS is going through the VPN is there any point at all in using DNS over TLS? I mean does that mean data is encrypted twice: 1) via DOT; and then 2) over VPN? Presumably a possible benefit would be preventing the VPN provider from logging your DNS queries?

 

[Chuckles67]

This post might help: https://www.snbforums.com/threads/dns-over-tls-nextdns-openvpn.70133/page-2
See the comment about using traceroute

 

[Lynx]

Thanks.
So with policy rules set as:

LAN	192.168.1.0/24		VPN
Modem	192.168.1.0/24	192.168.8.1	WAN

From windows command line:

tracert 1.1.1.1

Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms RT-AX86U-4168 [192.168.1.1]
2 53 ms 59 ms 41 ms 10.8.1.1
3 54 ms 49 ms 44 ms 5.226.136.129
4 54 ms 55 ms 57 ms ae1.rt0-thn2.ldn.as25369.net [5.226.136.38]
5 54 ms 60 ms 57 ms lonap.as13335.net [5.57.81.75]
6 45 ms 53 ms 60 ms one.one.one.one [1.1.1.1]

Trace complete.

This looks good - going through VPN.
From router via SSH:

admin@RT-AX86U-4168:/tmp/home/root# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
1 192.168.8.1 (192.168.8.1) 0.668 ms 0.844 ms 0.769 ms
2 * * *
3 192.168.213.21 (192.168.213.21) 45.342 ms 45.600 ms 50.943 ms
4 192.168.213.22 (192.168.213.22) 49.853 ms * *
5 * * *
6 * * *
7 * 63.130.105.110 (63.130.105.110) 54.798 ms 54.686 ms
8 ixmanchester.as13335.net (195.66.244.71) 60.928 ms 45.794 ms 50.063 ms
9 162.158.32.9 (162.158.32.9) 49.826 ms 162.158.32.11 (162.158.32.11) 51.855 ms *
10 one.one.one.one (1.1.1.1) 55.102 ms 52.920 ms 48.946 ms

This is not going through VPN I do not think.
Does this help(?):

admin@RT-AX86U-4168:/tmp/home/root# ip route show table ovpnc1
default via 10.8.1.1 dev tun11
10.8.1.0/24 dev tun11 proto kernel scope link src 10.8.1.5
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
239.0.0.0/8 dev br0 scope link

 

[Chuckles67]

There's a comment in the link I shared: says doesn't work when you specify a source IP. Perhaps that's your situation. The link suggests to only specify a destination IP.

 

[Lynx]

OK yes thanks - it seems just setting source 192.168.1.0/24 to VPN (without setting destination) works for client devices, but doesn't work from the router to DNS.
But I have found that further including the destinations manually:

LAN	192.168.1.0/24		VPN
CB Family 1		185.228.168.168	VPN
CB Family 2		185.228.169.168	VPN
Modem	192.168.1.0/24	192.168.8.1	WAN

seems to work - traceroute from router via SSH shows tunnel used in respect of either DNS IP.
Something I completely don't understand is the following. Traceroute from my router to external IP outside tunnel means that the next few hops include private IP addresses on the Vodafone network (see the traceroute above). But with the VPN the very next hop after my modem is to the VPN IP. Does that make sense?
Also isn't there a way just to route all IP from my router to any destination through VPN? I tried setting an explicit VPN rule in respect of source 192.168.1.1 without destination, but that didn't work either. What if I want all router traffic to go through the VPN?

 

[eibgrad]

Several points, in no particular order of importance (you raised many questions).

1. Do NOT depend on the results of online leak testing tools. Remember, your client is NOT the one that accesses the public DNS servers directly. It's only indirectly, via the router's DNS proxy (DNSMasq). That makes any determination by third-party tools highly suspect. The only means I've ever found to know w/ certainty is to dump connection tracking (cat /proc/net/nf_conntrack). Or perhaps traceroute/tracert. At least these tools are immediately associated w/ this process.

2. IMO, if you use any DoH/DoT solution, there's much less (if any) concern about whether your DNS traffic is sent over the WAN or VPN. Take your pick. Either way, it's encrypted. The issue is when you DON'T use DoH/DoT, but standard ol' port 53 DNS in the clear. NOW it matters.

3. Something many ppl don't realize is that by using Routing Policy rules, this removes the router itself from the VPN! Any processes the router is running are bound to the WAN, NOT the VPN. That's what often causes DNS leaks. And why it's recommended you bind your DNS servers to the VPN explicitly via Routing Policy. At least for the purposes of DNS, now all your DNS queries, whether from the router itself or clients on the network, are routed over the VPN.

4. Because the router is no longer bound to the VPN once Routing Policy is in effect, you can't simply bind its LAN ip (192.168.1.1) w/ a rule that rebinds it to the VPN. Unlike the LAN clients, the router isn't using the LAN network interface to access the internet; it's using the WAN or VPN since it's hosting these. From the perspective of the router, the LAN interface is only used to interact w/ LAN devices, which is NOT the issue you're trying to resolve.

 

[Lynx]

That is extremely helpful, informative and interesting - thank you.
Forgive me for my ignorance, but when a client device accesses an internet page, is it not the case that the client device itself makes the request for the DNS lookup in the same way that it makes the request for the data - so in respect of this 'LAN interface' you describe, why is there a distinction between client DNS queries and client data, with only the latter being sent over VPN by default? As in, if the router sends the data over VPN by default, why does it not also send the DNS over VPN by default since it is always originating at the client? I think there must be something about the way DNS works that I am missing here in terms of your explanation. I am also confused as to why in the Policy Rules page it is described to explicitly make the router not go via VPN - that is the opposite of what I had expected for my use case in which I am not bothered about accessing my network from the outside.

 

[sbsnb]

Because the LAN clients send the DNS request to the router. The router then performs the actual DNS lookup. As far as routing is concerned it is the router doing the lookup. If you don't have any routing policies for the VPN then the router does send all traffic over the VPN. Once you set a policy that is no longer the case.

 

[eibgrad]

Forgive me for my ignorance, but when a client device accesses an internet page, is it not the case that the client device itself makes the request for the DNS lookup in the same way that it makes the request for the data - so in respect of this 'LAN interface' you describe, why is there a distinction between client DNS queries and client data, with only the latter being sent over VPN by default?

Yes, the client makes the DNS request, but what matters is who handles the request.

By default, your LAN clients are NOT directly accessing the public DNS servers. Your LAN clients are configured w/ the LAN ip of the router (192.168.1.1) as their DNS server. The router is managing its own *local* DNS server, which acts as a proxy server for the LAN. Every LAN client is making DNS queries to the router, which in turn make DNS queries to the public DNS servers you have configured w/ the router. And if the router itself is NOT bound to the VPN (which is what happens when you enable routing policy), then it's possible the router is accessing those DNS servers (on behalf of those clients) over the WAN. It depends on several other factors in the configuration as to whether that's actually the case.

Any NON DNS requests are sent directly on through to the WAN or VPN, depending on how you've configured routing policy.

 

[Lynx]

Ok great answers thank you.
The only reason I initially set up Routing Policy was because I need to access my modem on 192.168.8.1 - could I do that with a static route instead and keep everything routed through to the VPN?
I don't understand why setting up the routing policy means that the router itself is NOT bound to the VPN <- what is the logic behind this? From a security perspective would it not be better for everything including router to go through VPN by default? I think the info pages / Routing Policy is misleading because when you specify 192.168.1.0/24 I think you expect that to include the router, and in the pages it even specifies including an exclusion for the router 192.168.1.1 -> VPN - so I expected absent the exclusion the router to get included. So what's the point in the exclusion if it's already excluded. Doesn't feel right.

 

[sbsnb]

I don't understand why setting up the routing policy means that the router itself is NOT bound to the VPN <- what is the logic behind this?

I suspect it would be difficult for the router to send traffic over the WAN if it was "inside" the VPN. In other words, it couldn't do the routing from inside.

 

[eibgrad]

Ok great answers thank you.
The only reason I initially set up Routing Policy was because I need to access my modem on 192.168.8.1 - could I do that with a static route instead and keep everything routed through to the VPN?
I don't understand why setting up the routing policy means that the router itself is NOT bound to the VPN <- what is the logic behind this? From a security perspective would it not be better for everything including router to go through VPN by default? I think the info pages / Routing Policy is misleading because when you specify 192.168.1.0/24 I think you expect that to include the router, and in the pages it even specifies including an exclusion for the router 192.168.1.1 -> VPN - so I expected absent the exclusion the router to get included. So what's the point in the exclusion if it's already excluded. Doesn't feel right.

It's complicated. It has to do w/ the way routing policy is implemented.

Normally, when NOT using routing policy, the main routing table has its default gateway changed from the WAN/ISP to the VPN, so the router and all clients behind the router are bound to the VPN. Pretty simple and straight-forward.

However, when you enable routing policy, the main routing table remains bound to the WAN/ISP. The router creates a secondary routing table that has the VPN as its default gateway. It then binds only those items you've described in routing policy to that secondary routing table, which does NOT include the router. At least NOT unless you specifically specify it.

But here's the rub. The router is a special case. Unlike the rest of 192.168.1.0/24, the router is hosting the internet-bound network interfaces (WAN and VPN), and NOT accessing the internet via its LAN network interface (192.168.1.1). So adding a rule that binds 192.168.1.1 to the VPN is meaningless. If routing policy is enabled, and the router needs access to the internet, it is unlikely it's going to be using 192.168.1.1, but instead the public ip on the WAN. IOW, the actual outgoing packets will have that public IP on the WAN as their source, NOT 192.168.1.1.

In short, what most ppl are failing to recognize is the router is NOT like any other LAN device. But when you specify "192.168.1.0/24 VPN" or "192.168.1.1 VPN" as a rule, that's what you're assuming. Again, it's *hosting* the internet-bound network interfaces, and that changes how the router is bound to the internet compared to the rest of the network.

 

[Lynx]

Fascinating.

However, when you enable routing policy, the main routing table remains bound to the WAN/ISP. The router creates a secondary routing table that has the VPN as its default gateway. It then binds only those items you've described in routing policy to that secondary routing table, which does NOT include the router. At least NOT unless you specifically specify it.

Could it work instead that with routing policy enabled the main routing table remains with VPN and the secondary routing table is bound to the WAN/ISP? Or does this not make sense / creates an impossibility?
I presume that I could have not enabled routing table then set up static route to my modem (192.168.8.1) on different subnet from router (192.168.1.1) or would that also not have been possible?

 

[eibgrad]

Could it work instead that with routing policy enabled the main routing table remains with VPN and the secondary routing table is bound to the WAN/ISP?

Yes. In fact, I've written my own routing policy scripts for DD-WRT and FreshTomato that do just that! Using my scripts, the user has the option to chose which network interface is the default. Just take a look at my FreshTomato scripts. Instruction #7 is all about this issue.

tomato-ovpn-split-basic.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

tomato-ovpn-split-advanced.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

I purposely default to the VPN because I don't like the idea of removing the router from the VPN. But I can't change how developers choose to implement their own routing policy in the GUI. And in every case, Merlin, DD-WRT, and FreshTomato, they *all* default the router to the WAN/ISP. But you will find some users complaining about it, and requesting the other option.

OpenVPN - Reverse policy-routing (a.k.a. split-tunneling)?

I was wondering how easy/difficult would be to have an opt-out policy routing. Currently these two scenarios are possible within Tomato - Redirect all traffic through VPN - Redirect only policy-routing sites/IPs through VPN (relaxed/strict) Perhaps there's a way to also have a new scenario...

www.linksysinfo.org

So far, I've failed to see any developers take up the challenge.

I presume that I could have not enabled routing table then set up static route to my modem (192.168.8.1) on different subnet from router (192.168.1.1) or would that also not have been possible?

You lost me when it comes to 192.168.8.1. I never understood what that was all about, esp. wrt this issue w/ routing policy.

 

[Lynx]

Many thanks - very interesting.

You lost me when it comes to 192.168.8.1. I never understood what that was all about, esp. wrt this issue w/ routing policy.

I have router (192.168.1.1) -> modem (192.168.8.1) -> internet.

And I want client devices behind the router to be able to access the web page of the modem, which is on a different subnet. With the default VPN configuration I cannot access the modem.