DNS-over-TLS (NextDNS) & OpenVPN

[trekkie3214543]

Hello,

I am running the latest Merlin on an AC86U.

I am running an OpenVPN connection with DNS set to Exclusive and it uses the VPN's DNS as expected

I then set up DNS-over-TLS with NextDNS and set the OpenVPN DNS to disabled as per the Wiki.

My expectation was that the DNS-over-TLS connection would take place within the tunnel. However, when I look at the NextDNS logs, it shows the source IP from my ISP. I was under the impression that DNS-over-TLS would work through the OpenVPN tunnel but it doesn't seem to be the case.

Am I wrong in my understanding of how DNS-over-TLS and the OpenVPN tunnel on Merlin should work?

Thanks.

 

[eibgrad]

Are you using PBR (policy based routing)?

 

[trekkie3214543]

Are you using PBR (policy based routing)?

Yes, I am using Policy based routing

Force Internet Traffic through Tunnel -> Policy Rules (strict)
Block routed clients if tunnel goes down -> Yes

and the one rule being

192.168.xx.0/24 -> 0.0.0.0/0 (Iface -> VPN) [so all clients through the VPN]

 

[eibgrad]

One of the side effects of using PBR is that it takes the router itself OFF the VPN! As a result, all its internal processes revert back to the WAN. IOW, when using PBR, quite literally the *only* devices using the VPN are those defined in the PBR rules.

You commonly see this w/ things like Transmission (not sure Merlin supports this), where that app is now using the WAN when obviously you expect to have it use the VPN. I suspect the same thing is happening w/ DNS-over-TLS.

P.S. And the fact the router's LAN ip is included in PBR (either explicitly or implicity) doesn't help. Most of those internal processes are NOT bound to the LAN, but the WAN.

P.S. I'll have to dig a little deeper to confirm my suspicions. I don't normally use DNS-over-TLS.

 

[New2This]

P.S. I'll have to dig a little deeper to confirm my suspicions. I don't normally use DNS-over-TLS.

What do you use?

 

[eibgrad]

I'm just using good ol' DNS.

Here's what I found (I'm only now learning about NextDNS). As I understand it, you need to install it on the router and it runs a local proxy, which then DNSMasq is configured to call. When I set it up for myself, it appears to tell you (on their website) the actual DNS server(s) you'll be referencing (in my case, its 4bb5a2.dns.nextdns.io). So try adding those DNS servers to the OpenVPN client custom config field as route directives which will bind them to the VPN.

route 4bb5a2.dns.nextdns.io 255.255.255.255 vpn_gateway

 

[trekkie3214543]

One of the side effects of using PBR is that it takes the router itself OFF the VPN! As a result, all its internal processes revert back to the WAN. IOW, when using PBR, quite literally the *only* devices using the VPN are those defined in the PBR rules.

You commonly see this w/ things like Transmission (not sure Merlin supports this), where that app is now using the WAN when obviously you expect to have it use the VPN. I suspect the same thing is happening w/ DNS-over-TLS.

P.S. And the fact the router's LAN ip is included in PBR (either explicitly or implicity) doesn't help. Most of those internal processes are NOT bound to the LAN, but the WAN.

P.S. I'll have to dig a little deeper to confirm my suspicions. I don't normally use DNS-over-TLS.

Thank you, this makes sense.

I stopped using PBR and just chose "Force Internet Traffic through Tunnel" -> Yes and set the OpenVPN DNS to disabled and the NextDNS logs show the DNS over TLS connection going through the OpenVPN tunnel.

PS: Too bad though about PBR resulting in DNS-over-TLS outside the OpenVPN tunnel, now I got to decide whether I want to block crappy ads with NextDNS or have a situation where my clients are exposed if the VPN goes down. Though technically, with PBR, the DNS query goes through DNS-over-TLS on the WAN iface and the rest of the connection goes through the VPN tunnel so both parts are still invisible to my ISP (I think).

 

[eibgrad]

Did you see my last post?

 

[trekkie3214543]

I'm just using good ol' DNS.

Here's what I found (I'm only now learning about NextDNS). As I understand it, you need to install it on the router and it runs a local proxy, which then DNSMasq is configured to call. When I set it up for myself, it appears to tell you (on their website) the actual DNS server(s) you'll be referencing (in my case, its 4bb5a2.dns.nextdns.io). So try adding those DNS servers to the OpenVPN client custom config field as route directives which will bind them to the VPN.

