What's new

Issue with vpn client 'Accept DNS Configuration' parameter

  • 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!

hs222

New Around Here
Hi,
my configuration : RT-AC86U / v 384.8_2

on vpn client configuration, "Accept DNS Configuration = Exclusive" does not work as soon as "Redirect Internet traffic" is set to "Policy Rules" ( or "Policy Rules Strict" )

When "Accept DNS Configuration " is set to "exclusive", DNS servers pushed by the remote VPN should be used instead of the DNS set in the WAN section; concretely in such configuration /tmp/resolv.dnsmasq should contain the list of the VPN's DNS servers and nothing else, but actually resolv.dnsmasq contains the WAN's DNS servers.

For information, if I change "Redirect Internet traffic" from "Policy Rules" to "All", then resolv.dnsmasq is correctly set, likewise, when I change"Accept DNS Configuration" from "Exclusive" to "Strict" the VPN's DNS IPs are correctly pushed to resolv.dnsmasq (just before the wan's dns). So the issue seems to be linked to the combination of the Exclusive and the Policy Rules options.

Am I missing something or is it really a bug?

Thanks
 
Hi,
my configuration : RT-AC86U / v 384.8_2

on vpn client configuration, "Accept DNS Configuration = Exclusive" does not work as soon as "Redirect Internet traffic" is set to "Policy Rules" ( or "Policy Rules Strict" )

When "Accept DNS Configuration " is set to "exclusive", DNS servers pushed by the remote VPN should be used instead of the DNS set in the WAN section; concretely in such configuration /tmp/resolv.dnsmasq should contain the list of the VPN's DNS servers and nothing else, but actually resolv.dnsmasq contains the WAN's DNS servers.

For information, if I change "Redirect Internet traffic" from "Policy Rules" to "All", then resolv.dnsmasq is correctly set, likewise, when I change"Accept DNS Configuration" from "Exclusive" to "Strict" the VPN's DNS IPs are correctly pushed to resolv.dnsmasq (just before the wan's dns). So the issue seems to be linked to the combination of the Exclusive and the Policy Rules options.

Am I missing something or is it really a bug?

Thanks
I document the behavior on my blog site
https://x3mtek.com/torguard-openvpn-2-4-client-setup-for-asuswrt-merlin-firmware/

I need to update the workaround in the blog post. Rather than using Strict, one can also set Accept DNS Configuration to None. This will force the OpenVPN client to use the DNS specified in the WAN interface. To secure DNS using this method, you can use Stubby DNS.
https://github.com/Xentrk/Stubby-Installer-Asuswrt-Merlin
 
Last edited:
Xentrk, thanks for your help, I found very interesting informations that lead me to perform some searching in the asuwrt-merlin github sources.

Answering my own question, I can say I was really missing something, /tmp/resolv.dnsmasq is not always used, hence there is no bug and the two options I suspected to be broken are working perfectly!!

In fact, when "Accept DNS Configuration" is set to Exclusive and Policy Rules are activated, the dns server ip of a dns query can be forced to the vpn's dns ip thanks to a set of iptable rules, and this mechanism is independent of the content of resolv.dnsmasq.

For those who might be interested with some details, the iptable DNS configuration is performed by a script named /etc/openvpn/fw/client[n]-dns.sh (n is the vpn client number, 1 to 5), this script is itself generated by /etc/openvpn/client[n]/updown.sh, which I presume is run when the vpn client [n] starts.

In fact, that was the reason of my post, I was misled to believe there was a bug because during the configuration of my new RT, instead of leaving it blank I entered my DNS IPs into the DNS server 1/2 parameters of the DHCP configuration page (very very bad!), so that's the reason why my PC was using these two DNS servers and not those pushed by the VPN.
 
I keep meaning to ask about one section of that post, I hope you don't mind if I do it here...
Regarding DNSmasq and OpenVPN, you mention "To resolve the DNS and routing issues when using Policy Rules with Asuswrt-Merlin, set Accept DNS Configuration to “Strict” and specify the DNS server for the VPN tunnel to use by adding the dhcp-option DNS command in the Custom Configuration section."
What DNS server address are you suggesting to use here - the router's address or whatever DNS provider you've selected (ISP, Cloudflare, etc.)? I would assume the router's address otherwise the VPN client will bypass Diversion, but I'll admit I don't fully understand how DNS is handled for VPN clients when selective routing is being used.
 
