Questions with using OpenVPN with DoT and Diversion

[jadog]

I have been using AsusMerlin with Diversion for a few years and am on the latest version. I recently purchased a subscription to a VPN and would like to use that at the router level. I configured all 5 slots with VPN's around the country and defined to be used with VPN Director. I also set the "Accept DNS Configuration" as Exclusive. I then defined my subnet CID so that the VPN uses all devices on my network (I excluded Disney+ otherwise I'm unable to access it). During my testing, it appears that Diversion works along side the VPN. So far, so good. I then configured DNS over TLS and setup to resolve with Cloudflare servers. I can see this takes effect only if I change "Accept DNS Configuration" from "Exclusive" to "Strict". However, if I change to Strict, the DNS Leak Test shows my DNS is leaking to Cloudflare and my IP address shows as my own provider instead of the VPN. I suppose I can leave it as "Exclusive" and know that if my VPN drops offline or if I need to disconnect from the VPN, I'm still covered by DoT.

However, I have additional questions:

1. Has the VPN Director replaced the x3mRouting script or does that provide some additional features?
2. If I enable all 5 VPN clients for the same interface, when the first one fails, will it roll to the second and so forth?
3. I've also been considering replacing Cloudflare with NextDNS so that I can configure additional network level control (custom blacklist/whitelist, parental controls, etc). Can I configure this so I can use DoT with NextDNS inside the VPN tunnel?

 

[Caesar the Dictator]

It will be useful for you to take a look at the post I shared below and the whole thread.

DNS-over-TLS (NextDNS) & OpenVPN

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...

www.snbforums.com

With DNS Filter turned off and I only use DoT server. I added the DoT's IPv4 address to VPN Director. And so, DNS queries of my VPN clients with DNS configuration "disabled" and my devices accessing the internet from WAN started to be made via VPN tunnel.

I will try this method in AdGuard Home instead of Diversion next. I hope it works.

Tutorial - AdGuard Home - adblocker - Clean install on Asus Merlin (No 3rd party scripts !!!)