route 4bb5a2.dns.nextdns.io 255.255.255.255 vpn_gateway

Interesting, so based on this

1) Set up DNS over TLS using the Merlin WAN UI
2) You can continue to use PBR with OpenVPN (setting DNS to disabled)
3) Add the route directive to the custom config field of the VPN client UI so that the DNS-over-TLS connection is forced through the VPN gateway instead of the WAN

I will try this out, see if it works.

Thanks.

 

[Netbug]

I run 2 vpn clients myself.

As far as i was aware DoT is done over WAN.

One of my vpn clients i have "Accept DNS Configuration" set to "Exclusive" (bypassing dnsmasq, which diversion requires for ad-blocking) and PBR set to strict. Because i want the devices connected to this vpn to send traffic and dns queries over the vpn, unfortunately that means no ad-blocking as i am bypassing dnsmasq to use vpn dns servers. Using ipleak.net the dns is the same as the ip address as using vpn dns which in this case is correct.

My second vpn client i have dns set to "Disabled" (dnsmasq isn't bypassed and diversion ad-blocking will work) and PBR set to strict. Because i want the devices connected to this vpn to send traffic over the vpn but because i want to take advantage of Diversion ad-blocking, "Accept DNS Configuration" is set to "Disabled", which as far as i've always understood it means dns queries will be sent over WAN in you're case and mine using DoT. Using ipleak.net the IP is the IP of the vpn service i'm using and dns is the dns ip of clourflare which i have set in WAN using DoT and goes over WAN.

Maybe i am wrong but i thought that was one of the downsides of setting "Accept DNS Configuration" to "Disabled" is you are bypassing vpn dns servers and using dnsmasq which in mycase benefit from ad-blocking using diversion but dns queries will be sent over WAN not VPN (im using DoT to in WAN).

This guide might be of some help.

 

[Smokey613]

I use NextDNS but I use the client https://github.com/nextdns/nextdns/wiki/AsusWRT-Merlin
My 2 FireStick 4K and my AppleTV are routed over a TorGuard VPN dedicated IP for geo location reasons so I can get specific programming. DNS lookups are done over the default WAN route. The plus side is the client will also track devices on your network so you can see their DNS lookups. It works great.

 

[eibgrad]

Interesting, so based on this

1) Set up DNS over TLS using the Merlin WAN UI
2) You can continue to use PBR with OpenVPN (setting DNS to disabled)
3) Add the route directive to the custom config field of the VPN client UI so that the DNS-over-TLS connection is forced through the VPN gateway instead of the WAN

I will try this out, see if it works.

Thanks.

Got curious and decided to test out my own theory. I added the DNS-over-TLS domain name as a route to the OpenVPN client custom config field. And it *would* have worked, were it not for something I'm about to explain.

When using PBR (policy based routing), the router removes the default gateway of the VPN from the main routing table (which is correct; that will eventually be moved to a secondary routing table). But it also removes *all* routes that point to the VPN, which is NOT correct!

Here's a dump of the syslog (note, I have a lot of other route directives besides the one for the DNS-over-TLS domain name, so that's why you see so many removals; the ones that matter for DNS-over-TLS are 162.250.2.3 and 45.77.162.235).

Feb  7 18:39:15 openvpn-routing: Configuring policy rules for client 1
Feb  7 18:39:15 openvpn-routing: Creating VPN routing table (mode 2)
Feb  7 18:39:16 openvpn-routing: Removing route for 1.0.0.1 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Removing route for 10.81.0.1 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Removing route for 162.250.2.3 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Removing route for 1.1.1.1 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Removing route for 45.77.162.235 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Adding route for 192.168.1.7 to  through VPN client 1
Feb  7 18:39:16 openvpn-routing: Completed routing policy configuration for client 1
Feb  7 18:39:16 ovpn-client1[1133]: Initialization Sequence Completed

Again, it's absolutely correct for the router to remove the following routes from the main routing table because these represent the routes that change the default gateway from the WAN to the VPN.

Feb  7 18:39:16 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from main routing table
Feb  7 18:39:16 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from main routing table

But all the others should be left alone! Those are route directives that we want placed in the main routing table so we can force the router (which is using the main routing table) to use the VPN for those routes.