I keep meaning to ask about one section of that post, I hope you don't mind if I do it here...
Regarding DNSmasq and OpenVPN, you mention "To resolve the DNS and routing issues when using Policy Rules with Asuswrt-Merlin, set Accept DNS Configuration to “Strict” and specify the DNS server for the VPN tunnel to use by adding the dhcp-option DNS command in the Custom Configuration section."
What DNS server address are you suggesting to use here - the router's address or whatever DNS provider you've selected (ISP, Cloudflare, etc.)? I would assume the router's address otherwise the VPN client will bypass Diversion, but I'll admit I don't fully understand how DNS is handled for VPN clients when selective routing is being used.
The recommendation was made so the Diversion ad-blocker will work when using an OpenVPN tunnel when using Policy Rules. If you set Accept DNS Configuration to Exclusive, dnsmasq is bypassed. Diversion requires dnsmasq in order to work. So that is the reason for the recommendation.

Cloudflare 1.1.1.1 is a good one. Rather than the Strict setting a placing the line "dhcp-option DNS 1.1.1.1" in the custom config section, you can set Accept DNS Configuration to None. It will then default to the DNS entries on the WAN page.

@Jack Yaz created a fork of the Stubby installer that works with the AC86U. Using Stubby will encrypt DNS queries. The current script is setup to use Cloudflare DNS over TLS encryption.

https://github.com/JackYaz/Stubby-Installer-Asuswrt-Merlin
 
@Jack Yaz created a fork of the Stubby installer that works with the AC86U. Using Stubby will encrypt DNS queries. The current script is setup to use Cloudflare DNS over TLS encryption.
Thanks, I've been watching the Stubby thread, but am currently still using dnscrypt-proxy with DoH. I was thinking of switching to Stubby soon but noticed that "opkg update" seems to break the @Jack Yaz fork. I'll read the thread bit more thoroughly and think again about switching, though as far as I know even with DoH my DNS is still encrypted.

What confused me was that with VPN DNS set to Strict and "dhcp-option DNS 1.1.1.1" in the config, I would have expected the VPN clients to just use Cloudflare and completely bypass dnsmasq, which is why I thought maybe I needed the router's IP in "dhcp-option DNS", not Cloudflare's IP. There's some logic in the way the policy-based routing handles DNS that I don't entirely understand yet. Edit: I think I'm confusing "Strict" with "Exclusive", I think I need to work out exactly how DNS is handled in Strict mode.

Apologies for the thread hijack!

For those who might be interested with some details, the iptable DNS configuration is performed by a script named /etc/openvpn/fw/client[n]-dns.sh (n is the vpn client number, 1 to 5), this script is itself generated by /etc/openvpn/client[n]/updown.sh, which I presume is run when the vpn client [n] starts.

Edit2: Oops, just noticed the post from @hs222 so I'll look at the code and scripts, which might shed some light on things. Useful info, thanks for sharing it. :)
 
Last edited:
Thanks, I've been watching the Stubby thread, but am currently still using dnscrypt-proxy with DoH. I was thinking of switching to Stubby soon but noticed that "opkg update" seems to break the @Jack Yaz fork. I'll read the thread bit more thoroughly and think again about switching, though as far as I know even with DoH my DNS is still encrypted.

What confused me was that with VPN DNS set to Strict and "dhcp-option DNS 1.1.1.1" in the config, I would have expected the VPN clients to just use Cloudflare and completely bypass dnsmasq, which is why I thought maybe I needed the router's IP in "dhcp-option DNS", not Cloudflare's IP. There's some logic in the way the policy-based routing handles DNS that I don't entirely understand yet. Edit: I think I'm confusing "Strict" with "Exclusive", I think I need to work out exactly how DNS is handled in Strict mode.

Apologies for the thread hijack!



Edit2: Oops, just noticed the post from @hs222 so I'll look at the code and scripts, which might shed some light on things. Useful info, thanks for sharing it. :)
Xentrk, thanks for your help, I found very interesting informations that lead me to perform some searching in the asuwrt-merlin github sources.

Answering my own question, I can say I was really missing something, /tmp/resolv.dnsmasq is not always used, hence there is no bug and the two options I suspected to be broken are working perfectly!!

In fact, when "Accept DNS Configuration" is set to Exclusive and Policy Rules are activated, the dns server ip of a dns query can be forced to the vpn's dns ip thanks to a set of iptable rules, and this mechanism is independent of the content of resolv.dnsmasq.

For those who might be interested with some details, the iptable DNS configuration is performed by a script named /etc/openvpn/fw/client[n]-dns.sh (n is the vpn client number, 1 to 5), this script is itself generated by /etc/openvpn/client[n]/updown.sh, which I presume is run when the vpn client [n] starts.