I have finally managed to install AdGuard Home on an Asus Router.... this is without using any special scripts. There was a previous forum post (here) on the same, but that involved installing using a custom script (that asked for your ssh login credentials, installed its own version of Samba...

www.snbforums.com

 

[jadog]

Thanks, I'll add the DoT's IPv4 address to VPN Director and see how that goes. I already looked at AdGuard Home and NextDNS appears to be superior in every way. But thanks for that tip. Hopefully someone will still answer question 1 and 2.

 

[eibgrad]

I can see this takes effect only if I change "Accept DNS Configuration" from "Exclusive" to "Strict". However, if I change to Strict, the DNS Leak Test shows my DNS is leaking to Cloudflare and my IP address shows as my own provider instead of the VPN. I suppose I can leave it as "Exclusive" and know that if my VPN drops offline or if I need to disconnect from the VPN, I'm still covered by DoT.

Seems to me this comes down to the definition of a DNS leak. For my purposes, a DNS leak is anytime you access DNS using your ISP's specified DNS server(s), OR, access some other DNS server(s) over the WAN and "in the clear".

But once you decide to use DoT, it doesn't really matter whether DNS is accessed over the WAN or VPN. It's no longer in the clear. And that's the whole point. Not unless you're particularly paranoid and have some reason to prevent your ISP from even knowing you're using a DoT provider.

1. Has the VPN Director replaced the x3mRouting script or does that provide some additional features?

AFAIK, the author of x3mRouting has NOT been actively supporting it in recent months, and the current version is known to have incompatibilities w/ the VPN Director. I don't use it personally, but it appears to me the biggest advantage it offers over the VPN Director is its support for IPSET.

So unless you have a specific reason NOT to use the VPN Director, I think most ppl would be wise to use what's available in the GUI.

1. If I enable all 5 VPN clients for the same interface, when the first one fails, will it roll to the second and so forth?

The lowered numbered OpenVPN clients always have precedence over the higher numbered ones. It will only roll over to the next available OpenVPN client *assuming* the failed VPN is shutdown cleanly and completely, because that's the only way the ip rule(s) for the failed OpenVPN client will be removed from the RPDB (routing policy database) and allow traffic to continue to the ip rule(s) for the next available OpenVPN client. But depending on how you have your OpenVPN clients configured, that may never happen.

For example, if you have two OpenVPN clients (#1 and #2) configured identically wrt their ip rules, and OpenVPN client #1 is configured to retry after a failure, the router will BLOCK access to the internet during this period, because OpenVPN client #1's ip rule(s) are still in-place and active! This is particularly true when it comes to using the GUI's kill switch. By definition, that feature can only be enforced w/ those rules in-place and active. There's also the problem of the use of the persist-tun and persist-key directives by the router. These prevent the failed tunnel from being deconstructed after a failure (something I'm mentioned in a prior post).

IOW, this is a tricky thing to configure properly. Nothing about it is automatic. It's the result of making all the right configuration choices.

When dealing w/ multiple, concurrent OpenVPN clients, you also have to be careful that each one is using NON overlapping IP networks on their respective tunnels. This is always a risk, particularly when you're using the same OpenVPN provider. If the tunnels overlap, then you'll create routing ambiguity.

I'm of the opinion that it would be better to script this sort of thing yourself, where you only maintain a single OpenVPN client at any given time, then monitor it for failure (as you define it), and as necessary, shutdown that VPN and start a different OpenVPN client. But there is no such logic available in the GUI. The GUI is NOT monitoring anything in terms of failover. It's a matter of how you statically configure the OpenVPN clients whether you'll get the failover behavior you're expecting.

1. I've also been considering replacing Cloudflare with NextDNS so that I can configure additional network level control (custom blacklist/whitelist, parental controls, etc). Can I configure this so I can use DoT with NextDNS inside the VPN tunnel?

Once again, DoT would normally make the issue of using the WAN vs. VPN moot. Once your DNS is secured, it's secured. But if you insist on forcing DoT over the VPN as well, then you'd need to use routing policy rules to bind those DNS servers to the OpenVPN client(s). Just beware that you can sometimes tie yourself into knots w/ stuff like this, since now even the router's own DNS is bound to the VPN (possibly a failed VPN!), NOT just the LAN clients bound to the VPN. I fear if the VPN fails, and the router needs to re-resolve the OpenVPN server's domain name, it may fail!

DNS is tricky stuff. Don't make it overly complicated. For most ppl, once you configure for DoT over the WAN, that should be the end of it. The one exception might be those who insist on having those clients bound to the WAN in general, also bind their DNS to the WAN, while those bound to the VPN in general, bind their DNS to the VPN. In that case, use "Exclusive" for "Accept DNS Configuration" on the OpenVPN client.

 

[Caesar the Dictator]

Once again, DoT would normally make the issue of using the WAN vs. VPN moot. Once your DNS is secured, it's secured. But if you insist on forcing DoT over the VPN as well, then you'd need to use routing policy rules to bind those DNS servers to the OpenVPN client(s). Just beware that you can sometimes tie yourself into knots w/ stuff like this, since now even the router's own DNS is bound to the VPN (possibly a failed VPN!), NOT just the LAN clients bound to the VPN. I fear if the VPN fails, and the router needs to re-resolve the OpenVPN server's domain name, it may fail!

DNS is tricky stuff. Don't make it overly complicated. For most ppl, once you configure for DoT over the WAN, that should be the end of it. The one exception might be those who insist on having those clients bound to the WAN in general, also bind their DNS to the WAN, while those bound to the VPN in general, bind their DNS to the VPN. In that case, use "Exclusive" for "Accept DNS Configuration" on the OpenVPN client.

Can a user who expects to use the DoT server of another DNS provider they trust (e.g. NextDNS) instead of using only the VPN provider's DNS, and hide it from their ISP, can use this method that Rmerlin has shown? https://www.snbforums.com/threads/dns-over-tls-nextdns-openvpn.70133/page-2

Is there any risk for average users like me to use this method in their daily use? This method works in a way that meets my expectation as far as I can see.

Unfortunately, the mobile broadband internet provider that I am a customer of in the country I live in has restricted port 853. Therefore, I cannot use ad-blocking DoT servers such as AdGuard, NextDNS, AhaDNS, BlahDNS. In the future, the same restriction can be brought for the internet that I use at home. If this happens, I won't be able to access the DoT servers with my ISP, ie over the WAN. I think Rmerlin's method can also be used to circumvent this problem.

 

[jadog]

eibgrad said:

Once again, DoT would normally make the issue of using the WAN vs. VPN moot. Once your DNS is secured, it's secured. But if you insist on forcing DoT over the VPN as well, then you'd need to use routing policy rules to bind those DNS servers to the OpenVPN client(s). Just beware that you can sometimes tie yourself into knots w/ stuff like this, since now even the router's own DNS is bound to the VPN (possibly a failed VPN!), NOT just the LAN clients bound to the VPN. I fear if the VPN fails, and the router needs to re-resolve the OpenVPN server's domain name, it may fail!

DNS is tricky stuff. Don't make it overly complicated. For most ppl, once you configure for DoT over the WAN, that should be the end of it. The one exception might be those who insist on having those clients bound to the WAN in general, also bind their DNS to the WAN, while those bound to the VPN in general, bind their DNS to the VPN. In that case, use "Exclusive" for "Accept DNS Configuration" on the OpenVPN client.

So to be clear, are you suggesting that DoT is as private as using a VPN? My research led me to a different conclusion. I like my privacy and would prefer that the world doesn't spy on me. I don't like doing a search for an Asus router in Google and then see ads show up in Amazon for the same router. I remember talking about buying something one time and my phone must have been listening because I saw ads turn up in a search that very hour. Creeps me out. I would rather not have my online activity be recorded and tracked by my ISP. Certainly not for illegal activity - simply my privacy.

 

[L&LD]

Unless you own/control the ISP, your clients, AND the endpoint servers you connect to online, not even a VPN will give you 'privacy'. This is a myth.

If you're online, you have no privacy. This has been discussed extensively.

 

[jadog]

Unless you own/control the ISP, your clients, AND the endpoint servers you connect to online, not even a VPN will give you 'privacy'. This is a myth.

If you're online, you have no privacy. This has been discussed extensively.

I understand that privacy will be relative. My question wasn't about "how much" privacy but rather if DoT was as private as a VPN. Truthfully, I'd rather just use DoT as I have higher performance.

 

[L&LD]

If you're strictly accessing your home network (and not browsing the 'net, at all), then using a non-paid-for VPN, like OpenVPN, is the theoretically better option.

If you are browsing the 'net, it is all the same. The only difference is who you decide (willingly or not) to give your browsing info to.

Paid VPNs are, IMO, the worst in all scenarios.

 

[jadog]

Interesting. I have not heard this point of view. Can you describe an example of why paid VPN's are the worst? If their TOS says that the VPN provider is destroying my browsing data, then am I just being naive to believe it's true? If I trust my local ISP, then it sounds like DoT would be the best solution.

 

[L&LD]

If we're talking about security/privacy, a fair huge dose of skepticism of their claims is necessary. Even required. Because none of them have earned any gold stars that I know of (unless they handed them out to themselves from dupe-sites that show how great they are).

All you are to them is $$ until you're not. If anyone could really provide security/privacy this would be a done deal (and these discussions wouldn't be happening).