IOW, as implemented, PBR is just looking for anything that references the VPN in the main routing table (probably just grep'ing for tun11) and removing it, unconditionally.

Ugg.

If it wasn't for this, it would be working. And in my book, this is a flaw in the implementation of PBR. It needs to be *selective* about what it removes from the main routing table wrt the VPN (tun11 in this case) rather than a blanket removal of everything. Most likely the developer never anticipated someone wanting to force the router over the VPN while PBR was active.

Just to be 100% sure I understood the problem correctly, I manually added back the routes to the main routing table, and it worked just fine. NextDNS's website reported the OpenVPN client's public IP in the logs.

I'll probably have to report it as a bug/flaw to @RMerlin.

 

[RMerlin]

Use "Policy Rules" instead of "Policy Rules (strict)".

I set up my server to push a route for 1.1.1.1. This is the result on the client:

admin@rtac66b1:/tmp/home/root# ip route show table ovpnc3
192.168.10.1 dev eth0  proto kernel  scope link 
1.1.1.1 via 10.8.0.1 dev tun13
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1 
10.8.0.0/24 dev tun13  proto kernel  scope link  src 10.8.0.2 
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.202 
192.168.10.0/24 via 10.8.0.1 dev tun13  metric 500 
10.7.3.0/24 dev tun12  proto kernel  scope link  src 10.7.3.5 
127.0.0.0/8 dev lo  scope link 
default via 10.8.0.1 dev tun13

 

[eibgrad]

Use "Policy Rules" instead of "Policy Rules (strict)".

I set up my server to push a route for 1.1.1.1. This is the result on the client:

admin@rtac66b1:/tmp/home/root# ip route show table ovpnc3
192.168.10.1 dev eth0  proto kernel  scope link
1.1.1.1 via 10.8.0.1 dev tun13
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
10.8.0.0/24 dev tun13  proto kernel  scope link  src 10.8.0.2
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.202
192.168.10.0/24 via 10.8.0.1 dev tun13  metric 500
10.7.3.0/24 dev tun12  proto kernel  scope link  src 10.7.3.5
127.0.0.0/8 dev lo  scope link
default via 10.8.0.1 dev tun13

Who are you specifically responding to?

 

[RMerlin]

Who are you specifically responding to?

You, who said that all pushed routes were getting removed.

 

[eibgrad]

You, who said that all pushed routes were getting removed.

I *was* using Routing Policy (non strict).

And I'm NOT talking about pushed routes. I'm talking about routes defined on the client.

 

[RMerlin]

I *was* using Routing Policy (non strict).

Well I don't know how you were adding those routes, but in my own test, they properly got copied to the ovpnc table when in non-strict mode.

 

[eibgrad]

Well I don't know how you were adding those routes, but in my own test, they properly got copied to the ovpnc table when in non-strict mode.

Again, the routes are being defined on the client. The syslog shows them being removed.

 

[RMerlin]

Again, the routes are being defined on the client. The syslog shows them being removed.

In the Custom Config section? Also works fine here. I added:

route 9.9.9.9 255.255.255.255

to my client's custom config, and it got copied to the ovpnc table.

admin@rtac66b1:/tmp/home/root# ip route show table ovpnc3
9.9.9.9 via 10.8.0.1 dev tun13 
192.168.10.1 dev eth0  proto kernel  scope link 
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1 
10.8.0.0/24 dev tun13  proto kernel  scope link  src 10.8.0.2 
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.202 
192.168.10.0/24 via 10.8.0.1 dev tun13  metric 500 
10.7.3.0/24 dev tun12  proto kernel  scope link  src 10.7.3.5 
127.0.0.0/8 dev lo  scope link 
default via 10.8.0.1 dev tun13

 

[eibgrad]

In the Custom Config section? Also works fine here. I added:

route 9.9.9.9 255.255.255.255

to my client's custom config, and it got copied to the ovpnc table.

admin@rtac66b1:/tmp/home/root# ip route show table ovpnc3
9.9.9.9 via 10.8.0.1 dev tun13
192.168.10.1 dev eth0  proto kernel  scope link
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
10.8.0.0/24 dev tun13  proto kernel  scope link  src 10.8.0.2
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.202
192.168.10.0/24 via 10.8.0.1 dev tun13  metric 500
10.7.3.0/24 dev tun12  proto kernel  scope link  src 10.7.3.5
127.0.0.0/8 dev lo  scope link
default via 10.8.0.1 dev tun13

You're not getting it. I'm NOT talking about those routes being removed from the secondary routing table (ovpnc3). I'm talking about those same routes being removed from the *main* routing table. You're removing them, but I need them so the router when it references those routes can be bound to the VPN. The router, when PBR is active, is using the main routing table, which is bound to the WAN.