In fact, that was the reason of my post, I was misled to believe there was a bug because during the configuration of my new RT, instead of leaving it blank I entered my DNS IPs into the DNS server 1/2 parameters of the DHCP configuration page (very very bad!), so that's the reason why my PC was using these two DNS servers and not those pushed by the VPN.
Yes, I enjoy uncovering and seeing the brilliant coding of Merlin firmware.

I have analyzed the inner workings of how Merlin firmware dynamically generates the client[n]-dns.sh scripts as I have made extensive custom mods to updown.sh and vpnrouting.sh and had to make sure not to break the firmware in the process. You can read more here if curious.
https://www.snbforums.com/threads/iptables-ipsets-and-vpn-kill-switch.48130/
 
Thanks for the link, it was fascinating but unfortunately I'm still on a steep learning curve for iptables, so I only followed some of it. I love figuring out how things work so will bookmark it to refer back as my understanding grows.

One quick question for either of you (or anyone else), @hs222 explained that /tmp/resolv.dnsmasq isn't used when Policy Rules are activated and DNS is set to Exclusive, and that DNS queries are handled by iptables rules. That makes sense and of course works fine here when I use browser-based tools to check DNS servers, which show my VPN DNS.

However I'm really struggling to work out what happens when Policy Rules are activated and DNS is set to Strict. By my understanding "Strict" should use the VPN DNS first, and then the WAN DNS if the VPN DNS doesn't respond. But every browser-based DNS test I run in this mode shows that I'm using my ISP's DNS.

I'm poking around iptables trying to find something that marks DNS queries and then routes them differently, but I don't fully understand how to query the firewall, or interpret what I'm seeing.

I know I could disable the VPN's DNS and rely on dnscrypt-proxy or Stubby, but I'd really like to understand why this isn't working - or whether my understanding is incorrect. Should "Strict" be using the VPN DNS if available if Policy Rules are used? The wiki doesn't cover this combination as far as I can tell, I'm currently searching the forum as I'm sure this must have come up before.
 
Last edited:
Thanks for the link, it was fascinating but unfortunately I'm still on a steep learning curve for iptables, so I only followed some of it. I love figuring out how things work so will bookmark it to refer back as my understanding grows.

One quick question for either of you (or anyone else), @hs222 explained that /tmp/resolv.dnsmasq isn't used when Policy Rules are activated and DNS is set to Exclusive, and that DNS queries are handled by iptables rules. That makes sense and of course works fine here when I use browser-based tools to check DNS servers, which show my VPN DNS.

However I'm really struggling to work out what happens when Policy Rules are activated and DNS is set to Strict. By my understanding "Strict" should use the VPN DNS first, and then the WAN DNS if the VPN DNS doesn't respond. But every browser-based DNS test I run in this mode shows that I'm using my ISP's DNS.

I'm poking around iptables trying to find something that marks DNS queries and then routes them differently, but I don't fully understand how to query the firewall, or interpret what I'm seeing.

I know I could disable the VPN's DNS and rely on dnscrypt-proxy or Stubby, but I'd really like to understand why this isn't working - or whether my understanding is incorrect. Should "Strict" be using the VPN DNS if available if Policy Rules are used? The wiki doesn't cover this combination as far as I can tell, I'm currently searching the forum as I'm sure this must have come up before.
I made an attempt to explain the Accept DNS Configuration settings when using VPN in the blog post
https://x3mtek.com/torguard-openvpn-2-4-client-setup-for-asuswrt-merlin-firmware/

Read that first and then let me know if you have questions.
TLDR:
  1. The definition of the Accept DNS Configuration field values are as follows:
    • Disabled: DNS servers pushed by VPN provided DNS server are ignored.
    • Relaxed: DNS servers pushed by VPN provided DNS server are prepended to the current list of DNS servers, of which any can be used.
    • Strict: DNS servers pushed by the VPN provided DNS server are prepended to the current list of DNS servers, which are used in order (existing DNS servers are only used if VPN provided ones don’t respond).
    • Exclusive: Only the pushed VPN provided DNS servers are used.

I have a list of iptables commands that show how the firmware is creating the iptable rules using the different options if you want to get into the weeds. But I will not be in a position to provide for another five days or so.
 
You can try in vpn client Custom Configuration
example:
Code:
dhcp-option DNS 8.8.8.8
dhcp-option DNS 8.8.4.4
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
and change 8.8.8.8 and 8.8.4.4 to whatever your vpn dns is, Should work with strict/exclusive

edit: see thats already been suggested
 
Last edited:
You can try in vpn client Custom Configuration
example:
Code:
dhcp-option DNS 8.8.8.8
push "dhcp-option DNS 8.8.8.8"
and change 8.8.8.8 to whatever your vpn dns is