You trust your local ISP, the backbone your local ISP connects to, and the bilateral contracts (re: data sharing) between all parties concerned. Not to mention the equipment you use and the various ISPs and hotspots you connect to along your travels.

I say just trust your click finger instead and browse like your mother is watching you instead.

We've all read/heard the online horror stories. Act like they're true.

Btw, I have offered this point of view in various threads/posts before too.

 

[eibgrad]

So to be clear, are you suggesting that DoT is as private as using a VPN? My research led me to a different conclusion. I like my privacy and would prefer that the world doesn't spy on me. I don't like doing a search for an Asus router in Google and then see ads show up in Amazon for the same router. I remember talking about buying something one time and my phone must have been listening because I saw ads turn up in a search that very hour. Creeps me out. I would rather not have my online activity be recorded and tracked by my ISP. Certainly not for illegal activity - simply my privacy.

What is the purpose of DoT (or DoH)? It's to secure your DNS queries from eavesdropping, and/or prevent them from being redirected by your ISP. Before the introduction of these protocols, your only option was to use a VPN and force your Do53 (in the clear) queries over the tunnel and to the VPN provider's DNS server.

IOW, the whole point of DoT/DoH is to secure your DNS w/o the need for a VPN! Of course, nothing prevents you from using BOTH, but given the intent of the DoT/DoH protocols, it's sort of silly. Seems to me you either use DoT/DoH as designed and route that *secured* traffic over the WAN, or else you use the old methology of Do53 over the VPN. But inisting on the combination of both methods seems to suggest a lack of understanding about the intent of DoT/DoH.

 

