What's new

Use VPN Exclusive DNS and Local 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!

ragnaroknroll

Regular Contributor
I have a question related to https://www.snbforums.com/threads/local-dns-and-vpn-issue.55312/#post-468948, but thought I'd post a separate question since my setup is slightly different than what is described there.


I have an Asus RC-AC86U router running Merlin v386.4. Its relevant configuration options are as follows:
Running a DNS leak test with my VPN provider using this configuration shows no leaks, but I lose the ability to use local hostnames in the browser.


I now make the following change to the original configuration described above:
This enables me to use local hostnames in the browser, but the DNS leak test with my VPN provider fails.


I now revert back to the Accept DNS Configuration back to Exclusive and make the following change instead:
  • LAN -> DNS Server 1 -> <local router ip>
I am again able to use local hostnames in the browser, but the DNS leak test with my VPN provider fails again.


Is there any way I can both pass my VPN provider's DNS leak test and continue to use local hostnames in the browser?
 
Some of us have been having a back and forth discussion on this very issue over the past week or so. As you've discovered, Exclusive bypasses DNSMasq, so you lose access to all its features (local name resolution, caching, ad blocking, etc.). And Strict actually doesn't even work properly. For all intents and purposes, it's no better than Relaxed, meaning ALL your configured DNS servers, whether from the WAN, DHCP server, or pushed by the VPN provider are made accessible. Just a matter of luck which ones get chosen at any given time. That's why so many resort to Exclusive, despite its other limitations.

What you can do is specify Disabled for Accept DNS Configuration on the OpenVPN client. Then configure the WAN w/ your preferred public DNS servers (e.g., 1.1.1.1 and 1.0.0.1). Those will be copied down to DNSMasq for the benefit of the WLAN/LAN clients. Then bind those same servers to the VPN using policy rules.

Code:
Cloudflare (primary) <blank> 1.1.1.1 OVPN1
Cloudflare (backup) <blank> 1.0.0.1 OVPN1

Before 386.4, that was sufficient. But now in 386.4, ASUS in their infinite wisdom decided to create static routes to bind the WAN DNS servers to the WAN! And so now when those policy rules redirect DNS through the VPN's alternate routing table, that routing table *also* contains those same static routes, thus the servers are still bound to the WAN. To overcome it, you also need to add static routes to the OpenVPN client's custom config field to bind them to the tunnel.

Code:
route 1.1.1.1
route 1.0.0.1

These will have a lower metric than the static routes for the WAN, and so now all your DNS will finally be bound to the VPN. This will also bind the router itelf to those same DNS servers. Even for the purposes of the WAN connectivity check. IOW, you should have complete DNS stealthiness w/ this configuration. You can verify all that w/ my DNS monitoring utility.

 
Last edited:
@eibgrad - Thank you so much for your detailed and patient response. I really appreciate it. I am sorry that I missed the discussion you had about this last week in my searches on this subject. I've just found it and read through it: https://www.snbforums.com/threads/v...ries-default-isp-servers-rt-ac86u-386-4.77091, and it definitely helps me understand this issue in a bit more detail. Will go ahead and configure my router as you've suggested here for now. Cheers!

PS: I really do hope this process can be simplified in a future revision of the Merlin firmware ;-)
 
Guys, I have almost the same configuration (RT-AX86U, 386.4), the only thing, I use DoT DNS instead of WAN DNS. And when I use selective routing with VPN Director (policy rules) and Accept DNS Configuration is set to Exclusive, all VPN queries go through DoT DNS instead of DNS servers that are pushed by my VPN server, and of cause they are not tunneled.

I use the same method that @eibgrad suggested, to route DNS queries to VPN tunnel in сlient config, but then all DNS queries on the router go through the VPN tunnel, even those, that are not set in the VPN Director (policy rules).

Do I understand correctly that we cannot separate DNS queries, to be sent through VPN tunnel if destination is in policy rules or through DoT DNS if it's not in the policy rules?
 
Guys, I have almost the same configuration (RT-AX86U, 386.4), the only thing, I use DoT DNS instead of WAN DNS. And when I use selective routing with VPN Director (policy rules) and Accept DNS Configuration is set to Exclusive, all VPN queries go through DoT DNS instead of DNS servers that are pushed by my VPN server, and of cause they are not tunneled.

That doesn't sound right. When DoT is enabled on the WAN, this only affects the WLAN/LAN clients, at least by default. And if you're using Exclusive on the OpenVPN client, and policy rules, this takes the router itself OFF the VPN, and all your VPN clients are bound to the VPN for *all* their network activity, DNS and whatever else. It's only those WLAN/LAN clients NOT bound to the VPN that end up using DoT. And since the router itself is NOT bound to the VPN, DoT is accessed over the WAN.

