What's new

OpenVPN Client and DoT DNS

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Gary_Dexter

Senior Member
Hi,

Currently using NordVPN as OpenVPN client, and using VPN Director to route all LAN traffic over the VPN.
DNS is also set to Exclusive in the OVPN Client settings.

Traffic is routed out the VPN as expected (confirmed by doing IP check), however DNS Leak Tests show that DNS is coming from Cloudflare, which is set as my DoT DNS, rather than Nord's DNS.

This is also confirmed on the 1.1.1.1 help page that shows me as using Cloudflare DoT as well.

Is this expected behaviour when using DoT that it overrides OVPN Clients DNS settings regardless?

Cheers.
 
This is known behaviour, reported many times. Whether it's by design I couldn't say.

The advantage of Exclusive mode is that it uses dnsmasq to forward to the VPN's DNS servers. This allows you to do things like local name resolution and run Diversion, etc.

The problem comes when you turn on DoT. Stubby (DoT) inserts itself into the dnsmasq config (/tmp/resolv.dnsmasq) as the priority server. Effectively overriding the VPN's DNS entries.

So arguably it's doing what you asked of it. You enabled DoT as the system-wide resolver and it is. This issue doesn't occur when using Policy Rules because the clients requests don't go via dnsmasq.
 
Understood - that makes sense.

I guess there's no way to override it - other than turning off DoT?

Or using DNSFilter and specifying the NordDNS as a custom filter and then assigning all devices to that filter?
 
If you're routing all of your internet traffic through the VPN and using their DNS servers (Exclusive mode) then what's the point of enabling DoT on the router?
I've only just started using/testing the VPN options so DoT is still there from previous setup.
 
If you're routing all of your internet traffic through the VPN and using only their DNS servers (Exclusive mode) then what's the point of enabling DoT on the router?

In general I agree, however, you could make the argument that at least the router itself continues to use DoT. That's one of the problems w/ using the VPN Director. As soon as you enable it, the router itself is no longer bound to the OpenVPN client and its DNS servers. And so from that perspective, you might conclude you do have a DNS leak.

That's what makes dealing w/ DNS leaks so tricky, and responding to comments from users that they have a DNS leak. From whose perspective are they making that assessment? The router? Only the LAN clients bound to the OpenVPN client? Both?

There's also the issue of DNS leaks as seen from the router itself, vs. reported externally by some online leak testing tool. Those are NOT the same thing. You can have total protection from DNS leaks at the point of the router, but still have external DNS leak testing tools report leaks (typically due to redirection).

We haven't even gotten into the discussion of VPN providers who push *public* DNS servers, or private DNS servers outside the scope of the tunnel! When it comes to VPN providers that push public DNS servers, they assume it's safe because they assume the OpenVPN client itself (in this case the router) is bound to the VPN! But if you use the VPN Director, that's NOT the case. So now you have a DNS leak because those DNS servers are being accessed over the WAN.

That's why this whole discussion of DNS leaks requires much deeper analysis than simply what some online tool reports. There are just too many variables in the mix to know w/ any certainty what exactly is happening until you dig down deep. It's why I created the DNSMON utility.
 
In general I agree, however, you could make the argument that at least the router itself continues to use DoT. That's one of the problems w/ using the VPN Director. As soon as you enable it, the router itself is no longer bound to the OpenVPN client and its DNS servers. And so from that perspective, you might conclude you do have a DNS leak.

That's what makes dealing w/ DNS leaks so tricky, and responding to comments from users that they have a DNS leak. From whose perspective are they making that assessment? The router? Only the LAN clients bound to the OpenVPN client? Both?

There's also the issue of DNS leaks as seen from the router itself, vs. reported externally by some online leak testing tool. Those are NOT the same thing. You can have total protection from DNS leaks at the point of the router, but still have external DNS leak testing tools report leaks (typically due to redirection).