edit: see thats already been suggested
My new recommendation is to install Stubby to encrypt DNS and set Accept DNS Configuration to Disabled. The VPN tunnel will then use Stubby. Then, no need to add the dhcp-option to the Custom Config section. I will update the blog post next week.
 
and change 8.8.8.8 and 8.8.4.4 to whatever your vpn dns is, Should work with strict/exclusive
edit: see thats already been suggested
Thanks - and apologies to @Xentrk for not understanding the suggestion properly earlier, clearly I shouldn't be messing with this stuff late at night/early in the morning. :oops: The VPN server is pushing "dhcp-option DNS" so I assumed it wasn't needed in custom config, but I've added it. In all of my messing about this afternoon, at one point it seemed to work - but now I can't replicate it, and whenever I use the Policy Rules, I get the WAN DNS not the VPN ones. As soon as I turn off Policy Rules, DNS stops leaking.

It's not a major issue - I can use DOT or DOH with Cloudflare using either Stubby or dnscrypt-proxy - I stripped out dnscrypt-proxy earlier and got Stubby working. I've currently removed all entware packages so I can test the VPN, but when I re-install I will probably stick with Stubby moving forward.

But this apparent DNS leak is annoying me. Plus I would also really like to understand how things (are supposed to) work, how the router should be handling DNS requests from VPN clients using policy based routing, and what mechanisms it uses to achieve that.

I can see the VPN DNS servers being added to /tmp/resolv.dnsmasq, but with Policy rules I'm still not using them, so I assume it's supposed to be handled by the firewall.

I have a list of iptables commands that show how the firmware is creating the iptable rules using the different options if you want to get into the weeds. But I will not be in a position to provide for another five days or so.
That would be really helpful if you have time. As I said, I can work around this situation, but I don't know if I've done something wrong or just misunderstood something. I'll probably try a factory reset at some point just to rule out some dodgy config I might have made and forgotten about.

Thanks everyone for all the info and advice so far.
 
Thanks - and apologies to @Xentrk for not understanding the suggestion properly earlier, clearly I shouldn't be messing with this stuff late at night/early in the morning. :oops: The VPN server is pushing "dhcp-option DNS" so I assumed it wasn't needed in custom config, but I've added it. In all of my messing about this afternoon, at one point it seemed to work - but now I can't replicate it, and whenever I use the Policy Rules, I get the WAN DNS not the VPN ones. As soon as I turn off Policy Rules, DNS stops leaking.

It's not a major issue - I can use DOT or DOH with Cloudflare using either Stubby or dnscrypt-proxy - I stripped out dnscrypt-proxy earlier and got Stubby working. I've currently removed all entware packages so I can test the VPN, but when I re-install I will probably stick with Stubby moving forward.

But this apparent DNS leak is annoying me. Plus I would also really like to understand how things (are supposed to) work, how the router should be handling DNS requests from VPN clients using policy based routing, and what mechanisms it uses to achieve that.

I can see the VPN DNS servers being added to /tmp/resolv.dnsmasq, but with Policy rules I'm still not using them, so I assume it's supposed to be handled by the firewall.


That would be really helpful if you have time. As I said, I can work around this situation, but I don't know if I've done something wrong or just misunderstood something. I'll probably try a factory reset at some point just to rule out some dodgy config I might have made and forgotten about.

Thanks everyone for all the info and advice so far.
I recently made a post about the DNS Leak concern here if you want to check it out https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/page-81#post-455918

Installing Unbound may be a solution and still considering testing with it. I use unbound on my pfSense appliance with no leaks and have been thinking of applying the config to Merlin FW to see if it can be used to resolve the concern.

One of the reasons I decided to not implement DNSSEC option on Stubby is that it causes most of the validation tests to fail, causing people to then think Stubby was not working. It is further compounded by the issue that the Cloudflare test page is not configured for DNSSEC. In my testing, I added a DNSSEC detector add on to Firefox. I was very surprised to discover that most sites I visit do not have DNSSEC configured. Adoption rates for DNSSEC are not as widespread as I first believed. I searched on “DNSSEC adoption rates” and found some good articles on the topic.
 
Last edited:
Thanks, at this point I've pretty much decided that encrypting the DNS queries is the way to go. I want to retain local DNS resolution for one thing, so Exclusive is out.

Yes, I'd prefer to route DNS queries down the tunnel, but that's just the perfectionist side of me. Using Stubby is a perfectly acceptable alternative.

At this point it's more about understanding what the firmware is doing for "Relaxed" and "Strict" - I can clearly see the firewall rules being created for "Exclusive", and "Disabled" is pretty straightforward. But I can't work out what is changing when I switch between Relaxed and Strict. I'll dig into more later when I have a bit more time. I don't like it when I don't understand how something works. :)
 
