DNS-over-TLS (NextDNS) & OpenVPN

[RMerlin]

You can't have the router automatically manage routes based on the webui config AND add your own custom routes and expect the router to magically guess which routes should be left untouched in main and which should be moved... Pick one method, not both.

If you want the router's DoT queries to go through the tunnel, then create a policy rule with DoT server's IP address. It will tell the router to go through the VPN for that destination.

Normally you'd set up the source IP as the router and the destination as the DoT server, but for some reason this currently doesn't work (possibly one of the higher priority routing tables has precedence - I haven't had time to look into it). However not specifying a source will work, even from the router (a traceroute running from my router was going through the tunnel for me).

admin@stargate88ax:/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  10.8.2.1 (10.8.2.1)  10.302 ms  12.637 ms  14.217 ms
 2  vlan24.as02.qc1.ca.m247.com (176.113.74.1)  9.924 ms  16.546 ms  13.358 ms
 3  xe-0-0-1-0.agg2.qc1.ca.m247.com (37.120.128.166)  25.526 ms  35.845 ms  21.326 ms
 4  vlan304.as032.buc.ro.m247.com (77.243.185.226)  12.552 ms  13.364 ms  12.147 ms
 5  cloudflare.peer.qix.ca (198.179.18.55)  10.132 ms  10.877 ms  14.073 ms
 6  one.one.one.one (1.1.1.1)  13.470 ms  12.741 ms  18.921 ms

 

[eibgrad]

You can't have the router automatically manage routes based on the webui config AND add your own custom routes and expect the router to magically guess which routes should be left untouched in main and which should be moved... Pick one method, not both.

If you want the router's DoT queries to go through the tunnel, then create a policy rule with DoT server's IP address. It will tell the router to go through the VPN for that destination.

View attachment 30484

Normally you'd set up the source IP as the router and the destination as the DoT server, but for some reason this currently doesn't work (possibly one of the higher priority routing tables has precedence - I haven't had time to look into it). However not specifying a source will work, even from the router (a traceroute running from my router was going through the tunnel for me).

admin@stargate88ax:/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  10.8.2.1 (10.8.2.1)  10.302 ms  12.637 ms  14.217 ms
2  vlan24.as02.qc1.ca.m247.com (176.113.74.1)  9.924 ms  16.546 ms  13.358 ms
3  xe-0-0-1-0.agg2.qc1.ca.m247.com (37.120.128.166)  25.526 ms  35.845 ms  21.326 ms
4  vlan304.as032.buc.ro.m247.com (77.243.185.226)  12.552 ms  13.364 ms  12.147 ms
5  cloudflare.peer.qix.ca (198.179.18.55)  10.132 ms  10.877 ms  14.073 ms
6  one.one.one.one (1.1.1.1)  13.470 ms  12.741 ms  18.921 ms

I don't see why the use of static routes and PBR at the same time raises any issues. There's nothing to be touched or removed. As I see it, the former are global in scope. Seems to me that all static routes should be present in both the main and secondary routers tables at all times *except* when using Routing Policy strict, in which case you purposely strip any routes from the secondary table which are NOT bound to the VPN. I get that part of it. Otherwise I just don't see any conflict.

As far as using PBR w/ only a destination IP, I can see where that could possibly work. My assumption was that the rules minimally required a source IP, which in the case of the router, is problematic, since when referencing a public IP, the source IP would have to be either that associated w/ the WAN or VPN (depending on the default gateway). If you specify its LAN ip (which is what I assume you meant when you said the source IP didn't work), that's why it didn't work. It's not bound to the LAN ip except when communicating w/ the local network. IOW, by NOT providing a source IP, it's presumably acting as a wildcard (maybe 0.0.0.0/0 would work as well).

It's getting late here, so I'll give this a try in the morning. And btw, thanks for looking into this and coming up w/ a possible solution.

 

[Netbug]

You can't have the router automatically manage routes based on the webui config AND add your own custom routes and expect the router to magically guess which routes should be left untouched in main and which should be moved... Pick one method, not both.

If you want the router's DoT queries to go through the tunnel, then create a policy rule with DoT server's IP address. It will tell the router to go through the VPN for that destination.

View attachment 30484

Normally you'd set up the source IP as the router and the destination as the DoT server, but for some reason this currently doesn't work (possibly one of the higher priority routing tables has precedence - I haven't had time to look into it). However not specifying a source will work, even from the router (a traceroute running from my router was going through the tunnel for me).

admin@stargate88ax:/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  10.8.2.1 (10.8.2.1)  10.302 ms  12.637 ms  14.217 ms
2  vlan24.as02.qc1.ca.m247.com (176.113.74.1)  9.924 ms  16.546 ms  13.358 ms
3  xe-0-0-1-0.agg2.qc1.ca.m247.com (37.120.128.166)  25.526 ms  35.845 ms  21.326 ms
4  vlan304.as032.buc.ro.m247.com (77.243.185.226)  12.552 ms  13.364 ms  12.147 ms
5  cloudflare.peer.qix.ca (198.179.18.55)  10.132 ms  10.877 ms  14.073 ms
6  one.one.one.one (1.1.1.1)  13.470 ms  12.741 ms  18.921 ms

This works for me to some extent following your advice, I have 1.1.1.1 and 1.0.0.1 for DoT (WAN - Internet Connection) and "Connect to DNS Server automatically" = "no" and using 1.1.1.1 and 1.0.0.1 there also.

If i add just 1.1.1.1 to PBR as you did and do a traceroute via ssh it shows 1.1.1.1 being sent over vpn, until i reboot then nothing can connect to internet, vpn cant resolve, ntp cant sync etc.

if i also add 1.0.0.1 to PBR same as above.

I'm no expert so will leave mine as is caused to many undesirable effects for me. I use YazFi and one of my guest wifi networks have traffic sent over vpn but so they benefit from diversion ad-blocking "Accept DNS Configuration" is set to "Disabled" so DNS queries are sent via WAN using DoT, it would be good to send DoT queries over vpn but caused me problems mentioned above.

 

[trekkie3214543]

You can't have the router automatically manage routes based on the webui config AND add your own custom routes and expect the router to magically guess which routes should be left untouched in main and which should be moved... Pick one method, not both.

If you want the router's DoT queries to go through the tunnel, then create a policy rule with DoT server's IP address. It will tell the router to go through the VPN for that destination.

View attachment 30484

Normally you'd set up the source IP as the router and the destination as the DoT server, but for some reason this currently doesn't work (possibly one of the higher priority routing tables has precedence - I haven't had time to look into it). However not specifying a source will work, even from the router (a traceroute running from my router was going through the tunnel for me).

admin@stargate88ax:/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  10.8.2.1 (10.8.2.1)  10.302 ms  12.637 ms  14.217 ms
2  vlan24.as02.qc1.ca.m247.com (176.113.74.1)  9.924 ms  16.546 ms  13.358 ms
3  xe-0-0-1-0.agg2.qc1.ca.m247.com (37.120.128.166)  25.526 ms  35.845 ms  21.326 ms
4  vlan304.as032.buc.ro.m247.com (77.243.185.226)  12.552 ms  13.364 ms  12.147 ms
5  cloudflare.peer.qix.ca (198.179.18.55)  10.132 ms  10.877 ms  14.073 ms
6  one.one.one.one (1.1.1.1)  13.470 ms  12.741 ms  18.921 ms

Thanks to @RMerlin and @eibgrad for investigating this. The above solution is working for me. I just put the Destination IPs for NextDNS as above and the DNS-over-TLS connection is now being routed through the OpenVPN tunnel instead of WAN as observed from the NextDNS logs showing the VPN IP instead of my ISP assigned IP.

Thanks for your help.

 

[New2This]

Thanks to @RMerlin and @eibgrad for investigating this. The above solution is working for me. I just put the Destination IPs for NextDNS as above and the DNS-over-TLS connection is now being routed through the OpenVPN tunnel instead of WAN as observed from the NextDNS logs showing the VPN IP instead of my ISP assigned IP.

Thanks for your help.

have any pics, willing to try it here

 

[Netbug]

I finally managed to get it to work for myself now without issues by only have one dns server set under Wan - Internet Connection - (DNS-over-TLS Server List) . Having more than one server here when adding 1.1.1.1 to vpn client PBR causes internet to go down, ntp can't sync etc don't know why but it simply would not work.

So in WAN - Under (DNS-over-TLS Server List) i had both 1.1.1.1 and 1.0.0.1, as shown in pic above i removed 1.0.0.1. I then did as @RMerlin advised (thank you btw) adding 1.1.1.1 to vpn client PBR (see below pic) and when i do traceroute on 1.1.1.1 it shows it being routed via vpn, also my vpnclient is running via Netherlands and when using Ipleak.net it shows cloudflare dns server in Netherlands which is rite because if i remove 1.1.1.1 from PBR it goes back to cloudflare dns in UK which is rite for me.

traceroute via ssh:

@router:/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  10.32.234.1 (10.32.234.1)  18.449 ms  18.479 ms  18.549 ms
2  85.92.108.145 (85.92.108.145)  1775.183 ms !A  2521.157 ms !A  *

using ip rule via ssh also shows 1.1.1.1 going through vpn:

@router:/tmp/home/root# ip rule
0:    from all lookup local
10101:    from all to 1.1.1.1 lookup ovpnc1
10102:    from 192.168.20.14 lookup ovpnc1
10501:    from 192.168.50.0/24 lookup ovpnc3
32766:    from all lookup main
32767:    from all lookup default

So after wanting to bang my head against a brick wall a few times lol it was a matter of me just removing the second dns server from WAN under DNS-over-TLS Server List.

 

[eibgrad]

@trekkie3214543, @RMerlin

I'm glad this all worked out for you. But I still want to make it clear that the use of static routes *should* have worked, and by the router removing static routes from the main routing table, it can have unintended consequences that produce subtle errors. Let me explain.

When you configure the OpenVPN client w/ either Exclusive or Strict for "Accept DNS configuration", this means you want DNSMasq reconfigured to use the DNS server(s) push'd by the OpenVPN server. Most of the time these DNS servers are in the same *private* IP space as that of the tunnel, and so no problems. But whenever you use PBR and take the router off the VPN, and the VPN provider pushes *public* IPs for DNS (and it does happen from time to time), now you have a potential problem. If those are third-party DNS servers (e.g., Google, 8.8.8.8 and 8.8.4.4), they will be accessed over the WAN (I consider this a DNS leak). If the DNS servers are owned by the VPN provider (w/ public IPs), they might only be made available over the VPN for the exclusive use of their customers. And so if an attempt is made to access those DNS servers over the WAN, it fails! Many times VPN providers push a static route (in the form of a route directive) to the OpenVPN client in an attempt to prevent that from happening. But if the router is going to unconditionally strip out all static routes bound to the VPN when PBR is active, then things will start to break. Best case scenario is Strict, where the ISP's DNS servers are accessed over the WAN. Worst case scenario is Exclusive, where DNS may fail completely.

Of course, when dealing w/ a site-to-site configuration, similar problems can occur. The server might want to force certain destinations over the VPN using static routes for a variety of reasons, not just DNS.

So while using PBR to solve the OP's particular problem works, it's only because the *client* is the one trying to force the destination IP over the tunnel. It does nothing to help when the server wants to do likewise.

It's not my intent to belabor this point. Just to say that removing static routes bound to the VPN from the main routing table comes w/ some risk. And I would prefer that this wasn't done. IMO, PBR and static routes do NOT need to be mutually exclusive. They should complement each other.

 

[Dee dee]

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.

Can someone please post the link to the wiki.

I wanted to set up next DNS when I open VPN connection as well.

 

[Dee dee]

Can someone please post the link to the wiki.

I wanted to set up next DNS when I open VPN connection as well.

I want to know which mode either the exclusive or the strict would use the VPN from nordvpn and allow my next DNS site blocking rules or ifts do I have to use either exclusive or strict.

I remember reading about are Merlin's thread seeing what to use but when I try it through disabled my DNS doesn't work or I don't know.

 

[Chuckles67]

You can't have the router automatically manage routes based on the webui config AND add your own custom routes and expect the router to magically guess which routes should be left untouched in main and which should be moved... Pick one method, not both.

If you want the router's DoT queries to go through the tunnel, then create a policy rule with DoT server's IP address. It will tell the router to go through the VPN for that destination.

View attachment 30484

Normally you'd set up the source IP as the router and the destination as the DoT server, but for some reason this currently doesn't work (possibly one of the higher priority routing tables has precedence - I haven't had time to look into it). However not specifying a source will work, even from the router (a traceroute running from my router was going through the tunnel for me).

admin@stargate88ax:/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  10.8.2.1 (10.8.2.1)  10.302 ms  12.637 ms  14.217 ms
2  vlan24.as02.qc1.ca.m247.com (176.113.74.1)  9.924 ms  16.546 ms  13.358 ms
3  xe-0-0-1-0.agg2.qc1.ca.m247.com (37.120.128.166)  25.526 ms  35.845 ms  21.326 ms
4  vlan304.as032.buc.ro.m247.com (77.243.185.226)  12.552 ms  13.364 ms  12.147 ms
5  cloudflare.peer.qix.ca (198.179.18.55)  10.132 ms  10.877 ms  14.073 ms
6  one.one.one.one (1.1.1.1)  13.470 ms  12.741 ms  18.921 ms

This is interesting. I'm using DoT with Clouflare 1.1.1.1 and 1.0.0.1. After this change to make DoT queries go through a tunnel (OpenVPN to a local NordVPN server in my case) I see the trace route does not use my ISP as before. The trace route is slower in my case but seems acceptable for privacy.

This is not mentioned on the Asuswrt-Merlin Wiki entry for DNS Privacy, maybe it is a useful technique to mention on that page ?

 

[New2This]

Does this look right ?

admin@RT-AX88U-E960:/tmp/home/root# ip route show table ovpnc1
0.0.0.0/1 via 10.8.2.1 dev tun11
default via 10.8.2.1 dev tun11
1.1.1.1 via 10.8.2.1 dev tun11
10.8.2.0/24 dev tun11  proto kernel  scope link  src 10.8.2.2
66.115.145.18 via 209.71.196.8 dev ppp0
127.0.0.0/8 dev lo  scope link
128.0.0.0/1 via 10.8.2.1 dev tun11
169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.137.254
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
209.71.196.8 dev ppp0  proto kernel  scope link
239.0.0.0/8 dev br0  scope link
admin@RT-AX88U-E960:/tmp/home/root#

 

[Netbug]

Does this look right ?

admin@RT-AX88U-E960:/tmp/home/root# ip route show table ovpnc1
0.0.0.0/1 via 10.8.2.1 dev tun11
default via 10.8.2.1 dev tun11
1.1.1.1 via 10.8.2.1 dev tun11
10.8.2.0/24 dev tun11  proto kernel  scope link  src 10.8.2.2
66.115.145.18 via 209.71.196.8 dev ppp0
127.0.0.0/8 dev lo  scope link
128.0.0.0/1 via 10.8.2.1 dev tun11
169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.137.254
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
209.71.196.8 dev ppp0  proto kernel  scope link
239.0.0.0/8 dev br0  scope link
admin@RT-AX88U-E960:/tmp/home/root#

Yes as it shows 1.1.1.1 via 10.8.2.1 dev tun11 basically dns queries are being sent through the vpn tunnel.

 

[Vertron]

I finally managed to get it to work for myself now without issues by only have one dns server set under Wan - Internet Connection - (DNS-over-TLS Server List) . Having more than one server here when adding 1.1.1.1 to vpn client PBR causes internet to go down, ntp can't sync etc don't know why but it simply would not work.

View attachment 30492

So in WAN - Under (DNS-over-TLS Server List) i had both 1.1.1.1 and 1.0.0.1, as shown in pic above i removed 1.0.0.1. I then did as @RMerlin advised (thank you btw) adding 1.1.1.1 to vpn client PBR (see below pic) and when i do traceroute on 1.1.1.1 it shows it being routed via vpn, also my vpnclient is running via Netherlands and when using Ipleak.net it shows cloudflare dns server in Netherlands which is rite because if i remove 1.1.1.1 from PBR it goes back to cloudflare dns in UK which is rite for me.

View attachment 30493

View attachment 30491

traceroute via ssh:

@router:/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  10.32.234.1 (10.32.234.1)  18.449 ms  18.479 ms  18.549 ms
2  85.92.108.145 (85.92.108.145)  1775.183 ms !A  2521.157 ms !A  *

using ip rule via ssh also shows 1.1.1.1 going through vpn:

@router:/tmp/home/root# ip rule
0:    from all lookup local
10101:    from all to 1.1.1.1 lookup ovpnc1
10102:    from 192.168.20.14 lookup ovpnc1
10501:    from 192.168.50.0/24 lookup ovpnc3
32766:    from all lookup main
32767:    from all lookup default

So after wanting to bang my head against a brick wall a few times lol it was a matter of me just removing the second dns server from WAN under DNS-over-TLS Server List.

I've tried this and used NextDNS logs to test it.

If I set it up as above it shows all traffic running through the VPN IP in the NextDNS logs, even the devices that are not set to use the VPN, it should be showing the ISP IP in this case. whatismyipaddress.com shows the correct ISP IP, it's just one sent to NextDNS that's using the wrong VPN IP. Any ideas?