At least that would be the normal, expected sequence of events given your description of the configuration.

I use the same method that @eibgrad suggested, to route DNS queries to VPN tunnel in сlient config, but then all DNS queries on the router go through the VPN tunnel, even those, that are not set in the VPN Director (policy rules).

The only way to use split DNS (and that's basically what you're asking for) is to use Exclusive on the VPN. That keeps those bound to the VPN using the VPN for DNS, while those NOT bound to the VPN using the WAN for DNS. But as the OP in this thread found out, the use of Exclusive bypasses DNSMasq, so you lose access to all its benefits in the process (local name resolution, local caching, ad blocking, multiple DNS servers, etc.).

The only other way to get something much better would be to implement a *second* instance of DNSMasq, so that both those bound to the WAN and those bound to the VPN would have their own instances, and thus all the same benefits. But alas that's NOT how the router implements split DNS. It keeps things simple and bypasses DNSMasq for those bound to the VPN w/ Exclusive.

Do I understand correctly that we cannot separate DNS queries, to be sent through VPN tunnel if destination is in policy rules or through DoT DNS if it's not in the policy rules?

Adding the DoT servers to routing policy is one way to bind them to the VPN, if that is your intent.

As you can see, it can get all get VERY complicated. The best thing to do is to describe how you want things to behave, then we can make specific suggestions to achieve those ends. But trying to reverse-engineer what makes sense based on what you *believe* is happening makes for a confusing conversation.
 
And since the router itself is NOT bound to the VPN,

The router not being bound to the VPN, is that why the bottom two rows are showing up red in your tool? My devices show up green and with the VPN DNS, but the bottom two are my WAN IP is destined to the DNS destinations set in my WAN DNS1 and 2 and are red.

I do have VPN set to exclusive, I have DNS Filter to Router and redirect traffic through VPN Director policy rules. Does this mean that because my router is not bound that I have the possibility of a DNS leak, besides the split tunneling I have with the rules in my VPN Director?

v-------------- sender ---------------v v------------- recipient -------------v
udp src=192.168.1.107 dst=192.168.1.1 dport=53 src=192.168.1.1 dst=192.168.1.107

udp src=34.276.125.70 dst=1.1.1.1 dport=53 src=1.1.1.1 dst=34.276.125.70
udp src=34.276.125.70 dst=9.9.9.9 dport=53 src=9.9.9.9 dst=34.276.125.70
 
The router not being bound to the VPN, is that why the bottom two rows are showing up red in your tool? My devices show up green and with the VPN DNS, but the bottom two are my WAN IP is destined to the DNS destinations set in my WAN DNS1 and 2 and are red.

I do have VPN set to exclusive, I have DNS Filter to Router and redirect traffic through VPN Director policy rules. Does this mean that because my router is not bound that I have the possibility of a DNS leak, besides the split tunneling I have with the rules in my VPN Director?

v-------------- sender ---------------v v------------- recipient -------------v
udp src=192.168.1.107 dst=192.168.1.1 dport=53 src=192.168.1.1 dst=192.168.1.107

udp src=x.x.x.x dst=1.1.1.1 dport=53 src=1.1.1.1 dst=x.x.x.x
udp src=x.x.x.x dst=9.9.9.9 dport=53 src=9.9.9.9 dst=x.x.x.x

The use of Exclusive + policy rules means *only* those devices you've specifically bound to the VPN are routed over the VPN for all purposes, DNS et al. All other WLAN/LAN devices and the router continue to use the WAN for all their purposes.

Does the fact the router does NOT participate in the VPN (those RED lines) represent a DNS leak? It depends on your definition of a DNS leak. Given the fact that presumably at least *some* WLAN/LAN clients are NOT bound to the VPN, and presumably they are NOT considered a DNS leak, I don't see why the router should be either. But if you consider either of them to represent DNS leaks, then you probably shouldn't be using Exclusive, since by definition, this is the behavior to be expected.

This is why I continually stress that it matters what YOU see as a DNS leak that matters too. It's NOT just about some technical definition from some internet website, or even me.

Also, realize the DNS filter (I assume this is global) will only redirect rogue DNS queries from WLAN/LAN clients back through DNSMasq, which when using Exclusive w/ the VPN, only forces those queries back over the WAN, just like *all* WLAN/LAN clients NOT bound to the VPN.

I suspect most ppl initially only have a vague notion of what it means to prevent DNS leaks. Perhaps even relying solely on internet based DNS leak testing tools. They'll configure the router and *hope* it does the right thing. But when something like my script comes along, it then causes ppl to question what's actually happening (which is its intent). And you may end up w/ a completely different perspective on what is or isn't correct behavior. IOW, without the script, ignorance is bliss. With the script, you may still conclude all is well, or want to change your strategy to better meet YOUR expectations.