But I can't work out what is changing when I switch between Relaxed and Strict.

The change are just at the dnsmasq level, where strict-order is added to the dnsmasq config while in Strict mode in addition to the DNS. Relaxed simply has all DNS present in dnsmasq, with no particular instruction added.
 
The change are just at the dnsmasq level, where strict-order is added to the dnsmasq config while in Strict mode in addition to the DNS. Relaxed simply has all DNS present in dnsmasq, with no particular instruction added.

Thanks - that makes sense, and I was looking for that, but I still had "strict-order" in /tmp/etc/dnsmasq.conf even after I changed the VPN DNS setting from Strict to Relaxed, which threw me. However I've just checked again and if I restart dnsmasq after making the change, it's gone.

Not sure what the expected behaviour is, but if I change from Relaxed to Strict, then strict-order is added back to /tmp/etc/dnsmasq.conf without needing to restart dnsmasq manually. If I go from Strict to Relaxed I have to manually restart dnsmasq to see the changes.

(I've spent 10 mins trying to work out why the forum blocks the syslog snippets I was trying to post. I'll upload them to pastebin instead.)

Syslog from changing Strict to Relaxed: https://pastebin.com/VFppJtse
Syslog from changing Relaxed to Strict: https://pastebin.com/twwPy9g1

Not sure if I am reading this correctly, but it seems as if dnsmasq is restarted on Relaxed -> Strict which causes /tmp/etc/dnsmasq.conf to be updated. On Strict -> Relaxed dnsmasq is not restarted and /tmp/etc/dnsmasq.conf is not updated.

Is that a correct interpretation?

Does anyone else see this or should I factory reset and test again?
 
Last edited:
That's possible, I'd have to dive into that portion of the code, as it's fairly complex, and I don't remember the details.
 
Thanks (again). The other thing is that with strict-order, dnsmasq seems to be reading the server list in bottom-up order. I remembered this from last year and found this post: https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg11692.html
I'm not sure if the info in that post is still current, but if I move the VPN DNS servers to the bottom of /tmp/resolv.dnsmasq and restart dnsmasq, then clients routed via the Policy Rules all clients start using the VPN DNS, so I thought it was worth mentioning.
 
Last edited:
Thanks (again). The other thing is that with strict-order, dnsmasq seems to be reading the server list in bottom-up order. I remembered this from last year and found this post: https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg11692.html
I'm not sure if the info in that post is still current, but if I move the VPN DNS servers to the bottom of /tmp/resolv.dnsmasq and restart dnsmasq, then clients routed via the Policy Rules all clients start using the VPN DNS, so I thought it was worth mentioning.

Definitely worth investigating. Personally I disagree with Simon's explanation as to why he does not consider this a bug (or otherwise what's the point of a strict order if that order can unpredictably be top-down or down-top). Handling this at the config generation time might be tricky depending on whether the VPN servers are appended to the config, or are included at the initial config generation.

Personally, I always recommend people stick to Enforced however, because it's the only way to ensure that VPN clients will always use the VPN servers, and everyone else will stick to the WAN-defined servers.
 
If I'm understanding everything correctly then Relaxed and Strict apply to all dnsmasq clients, not just those using the tunnel (because to do otherwise would require dnsmasq to be able to use different resolvers based on the client address).

This is probably not what I want. The longer I consider it, the more the only sensible choices seem to be either Exclusive, or else if I really want to use dnsmasq, then Disabled with DOH/DOT and a no-log resolver such as Cloudflare. Which is pretty much what everyone has been saying already, it's just that now I more fully understand why. :)

However this started off for me as a mission to understand better how a small subset of the Asuswrt-Merlin functionality was working - and then some head-scratching when it wasn't doing as expected. At least now I've learnt a bit more about the ovpn scripts, about iptables, and also about dnsmasq. I really appreciate everyone's time in this thread, and apologies one last time to @hs222 for the hijack.

Re-sorting the DNS servers into the "correct" order looks to be a bit of a nightmare, based on what you're saying about when the VPN servers could potentially be added. While I can understand the logic behind Simon's argument, that lines in a config file can be in any order, therefore no promises as to which order the server= lines are used... it just makes 'strict-order' much less useful. You would at least expect servers loaded from a file through servers-file= to be treated in a consistent way, and for that way to be top-down.

Although a bit of further reading here (assuming it's still relevant) goes some way to helping me understand why a lot of people have always advised not to use strict-order at all. Which brings me full circle to choosing between Exclusive or Disabled + Stubby for my VPN clients. :cool:
 
Last edited:

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