Posted: Sun Jan 15, 2017 15:43 Post subject: send DNS requests trough OpenVPN Tunnel
I am probably asking a very simple question to many, but after long searching the forums still can't find the answer.
I am proudly running DD-WRT v3.0-r30910M kongac (12/02/16) on my Netgear R7000 for about a week, first time user with no networking background.
So far everything runs smoothly out of the box, I haven't done any extra configuration.
So here is the problem, when running the OpenVPN client the DNS requests get handled by whatever server I have put in the 'basic setup > network setup' page of the GUI. If I type zeroes in, the requests go to my ISP's DNS. So I guess this all goes outside the VPN tunnel. When I use the VPN provider's Windows client it works similarly and when I set some extra options for preventing DNS leaks, it starts sending requests to OpenDNS servers set by the provider (which I cannot choose), ignoring my system settings in Windows and in the router. So the question is how do I configure it so that all traffic, including DNS requests, go through the VPN tunnel. The second one, how do I see where it goes through?
Thanks to all the people keeping this project what it is!
We need to make it clear how DNS actually works on dd-wrt.
By default, dd-wrt uses its own DNS server called DNSMasq for LAN clients (under Setup->DHCP server, you'll find "Use DNSMasq for DNS" checked). So every LAN client will receive the router's LAN ip as its DNS server (you can verify this on Windows using the command, ipconfig /all).
When the WAN is started, the ISP's DNS servers are detected, added to the DNSMasq config, and DNSMasq is restarted. As a result any LAN client that sends its DNS requests to DNSMasq will have them relayed to the ISP's DNS servers.
That's the normal, expected behavior, prior to using OpenVPN.
Once the OpenVPN client is started, any DNS servers offered by OpenVPN, either because the OpenVPN server pushed them, or you added them to the OpenVPN client in Additional Config, are detected, DNSMasq is updated to point to those servers rather than the ISP, and DNSMasq restarted. Thus, all your LAN clients end up using the OpenVPN DNS servers.
All this works *provided* your LAN clients are actually using the DNS server of the router. But suppose you uncheck "Use DNSMasq for DNS"? Now the DNS servers of the WAN/ISP will be passed directly to your LAN clients. IOW, if you dump the IP config of your LAN clients, they will NOT have the router as their DNS server anymore. And so all the work done by DNSMasq to prevent DNS leaks has no effect. You're not using DNSMasq!
The moral of the story is, always use DNSMasq on the router, esp. if you want to prevent DNS leaks w/ OpenVPN. I've seen more than a few ppl uncheck "Use DNSMasq for DNS" on the Setup page without realizing the implications to OpenVPN.
As far as verifying which DNS servers are being used...
In most cases, as long as you're using DNSMasq, it's not possible to use anything but the OpenVPN DNS servers because those servers are only available over the VPN; they reside on the VPN provider's local network.
But if you want to be 100% sure which DNS servers are being used, you could dump the DNS servers currently in use.
Then use the connection tracking system to locate port 53 (DNS) packets (probably UDP) leaving the router and determine the DNS server being queried (dst=###.###.###.###).
cat /proc/net/ip_conntrack | grep 'dport=53 '
Finally, use traceroute to see what path the routing system is using for that same destination IP.
traceroute -n ###.###.###.###
Granted, a bit tedious, but these steps actually reflect what's happening.
Joined: 18 Mar 2014 Posts: 4387 Location: Netherlands
Posted: Mon Jan 16, 2017 13:22 Post subject:
That is a great explanation, very instructive, thank you!
I have set up my openVPNclient on PIA which works well
I can see that it is pushing DNS servers:
20170116 13:31:50 SENT CONTROL [06425c9dfd4606f82b5adc8217d63008]: 'PUSH_REQUEST' (status=1)
20170116 13:31:50 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 dhcp-option DNS 184.108.40.206 dhcp-option DNS 220.127.116.11 ping 10 comp-lzo no route 10.53.10.1 topology net30 ifconfig 10.53.10.6 10.53.10.5'
So that seems OK, BUT if I use ipleak.net, I can see that I am on my VPN, but my DNS server is listed as google so apparently the two pushed DNS servers, which are on the top of my resolv.dnsmasq, are not used. The last three entries of my resolv.dnsmasq are my entries under DHCP server.
Use DNSMasq for DHCP : Check
Use DNSMasq for DNS : Check
DHCP-Authoritative : Check
Forced DNS Redirection: Not
DNSMasq : Enable
Encrypt DNS : Disable
Local DNS : Enable
No DNS Rebind : Enable
Query DNS in Strict Order : Enable
Add Requestor MAC to DNS Query : Disable
I am on the latest Kong build 31135 (with openVPN 2.4)on a Netgear R6400
While I have used ipleak.net in the past, I've found it gives confusing and inconsistent results. Not sure why. I believe it's based on the WebRTC toolkit, which is built into most popular browsers. And I presume that explains its ability to detect DNS servers. It probably has some low-level access to the network stack. But from the end-user perspective, it's really a black box. I don't know precisely how it works. And I never trust things that I can't explain (and which is why you're here asking me these same questions).
Let's remember, in the case of the router, we want (and expect) each LAN client to be using the router's DNS server (DNSMasq). That *local* DNS server is only acting as a *relay* to the actual, public DNS servers configured in DNSMasq. So how in the world could your browser (WebRTC) know which public DNS servers your local DNS server was using at any given time? Seems to me the only DNS server that ipleak.net could actually detect is 192.168.1.1 (assuming that's your router's LAN ip).
Case and point, when I run ipleak.net and I'm NOT connected to a VPN, it does NOT return the DNS servers of my ISP. Instead, it returns a list of 12 DNS servers I've never heard of! But that kind of makes sense given what I described above. However, it doesn't explain why it generated that particularly odd list of DNS servers.
This is why I don't trust ipleak.net and other similar services in all cases. It's my assumption that such tools are assuming the LAN client is configured w/ public DNS servers, and NOT some local DNS server that's masking your actual, public DNS servers.
That's why I wanted you to verify the DNS servers being used by checking the results of connection tracking on destination port 53 (DNS). IMO, that's more likely to give us the correct picture.
Now I suppose it's possible that for some unknown reason your LAN client is NOT using the router as its DNS server, despite everything in the router config suggesting it should. You need to check if perhap your LAN client was assigned 18.104.22.168 rather than 192.168.1.1.
P.S. As I look more closely at the DNS servers listed by ipleak.net, it's clear that it can't detect my public DNS server(s), and has instead discovered that my public IP belongs to Time Warner, then dumped all the DNS servers it knows about for Time Warner in my particular location/region. Not exactly useful information, and definitely misleading.
I don't happen to have an OpenVPN client available at the moment or else I'd test that as well. But I suspect it would behave similarly, detecting the public IP, then dumping all the DNS servers it knows about for that IP in the VPN provider's location/region.
root@R6400:~# traceroute -n 22.214.171.124
traceroute to 126.96.36.199 (8.8.8., 30 hops max, 38 byte packets
1 10.26.10.1 47.973 ms 47.501 ms 47.940 ms
2 188.8.131.52 531.769 ms 239.497 ms 99.327 ms
3 184.108.40.206 55.308 ms 48.973 ms 56.528 ms
4 220.127.116.11 119.707 ms 87.292 ms 77.351 ms
5 * * 18.104.22.168 209.919 ms
6 22.214.171.124 81.499 ms 81.661 ms 81.967 ms
7 126.96.36.199 76.174 ms 188.8.131.52 81.603 ms 184.108.40.206 76.301 ms
8 220.127.116.11 78.385 ms 18.104.22.168 75.850 ms 22.214.171.124 76.001 ms
9 126.96.36.199 94.057 ms 93.998 ms 188.8.131.52 90.991 ms
10 184.108.40.206 91.367 ms 88.641 ms 220.127.116.11 92.064 ms
11 * * *
12 * 18.104.22.168 92.487 ms 90.478 ms
My take (for what it's worth) is that the resolv.dnsmasq.conf is not used.
So I tried to stop and start DNSMasq, what that did is it altered the resolv.dnsmas.conf file in such a way that the entries from the OpenVPN were gone, not surprisingly, after starting and stoping the OpenVPN the entries were back but still no go
Then I decided to open and save but not alter the resolv.dnsmasq.conf and BINGO now with dnsleaktest and ipleak.net my vpn IP address is listed as my DNS server.
root@R6400:~# traceroute -n 22.214.171.124
traceroute to 126.96.36.199 (188.8.131.52), 30 hops max, 38 byte packets
1 10.26.10.1 47.277 ms 49.820 ms 55.928 ms
2 * * *
3 184.108.40.206 47.949 ms 50.662 ms 48.774 ms
4 220.127.116.11 48.105 ms 46.910 ms 47.835 ms
5 18.104.22.168 70.494 ms 22.214.171.124 73.086 ms 126.96.36.199 69.943 ms
6 188.8.131.52 82.192 ms 184.108.40.206 77.521 ms 220.127.116.11 85.494 ms
7 18.104.22.168 169.163 ms 22.214.171.124 84.581 ms 126.96.36.199 168.142 ms
8 188.8.131.52 168.400 ms 184.108.40.206 164.305 ms 220.127.116.11 170.200 ms
9 18.104.22.168 88.615 ms 22.214.171.124 86.542 ms 126.96.36.199 167.472 ms
10 188.8.131.52 168.482 ms 184.108.40.206 169.875 ms 220.127.116.11 161.635 ms
11 18.104.22.168 165.518 ms 22.214.171.124 177.393 ms 126.96.36.199 170.098 ms
12 188.8.131.52 166.877 ms 184.108.40.206 173.375 ms 220.127.116.11 164.657 ms
By default, DNSMasq uses /etc/resolv.conf for determining the nameservers, but the DNSMasq config file has been overridden to point to /tmp/resolv.dnsmasq.
All the above is BEFORE my OpenVPN client is started.
I was incorrect in stating that DNSMasq is restarted when the OpenVPN client is started. Turns out that unless the DNSMasq config file contains the directive "no-poll", DNSMasq will check the timestamp of the resolv file (/tmp/resolv.dnsmasq) for a change, and if found, will reread it. No restarts of DNSMasq or SIGHUP required.
If I now start the OpenVPN client, the resolv file contains the original ISP nameservers, preceded by the VPN's DNS servers:
A new file called /tmp/resolv.dnsmasq_isp is created to retain/remember the original contents of the resolv file.
Obviously this is so the change in nameservers can be undone and have DNSMasq returned to normal once the OpenVPN client is stopped/disabled.
Even though the updated resolv file contains both the ISP's nameservers and those of the VPN, because the DNSMasq config file contains the directive "strict-order", it will give priority to the VPN's DNS server(s).
As best I can tell, that's the way it's supposed to work. And when I dump my own connection tracking, I do see the DNS queries switched to the VPN's DNS servers once the OpenVPN client is connected.
Of course, if someone starts messing around w/ DNSMasq settings in the Additional DNSMasq Options field, things might change (adding the no-poll directive, additional server directives, etc.).
That's why I say you have to be careful if you starting messing around w/ DNSMasq. The router is configured to prevent DNS leaks based on some assumptions that might no longer be valid due to those changes.
Btw, I'm not sure what trace routing the DNS servers actually proves. In fact, it adds to the confusion (at least for me) since we're trying to diagnose why those same DNS servers are or are not being used in various situations. All we really want is to force the client to make arbitrary DNS queries (using a browser makes the most sense here) and see what path they follow through connection tracking.
As far as why purposely saving the resolv.dnsmasq field worked, that gets back to my explanation above. Any changes to that file's timestamp causes DNSMasq to reread it. But that should have happened the moment the VPN got connected and the OpenVPN client updated resolv.dnsmasq w/ the VPN's DNS servers. We know it did since you checked visually. And you didn't add the VPN's DNS server manually, you simply forced an additional save, and hence timestamp change.
All this gets me to wondering if there's a timing issue, or perhaps the time wasn't set correctly, etc. Has to be something along those lines. At least w/ my dd-wrt router, I didn't have that problem.
Joined: 18 Mar 2014 Posts: 4387 Location: Netherlands
Posted: Tue Jan 17, 2017 18:38 Post subject:
Thank you very much for your elaborate answer. Not only is your knowledge amazing but your explanation concise and to the point.
The way you described it is the same as for my setup.
After the openVPN is active, the dnsmasq.conf points to the resolv.dnsmasq, which starts with the 2 entries from the VPN and then 3 entries form the DHCP fields.
I do not have anything in my Additional DNSMasq Options and I have: Query DNS in Strict Order, Local DNS and No DNS Rebind all enabled.
So my setup not working could indeed be a timing problem which is solved by opening and saving the resolv.dnsmasq file.
Joined: 18 Mar 2014 Posts: 4387 Location: Netherlands
Posted: Wed Jan 18, 2017 12:45 Post subject:
I did some further investigating and rebooted multiple times, sometimes DNS is using the pushed VPN DNS servers sometimes it didn't.
I include a file with the timestamps of the /tmp directory. When it was not working the timestamps of dnsmasq.conf and resolv.dnsmasq where the same, when it it worked as it should be, resolv.dnsmasq had a timestamp of 1 second later.
You (when not working):
-rw-r--r-- 1 root root 294 Wed Jan 18 13:25:50 2017 dnsmasq.conf
drwx------ 2 root root 0 Wed Jan 18 13:25:43 2017 openvpncl
-rw-r--r-- 1 root root 23 Wed Jan 18 13:25:50 2017 resolv.conf
-rw-r--r-- 1 root root 110 Wed Jan 18 13:25:50 2017 resolv.dnsmasq
-rw-r--r-- 1 root root 58 Wed Jan 18 13:25:50 2017 resolv.dnsmasq_isp
Notice in particular the timestamps of dnsmasq.conf and the openvpncl directory. The former is created at the time DNSMasq is started, while the latter is created at the time the OpenVPN client is just getting started and needs that as a working directory.
In my case, DNSMasq and the OpenVPN client get started at the same time (23:46:40). And the changes to resolve.* occur 7 seconds later (23:46:47), presumably once the OpenVPN client gets connected and executes its script to make the VPN DNS server changes. That's what I would expect. It seems right.
But in your case, all the timestamps wrt DNSMasq are the same (13:25:50), even the creation of dnsmasq.conf, which would only occur when DNSMasq is being started (or restarted). And this timestamp is later than the timestamp on the /tmp/openvpncl directory (13:25:43). It's as if DNSMasq in your case is either getting started after the OpenVPN client, or else being restarted for some reason.
In both cases, the difference is 7 secs, but I'm not sure if that's significant or coincidence.
That seems to be the common theme. For you, all the DNSMasq related files tend to congregate around the same timestamp, and always after the start of the OpenVPN client. If by chance there's a slight delay in updating resolv.dnsmasq, it works, otherwise it doesn't.
So clearly there is something different between our systems that accounts for all this, but I've yet to determine it. You would think that even if the timestamps were close, they wouldn't be down at the millisecond level. I assume DNSMasq would be using the milliseconds part of the timestamp to know when the resolv.dnsmasq file has been updated. But who knows. Maybe it isn't (seems dumb not to).
Anyway, I don't have a complete answer at the moment. And until I can reproduce it here, I can't fully explain it.
In the meantime, I suppose there are ways to deal with it, like running a script to detect the creation of the resolv.dnsmasq_isp file and then touch'ing resolv.dnsmasq. But of course that doesn't fix the underlying problem. And I'd like to find out what exactly is happening here in case it's a bug. I'm particularly concerned because most ppl wouldn't even notice. You can't really tell unless you go to the trouble we did to dump connection tracking and look directly at the port 53 traffic. And add to that it's intermittent.
Well one difference here is I'm using an older Asus RT-N10+ rev D1 router (MIPS, 2.x kernel) w/ Kong build (25630M, 12/13/14), while you're using a much more recent Kong build, and probably 3.x kernel and ARM-based. And very recently Kong added OpenVPN 2.4.
I'm suspicious because there have been known issue w/ OpenVPN 2.4 on the Kong builds as of late (build 30949 immediately comes to mind). And Kong tends to be more of a risk taker in adding or modifying the system. And as such, it wouldn't surprise me if he unwittingly introduced a bug. Heck, for all I know, he decided to change the way things work and restart DNSMasq in his revised route-up script, but without realizing the consequences. There's just a much higher likelihood of a bug w/ Kong than anyone using the older Brainslayer builds on more traditional platforms. And since I don't have access to your router, I'm betting I won't be able to reproduce it.
At the very least, I would poke around down in the /tmp/openvpncl directory, find those scripts, and check it out. At least we can compare yours scripts to mine.