P.S. You might want to obscure your public IP (as I did in my response). The script provides a menu option for that purpose.
 
Last edited:
Some of us have been having a back and forth discussion on this very issue over the past week or so. As you've discovered, Exclusive bypasses DNSMasq, so you lose access to all its features (local name resolution, caching, ad blocking, etc.). And Strict actually doesn't even work properly. For all intents and purposes, it's no better than Relaxed, meaning ALL your configured DNS servers, whether from the WAN, DHCP server, or pushed by the VPN provider are made accessible. Just a matter of luck which ones get chosen at any given time. That's why so many resort to Exclusive, despite its other limitations.

What you can do is specify Disabled for Accept DNS Configuration on the OpenVPN client. Then configure the WAN w/ your preferred public DNS servers (e.g., 1.1.1.1 and 1.0.0.1). Those will be copied down to DNSMasq for the benefit of the WLAN/LAN clients. Then bind those same servers to the VPN using policy rules.

Code:
Cloudflare (primary) <blank> 1.1.1.1 OVPN1
Cloudflare (backup) <blank> 1.0.0.1 OVPN1

Before 386.4, that was sufficient. But now in 386.4, ASUS in their infinite wisdom decided to create static routes to bind the WAN DNS servers to the WAN! And so now when those policy rules redirect DNS through the VPN's alternate routing table, that routing table *also* contains those same static routes, thus the servers are still bound to the WAN. To overcome it, you also need to add static routes to the OpenVPN client's custom config field to bind them to the tunnel.

Code:
route 1.1.1.1
route 1.0.0.1

These will have a lower metric than the static routes for the WAN, and so now all your DNS will finally be bound to the VPN. This will also bind the router itelf to those same DNS servers. Even for the purposes of the WAN connectivity check. IOW, you should have complete DNS stealthiness w/ this configuration. You can verify all that w/ my DNS monitoring utility.

Since I get to continue using the vpn for almost a month, I might as well keep trying.
Where do I enter these codes?
 
@eibgrad Do you think could help me figure this thing out so I can use exclusive and DnsMasq?
Not sure how to enter those commands in the router.
 
@eibgrad Do you think could help me figure this thing out so I can use exclusive and DnsMasq?
Not sure how to enter those commands in the router.

You can't have clients bound to the VPN w/ Exclusive *and* have them using DNSMasq at the same time, at least when using the VPN Director. The two are mutually exclusive as implemented in the router.

If you're NOT using the VPN Director but routing ALL your traffic over the VPN, then the use of Exclusive will reconfigure DNSMasq to only use the push'd DNS server(s) from the OpenVPN server, and ALL clients will use DNSMasq as their local proxy.
 
I think I remember now. It was to do with tunneling because I was having issues connecting to the server if the client was enabled…but now that I switched to Surfshark, that issue went away…so never mind.

I just want to make sure the way I have it now is the recommended settings for this router to work properly with the vpn.
 
@eibgrad Is there a con of having these settings permanent?
Sorry I keep asking. If this is not the best setting when using a VPN, then what should I change?

disabled.jpg

resolver.jpg
 
@eibgrad Is there a con of having these settings permanent?
Sorry I keep asking. If this is not the best setting when using a VPN, then what should I change?

View attachment 40015
View attachment 40016

Whether you want to use the DNS servers of your ISP, or some third party (e.g., Cloudflare), or those of your VPN provider, is just a matter of preference. Obviously certain choices and how they are accessed wrt network interface can have implication when it comes to DNS leaks. Some are obvious DNS leaks, others are more subtle, and in some cases, there isn't even agreement as to whether a given configuration constitutes a DNS leak. So YOU have to decide the source of your DNS, and how it should be accessed, such that it comports with YOUR intentions. That's why I can't easily tell you what you should do. I can only tell you given what you've configured, and your stated intentions, whether it will work as intended.

As far as the "Wan: Use local caching DNS server as system resolver (default: No)" option, as I explained in the following link ...


... it's my understand that this option was only added in response to ppl messing w/ the WAN's DNS before DoT became a built-in feature, and that having this option set to Yes merely returns the router to the behavior it had before the option was added. FWIW, in the case of DD-WRT, its default behavior is identical to having that option set to Yes. The fact the WAN is NOT bound to DNSMasq by default in the case of Merlin makes it the exception.