We haven't even gotten into the discussion of VPN providers who push *public* DNS servers, or private DNS servers outside the scope of the tunnel! When it comes to VPN providers that push public DNS servers, they assume it's safe because they assume the OpenVPN client itself (in this case the router) is bound to the VPN! But if you use the VPN Director, that's NOT the case. So now you have a DNS leak because those DNS servers are being accessed over the WAN.

That's why this whole discussion of DNS leaks requires much deeper analysis than simply what some online tool reports. There are just too many variables in the mix to know w/ any certainty what exactly is happening until you dig down deep. It's why I created the DNSMON utility.
I agree it's confusing and at times not obvious what's happening (I can't keep track of all the permutations). I've long since given up bothering to respond to the never ending posts from people fretting over DNS leaks. I made an exception in this case because it was an honest straightforward question. But most of the time it's about hopelessly complicated setups involving multiple VPN clients and kill switch behaviour where the user hasn't really thought through what they're asking and expecting the router to read their mind and change its behaviour accordingly. The final nail in the coffin is when people start pointlessly obsessing over the router's own queries.
 
Thanks both for the input.

I’m happy to use Cloudflare DNS as it also provides malware and adult-content filtering which I need anyway.
 
IMO, the ideal solution, provided your only motivation is to secure your DNS, is to use DoT on the WAN and specify Disabled on the OpenVPN client(s). That keeps it simple. All your DNS queries, be it from the router itself, or LAN clients bound or unbound to the OpenVPN client, are secured. And all your clients continue to have access to DNSMasq and all its features (unlike the case of using Exclusive w/ the VPN Director). If at that point any online DNS leak testing tools report an issue, you know it's beyond your control. You've done all you can to secure your DNS before leaving the router.

The problem comes when you start trying to find other means to secure your DNS, such as using the DNS servers from a VPN provider. Now things get complicated because you have all these other issues. It's just a mess of variables best avoided. But as I said, if you're depending upon the VPN provider's DNS server(s) to provide a workaround to geofencing issues, then of course you're stuck having to deal w/ all these other issues. But even so, it might be possible to find a DoT provider that can achieve the same ends.
 
I could make all DNS queries be forced through the VPN client's DNS server when routing mode is set to "All" instead of "VPN Director". The users will then become responsible for dealing with cases where his VPN might be pushing invalid DNS servers, or if they configure multiple OpenVPN clients set to "All" (which doesn't make sense already anyway). It would allow clients with hardcoded DNS servers (like Android's Netflix) to be redirected, however it also means that you lose the redundancy of having two separate nameservers (if your VPN provider pushes more than one). This might become more critical when applying that to your entire network, rather than just a few select clients when using VPN Director.

This however may introduce problems if the DNS connection goes down, and your router will no longer have a working DNS server to connect to for name resolution since all DNS traffic might possibly be trying to use a private DNS server pushed by the VPN provider.

This is a case where trying to handle every single possible scenario becomes a headache for me. To be honest, I wish users used more straightforward and less over-complicated setups where they are configuring conflicting settings. I'm open to attempting to address some of these scenarios, but I get the feeling that every time I will handle a particular edge case scenario, someone will come up with a new scenario that the new behaviour conflicts with.

In this specific case, you could otherwise use VPN Director, configure a rule to redirect your entire LAN through the VPN, which would then create a redirection for DNS queries coming from your whole LAN subnet. I would probably add a rule to keep the router itself outside of the tunnel, to avoid one of these edge cases with unforeseen consequences.
 
Another side effect of this is you lose the capacity to resolve local hostnames on your ENTIRE network, since every query gets redirected to the remote server. Again, something that might be more disruptive when applied to the entire network rather than just to a few select clients.
 
In this specific case, you could otherwise use VPN Director, configure a rule to redirect your entire LAN through the VPN, which would then create a redirection for DNS queries coming from your whole LAN subnet. I would probably add a rule to keep the router itself outside of the tunnel, to avoid one of these edge cases with unforeseen consequences.

How would you do that?

I’ve already added LAN/24 to VPN Director and pointed it to OVPN1 but DNS queries still go out via DoT - reading above this is by design though?
 
I could make all DNS queries be forced through the VPN client's DNS server when routing mode is set to "All" instead of "VPN Director".

This is how it already works though?

When set to All Traffic and Exclusive it picks up in the VPN’s DNS servers.

When set to Director and Exclusive it picks up on DoT.
 
How would you do that?

I’ve already added LAN/24 to VPN Director and pointed it to OVPN1 but DNS queries still go out via DoT - reading above this is by design though?
In theory I would have expected it to be redirected since the NAT rule occurs in the PREROUTING stage. However it's possible that the rule only gets applied as traffic leaves the router, which would mean then that DoT will still be used. In that case, this is a technical limitation of the technology, and I have no idea how this could be changed. This is one of these complex scenarios that I have never personally tested, and there might possibly be no solution to.
 
In theory I would have expected it to be redirected since the NAT rule occurs in the PREROUTING stage. However it's possible that the rule only gets applied as traffic leaves the router, which would mean then that DoT will still be used. In that case, this is a technical limitation of the technology, and I have no idea how this could be changed. This is one of these complex scenarios that I have never personally tested, and there might possibly be no solution to.

I think Colin explained why above:


This is known behaviour, reported many times. Whether it's by design I couldn't say.

The advantage of Exclusive mode is that it uses dnsmasq to forward to the VPN's DNS servers. This allows you to do things like local name resolution and run Diversion, etc.

The problem comes when you turn on DoT. Stubby (DoT) inserts itself into the dnsmasq config (/tmp/resolv.dnsmasq) as the priority server. Effectively overriding the VPN's DNS entries.

So arguably it's doing what you asked of it. You enabled DoT as the system-wide resolver and it is. This issue doesn't occur when using Policy Rules because the clients requests don't go via dnsmasq.

So is there a rule or something that can be entered into the Custom Configuration lines on the OVPN settings to override the use of DoT, or will DoT always have priority in this situation regardless of any rules or custom configs?
 
So is there a rule or something that can be entered into the Custom Configuration lines on the OVPN settings to override the use of DoT, or will DoT always have priority in this situation regardless of any rules or custom configs?
It's a technical limitation with dnsmasq and iptables, unrelated to OpenVPN. dnsmasq handles name resolution, and it does so before iptables can intercept the client queries if your test results are accurate.
 
I could make all DNS queries be forced through the VPN client's DNS server when routing mode is set to "All" instead of "VPN Director".

I don't see how this helps. When set to ALL, the use of Exclusive already reconfigures DNSMasq to use the VPN's DNS server(s). If anything, it's the best (if still imperfect) solution if you insist on using the VPN provider's DNS servers (as I said before, the ideal solution is to use DoT on the WAN). Having ALL create a firewall redirect just like in the case of using the VPN Director seems regressive (as you explain below).

The users will then become responsible for dealing with cases where his VPN might be pushing invalid DNS servers, or if they configure multiple OpenVPN clients set to "All" (which doesn't make sense already anyway). It would allow clients with hardcoded DNS servers (like Android's Netflix) to be redirected, however it also means that you lose the redundancy of having two separate nameservers (if your VPN provider pushes more than one). This might become more critical when applying that to your entire network, rather than just a few select clients when using VPN Director.

This however may introduce problems if the DNS connection goes down, and your router will no longer have a working DNS server to connect to for name resolution since all DNS traffic might possibly be trying to use a private DNS server pushed by the VPN provider.

The consequences of having a connection go down are much less of a concern to me. ANYTIME a connection goes down, things become uncertain, and even unpredictable to some extent. There's no way around it. And so we can't become overly concerned about such situations. We have to assume the best case scenario. That's when having bad configuration options becomes a problem; when a normative situation isn't so normative in its behavior.

This is a case where trying to handle every single possible scenario becomes a headache for me. To be honest, I wish users used more straightforward and less over-complicated setups where they are configuring conflicting settings. I'm open to attempting to address some of these scenarios, but I get the feeling that every time I will handle a particular edge case scenario, someone will come up with a new scenario that the new behaviour conflicts with.

There's a more fundamental problem here that NO ONE (not even DD-WRT or FreshTomato) ever considers. And that's having all your clients associated w/ a *single* instance of DNSMasq! If instead those bound to the WAN and VPNs had their own instances (w/ the ability to forward local name resolution to the primary DNSMasq instance), you'd avoid a lot of these anomalies. It's the fact that we're trying to force a single instance of DNSMasq to server ALL comers, no matter their unique circumstances, that's the problem. Unfortunately, any single instance of DNSMasq can NOT be uniquely configured on a per client basis. ALL are treated the same.

Of course, I realize why this is NOT done; it's more complicated to manage from the firmware's perspective. It's just much simpler to keep reconfiguring the one and only instance of DNSMasq as the circumstances change, or bypassing it altogether. But this will inevitably lead to anomalies or undesirable side-effects. A single instance of DNSMasq simply can't server the interests of ALL its clients differentially.

In this specific case, you could otherwise use VPN Director, configure a rule to redirect your entire LAN through the VPN, which would then create a redirection for DNS queries coming from your whole LAN subnet. I would probably add a rule to keep the router itself outside of the tunnel, to avoid one of these edge cases with unforeseen consequences.

Once the VPN Director is activated, the router itself is no longer on the VPN anyway. And due to a change made a few years ago to no longer have the router itself dependent on DNSMasq for DNS, neither is DNS. In more recent builds, ASUS has taken that even a step further by creating static routes to bind the WAN's DNS servers to the WAN. The only way the router will become dependent on DNSMasq is if you change the setting "Wan: Use local caching DNS server as system resolver (default: No)" in Tools > Other Settings to "Yes".
 
I don't see how this helps.
It would help for scenarios where you have a LAN client that uses a hardcoded DNS server (like Netflix for Android does). Also consistency, the behaviour would be identical to what VPN Director mode does.

The consequences of having a connection go down are much less of a concern to me. ANYTIME a connection goes down, things become uncertain, and even unpredictable to some extent. There's no way around it. And so we can't become overly concerned about such situations.
The client needs to be able to automatically reconnect if this is configured in your client as this is a feature of OpenVPN.

There's a more fundamental problem here that NO ONE (not even DD-WRT or FreshTomato) ever considers. And that's having all your clients associated w/ a *single* instance of DNSMasq! If instead those bound to the WAN and VPNs had their own instances (w/ the ability to forward local name resolution to the primary DNSMasq instance), you'd avoid a lot of these anomalies. It's the fact that we're trying to force a single instance of DNSMasq to server ALL comers, no matter their unique circumstances, that's the problem. Unfortunately, any single instance of DNSMasq can NOT be uniquely configured on a per client basis. ALL are treated the same.
A major reason there is the fact that you cannot configure your clients to use a different port for their resolver. To run multiple dnsmasq instances, you'd need to allocate multiple unique LAN IPs to your router, and bind each dnsmasq instance to a different IP. That's one of these "overly complicated" scenarios where you are more likely to break something else, and make everything very difficult to troubleshoot.

And that's assuming that dnsmasq even allows running multiple instances at the same time.

And due to a change made a few years ago to no longer have the router itself dependent on DNSMasq for DNS, neither is DNS. In more recent builds,
The reasons I was provided by engineers was that this was necessary for some ISPs (who push a temporary DNS server that cannot resolve anything outside of the ISP - a bit similar to a captive portal if you wish), and also that there are cases (for monitoring for instance) where you must ensure you aren't being fed stale date by the dnsmasq cache, hence the need to directly query the remote servers. I kept the option to revert that for any niche case that might need it otherwise, but it's not a supported configuration, and was done for a reason.

As I said: once you try to deal with every imaginable scenario, it gets ridiculously complicated, and there are no perfect solution. The fact that VPNs are being used for a non intended purpose is opening the door to these scenarios. A VPN is supposed to be used to securely connect to a remote network. Anything else is outside of the box already.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top