[eibgrad]

Can a user who expects to use the DoT server of another DNS provider they trust (e.g. NextDNS) instead of using only the VPN provider's DNS, and hide it from their ISP, can use this method that Rmerlin has shown? https://www.snbforums.com/threads/dns-over-tls-nextdns-openvpn.70133/page-2

As I just stated to the OP, normally it doesn't make sense to use both DoT/DoH *and* the VPN to secure your DNS queries. The prior was intended to eliminate the need for the latter. But if you want to, sure, got for it. As I stated previously, this would prevent the ISP from even knowing you were using a DoT provider, if for some reason you consider this necessary (I don't, but to each his own).

Is there any risk for average users like me to use this method in their daily use? This method works in a way that meets my expectation as far as I can see.

As I said, one concern I would have is binding the router itself to the VPN in this manner. If the DoT server is bound to the VPN based on its destination IP, then that will affect the router too, NOT just the LAN clients. And if the tunnel fails for any reason, and the router needs to re-resolve the domain name of the server to get restarted, that name resolution will FAIL! IOW, you risk being stuck in a catch-22; the router needs name resolution to be working w/ the OpenVPN client in order to get the OpenVPN client running again.

Unfortunately, the mobile broadband internet provider that I am a customer of in the country I live in has restricted port 853. Therefore, I cannot use ad-blocking DoT servers such as AdGuard, NextDNS, AhaDNS, BlahDNS. In the future, the same restriction can be brought for the internet that I use at home. If this happens, I won't be able to access the DoT servers with my ISP, ie over the WAN. I think Rmerlin's method can also be used to circumvent this problem.

Well that's a completely different issue. Obviously if you are denied access to DoT because of the port being blocked by the ISP, then the VPN is your only option. But again, this gets back to *why* anyone would be using DoT/DoH in the first place. I'm assuming the intent is to eliminate the need to rely on a VPN for securing DNS queries. But if you have other motives unrelated to securing your DNS (e.g., better ad-blocking), that's fine, but that is NOT the purpose of DoT/DoH! That's just a side benefit of using their services.

 

[Caesar the Dictator]

Your explanation was enlightening for me, thank you. I understand that if I want to block trackers and other advertising and analytics DNS queries in apps on my smart devices, I can safely use Diversion with a DoT server that queries over the WAN. At least as long as TLS 1.3 continues to exist as a reliable protocol, this will be so.

It would be great if my VPN provider offered an "internal DNS" IP address with customizable blocking filters like NextDNS that I could add to the OpenVPN configuration.

As I said, one concern I would have is binding the router itself to the VPN in this manner. If the DoT server is bound to the VPN based on its destination IP, then that will affect the router too, NOT just the LAN clients. And if the tunnel fails for any reason, and the router needs to re-resolve the domain name of the server to get restarted, that name resolution will FAIL! IOW, you risk being stuck in a catch-22; the router needs name resolution to be working w/ the OpenVPN client in order to get the OpenVPN client running again.

Finally, I will ask one more question. Is there any possibility of experiencing the problem you described above with an OpenVPN client configuration with "Redirect Internet traffic through tunnel" set to "Yes (all)"? If I'm not mistaken, in this scenario, the router itself connects to the VPN. Please excuse me if this question sounds funny.