Returning to that same link above, you'll notice I provided an example of what NOT having the option set to Yes means in the case of DoT. It actually creates a DNS leak! And that's after having explicitly enabled DoT for express purpose of preventing it. Then again, some would argue it doesn't matter because they're intent is to only secure the WLAN/LAN clients, NOT the router itself.

Again, this is what makes all this DNS stuff so complicated. There is no "one size fits all" answer.
 
Thanks for your response. I have been reading that post you provided, but honestly, I have no idea what you guys are talking about with regards to the script you created.
I still don't know what that is doing or what its purpose is. All of that just goes over my head lol.
 
Let me try to simplify things for myself. What I've encountered is if I configure the vpn via the router (network wise), things get a little tricky because some servers do not work with my bank.
I have to use specific servers, which I understand. So the one server that works well with my bank is in NY, but that server's ping is too high for online gaming and you can notice the lag a lot while in game.

Now, the server that does work well for gaming and that is even faster and lower ping than what I get from my ISP...does not work with my bank.
So what I've done is....

I am using VPN director and only assigning the devices I want to use the vpn, which is configured to use the NY server which works well for banks.....and, I am using the windows app on my gaming PC (which is excluded from the VPN director list) and connecting to the gaming server. Then, If I need to access the bank, I just change server on that PC in order to access the bank.

Is this OK?
 
Let me try to simplify things for myself. What I've encountered is if I configure the vpn via the router (network wise), things get a little tricky because some servers do not work with my bank.
I have to use specific servers, which I understand. So the one server that works well with my bank is in NY, but that server's ping is too high for online gaming and you can notice the lag a lot while in game.

Now, the server that does work well for gaming and that is even faster and lower ping than what I get from my ISP...does not work with my bank.
So what I've done is....

I am using VPN director and only assigning the devices I want to use the vpn, which is configured to use the NY server which works well for banks.....and, I am using the windows app on my gaming PC (which is excluded from the VPN director list) and connecting to the gaming server. Then, If I need to access the bank, I just change server on that PC in order to access the bank.

Is this OK?

If that works for you, of course it's OK. But whether that's the *best* solution is another question entirely.

Given your description of the problem, I'd be inclined to configure a second OpenVPN client on the router for the sole purpose of connecting to the bank. Then create policy rules based on the bank's public IP(s) that force those destinations over that OpenVPN client. You'd have to make it OVPN1 to make sure it had higher priority than OVPN2. OVPN2 would be for all other VPN purposes.

At least that's what I would probably be doing if in the same circumstances. In this way, you don't need to be juggling servers on the PC, or limit your access of the bank to that one specific device. But if your current technique works to your satisfaction, perhaps that's sufficient. In most cases, a VPN that runs on the desktop is going to be faster than if run on the router anyway.
 
Thanks eibgrad! - I just wanted to make sure that this setup was not going to interfere with anything as I know I can't have 2 vpns at the same time. Even though I made sure the PC was not connected to the vpn at the router...I just wanted to just make sure I hadn't missed a step. Glad to know this is OK as far as "it works" lol.

But, this is great! - I will definitely will try your suggestion as it would definitely make it simpler.

Now, those rules to have this done, where and how do I create them...and what would they look like?
 
Last edited:
Thanks eibgrad! - I just wanted to make sure that this setup was not going to interfere with anything as I know I can't have 2 vpns at the same time. Even though I made sure the PC was not connected to the vpn at the router...I just wanted to just make sure I hadn't missed a step. Glad to know this is OK as far as "it works" lol.

But, this is great! - I will definitely will try your suggestion as it would definitely make it simpler.

Now, those rules to have this done, where and how do I create them...and what would they look like?

You can have multiple, concurrent OpenVPN clients as long as you correctly configure them to NOT conflict. The GUI was specifically designed for this purpose, w/ lower number clients have higher priority than higher numbered clients.

In most every case, when using multiple, concurrent OpenVPN clients, you need to make sure all of them are using routing policy rules, even if it means including all your WLAN/LAN clients (e.g., 192.168.1.0/24). So as I said, you could configure OpenVPN client #1 to connect to the server that works w/ the bank and add rules that route those domains over the VPN. But you'd have to use nslookup or similar tools to pre-resolve those public IPs.

When I use nslookup to resolve bankofamerica.com, I find I need the following two rules to route the following destination (remote) IPs.

Code:
<blank> 171.161.148.150 OVPN1
<blank> 171.159.228.150 OVPN1

Of course, there could many other domains required besides the most obvious one.

Then configure OpenVPN #2 w/ what other server(s) you prefer, and appropriate routing policy rules as you see fit.

Code:
192.168.1.0/24 <blank> OVPN2

OpenVPN client #1 will always have precedence over OpenVPN #2. That why it works.
 

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