send DNS requests trough OpenVPN Tunnel

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
sozeee
DD-WRT Novice


Joined: 15 Jan 2017
Posts: 1

PostPosted: Sun Jan 15, 2017 15:43    Post subject: send DNS requests trough OpenVPN Tunnel Reply with quote
Hello everybody!

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!
Sponsor
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 5993

PostPosted: Sun Jan 15, 2017 19:28    Post subject: Reply with quote
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.

Code:
cat /tmp/resolv.dnsmasq


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=###.###.###.###).

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

Code:
traceroute -n ###.###.###.###


Granted, a bit tedious, but these steps actually reflect what's happening.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 700
Location: Netherlands

PostPosted: Mon Jan 16, 2017 13:22    Post subject: Reply with quote
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 209.222.18.222 dhcp-option DNS 209.222.18.218 ping 10 comp-lzo no route 10.53.10.1 topology net30 ifconfig 10.53.10.6 10.53.10.5'

My resolv.dnsmasq:
nameserver 209.222.18.222
nameserver 209.222.18.218
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 10.0.0.1

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.

Settings
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

What am I doing wrong?

_________________
Router Netgear R6400, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide see Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 5993

PostPosted: Mon Jan 16, 2017 16:36    Post subject: Reply with quote
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 8.8.8.8 rather than 192.168.1.1.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 5993

PostPosted: Mon Jan 16, 2017 16:47    Post subject: Reply with quote
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.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 700
Location: Netherlands

PostPosted: Mon Jan 16, 2017 17:33    Post subject: Reply with quote
Thank you very much, I will look into it and do some more testing, and report back if I know more.
It is not a problem because my IP address is hidden, and if I add the PIA DNSservers to my Static DNS on the Setup tab, the DNS servers of PIA are used.

_________________
Router Netgear R6400, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide see Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 700
Location: Netherlands

PostPosted: Tue Jan 17, 2017 15:22    Post subject: Reply with quote
@eibgrad, I have investigated somewhat further.
As stated my resolv.dnsmasq.conf:
root@R6400:~# cat /tmp/resolv.dnsmasq
nameserver 209.222.18.222
nameserver 209.222.18.218
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 10.0.0.0

When using ipleak.net and dnsleaktest.com my DNSservers are listed as google so coming from 8.8.8.8

With: cat /proc/net/ip_conntrack | grep 'dport=53'
udp 17 27 src=192.168.1.99 dst=192.168.1.1 sport=64033 dport=53 packets=2 bytes=154 src=192.168.1.1 dst=192.168.1.99 sport=53 dport=64033 packets=1 bytes=192 mark=0 use=2
udp 17 27 src=10.26.10.6 dst=8.8.8.8 sport=26834 dport=53 packets=1 bytes=77 src=8.8.8.8 dst=10.26.10.6 sport=53 dport=26834 packets=1 bytes=192 mark=0 use=2
udp 17 105 src=192.168.1.101 dst=192.168.1.1 sport=52699 dport=53 packets=1 bytes=80 src=192.168.1.1 dst=192.168.1.101 sport=53 dport=52699 packets=1 bytes=185 mark=0 use=2
udp 17 27 src=10.26.10.6 dst=8.8.4.4 sport=26834 dport=53 packets=1 bytes=77 src=8.8.4.4 dst=10.26.10.6 sport=53 dport=26834 packets=1 bytes=192 mark=0 use=2
udp 17 105 src=10.26.10.6 dst=8.8.8.8 sport=14912 dport=53 packets=1 bytes=80 src=8.8.8.8 dst=10.26.10.6 sport=53 dport=14912 packets=1 bytes=185 mark=0 use=2

root@R6400:~# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.Cool, 30 hops max, 38 byte packets
1 10.26.10.1 47.973 ms 47.501 ms 47.940 ms
2 93.114.43.193 531.769 ms 239.497 ms 99.327 ms
3 109.163.235.153 55.308 ms 48.973 ms 56.528 ms
4 109.163.235.130 119.707 ms 87.292 ms 77.351 ms
5 * * 5.254.68.146 209.919 ms
6 80.81.193.108 81.499 ms 81.661 ms 81.967 ms
7 216.239.49.128 76.174 ms 216.239.56.26 81.603 ms 216.239.56.110 76.301 ms
8 216.239.57.147 78.385 ms 216.239.57.145 75.850 ms 216.239.57.127 76.001 ms
9 66.249.95.226 94.057 ms 93.998 ms 64.233.174.143 90.991 ms
10 209.85.246.119 91.367 ms 88.641 ms 209.85.249.12 92.064 ms
11 * * *
12 * 8.8.8.8 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 Sad

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.

I redid your commands:
root@R6400:~# cat /proc/net/ip_conntrack | grep 'dport=53'
udp 17 2 src=10.26.10.6 dst=209.222.18.218 sport=20856 dport=53 packets=1 bytes=61 src=209.222.18.218 dst=10.26.10.6 sport=53 dport=20856 packets=1 bytes=317 mark=0 use=2
udp 17 32 src=192.168.1.99 dst=192.168.1.1 sport=63156 dport=53 packets=2 bytes=118 src=192.168.1.1 dst=192.168.1.99 sport=53 dport=63156 packets=1 bytes=92 mark=0 use=2
udp 17 21 src=10.26.10.6 dst=209.222.18.218 sport=63031 dport=53 packets=1 bytes=58 src=209.222.18.218 dst=10.26.10.6 sport=53 dport=63031 packets=1 bytes=74 mark=0 use=2
udp 17 3 src=10.26.10.6 dst=209.222.18.222 sport=21477 dport=53 packets=1 bytes=70 src=209.222.18.222 dst=10.26.10.6 sport=53 dport=21477 packets=1 bytes=130 mark=0 use=2
udp 17 21 src=192.168.1.99 dst=192.168.1.1 sport=62878 dport=53 packets=1 bytes=58 src=192.168.1.1 dst=192.168.1.99 sport=53 dport=62878 packets=1 bytes=74 mark=0 use=2
udp 17 17 src=192.168.1.99 dst=192.168.1.1 sport=53693 dport=53 packets=2 bytes=132 src=192.168.1.1 dst=192.168.1.99 sport=53 dport=53693 packets=1 bytes=172 mark=0 use=2
udp 17 30 src=10.26.10.6 dst=209.222.18.222 sport=26222 dport=53 packets=1 bytes=60 src=209.222.18.222 dst=10.26.10.6 sport=53 dport=26222 packets=1 bytes=60 mark=0 use=2
udp 17 20 src=192.168.1.99 dst=192.168.1.1 sport=63751 dport=53 packets=2 bytes=154 src=192.168.1.1 dst=192.168.1.99 sport=53 dport=63751 packets=1 bytes=93 mark=0 use=2
udp 17 26 src=10.26.10.6 dst=209.222.18.218 sport=3170 dport=53 packets=1 bytes=64 src=209.222.18.218 dst=10.26.10.6 sport=53 dport=3170 packets=1 bytes=64 mark=0 use=2
udp 17 33 src=192.168.1.99 dst=192.168.1.1 sport=56989 dport=53 packets=1 bytes=58 src=192.168.1.1 dst=192.168.1.99 sport=53 dport=56989 packets=1 bytes=58 mark=0 use=2
udp 17 30 src=192.168.1.99 dst=192.168.1.1 sport=65029 dport=53 packets=2 bytes=120 src=192.168.1.1 dst=192.168.1.99 sport=53 dport=65029 packets=1 bytes=60 mark=0 use=2

There are much more but I only showed about 20%

root@R6400:~# traceroute -n 209.222.18.222
traceroute to 209.222.18.222 (209.222.18.222), 30 hops max, 38 byte packets
1 10.26.10.1 47.277 ms 49.820 ms 55.928 ms
2 * * *
3 109.163.235.61 47.949 ms 50.662 ms 48.774 ms
4 62.115.147.6 48.105 ms 46.910 ms 47.835 ms
5 62.115.119.118 70.494 ms 80.91.248.15 73.086 ms 62.115.143.170 69.943 ms
6 62.115.136.62 82.192 ms 213.155.133.56 77.521 ms 62.115.134.216 85.494 ms
7 213.155.135.63 169.163 ms 62.115.116.160 84.581 ms 80.91.250.203 168.142 ms
8 62.115.134.108 168.400 ms 213.155.130.28 164.305 ms 62.115.141.238 170.200 ms
9 62.115.123.77 88.615 ms 62.115.123.85 86.542 ms 62.115.149.39 167.472 ms
10 66.55.144.146 168.482 ms 66.55.144.149 169.875 ms 66.55.144.146 161.635 ms
11 108.61.248.78 165.518 ms 80.91.247.121 177.393 ms 62.115.118.192 170.098 ms
12 62.115.112.107 166.877 ms 213.155.130.30 173.375 ms 209.222.18.222 164.657 ms

Is it possible that the DNSMasq is not getting a SIGHUP after the OpenVPNclient has altered the resolv.dnsmasq.conf?
(My linux knowledge is below average so maybe it is something entirely different Smile

_________________
Router Netgear R6400, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide see Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 5993

PostPosted: Tue Jan 17, 2017 17:40    Post subject: Reply with quote
There is no such file called resolv.dnsmasq.conf.

The DNSMasq config file is /tmp/dnsmasq.conf.

Code:
interface=br0
resolv-file=/tmp/resolv.dnsmasq
all-servers
strict-order
domain=hiphippo
dhcp-leasefile=/tmp/dnsmasq.leases
...


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.

Code:
nameserver 209.18.47.62
nameserver 209.18.47.61


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:

Code:
nameserver 10.13.0.1
nameserver 209.18.47.62
nameserver 209.18.47.61


A new file called /tmp/resolv.dnsmasq_isp is created to retain/remember the original contents of the resolv file.

Code:
nameserver 209.18.47.62
nameserver 209.18.47.61


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.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 700
Location: Netherlands

PostPosted: Tue Jan 17, 2017 18:38    Post subject: Reply with quote
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.

I will look further into the matter and report back if I know more.
Your help is greatly appreciated

_________________
Router Netgear R6400, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide see Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 700
Location: Netherlands

PostPosted: Wed Jan 18, 2017 12:45    Post subject: Reply with quote
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.

When it was not working, I could easily get it to work by executing: touch resolv.dnsmasq from the CLI, to give this file a later timestamp than dnsmasq.conf

_________________
Router Netgear R6400, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide see Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 5993

PostPosted: Wed Jan 18, 2017 15:06    Post subject: Reply with quote
Not really sure what's going on at the moment, but I dumped my own /tmp directory and saw something interesting (I edited the output for clarity sake).

Code:
Me:
-rw-r--r--    1 root     root           491 Tue Jan 17 23:46:40 2017 dnsmasq.conf
drwx------    2 root     root             0 Tue Jan 17 23:46:40 2017 openvpncl
-rw-r--r--    1 root     root            39 Tue Jan 17 23:46:40 2017 resolv.conf
-rw-r--r--    1 root     root            42 Tue Jan 17 23:46:47 2017 resolv.dnsmasq
-rw-r--r--    1 root     root            21 Tue Jan 17 23:46:47 2017 resolv.dnsmasq_isp

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.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 700
Location: Netherlands

PostPosted: Wed Jan 18, 2017 16:17    Post subject: Reply with quote
I totally agree, it could point to a nasty bug.

My setup is really standard, Netgear R6400 with the latest Kong build 31135, which has the new 2.4 OpenVPN.
No additional DNSMasq options only 1 static lease, no scripts or rules.

I will make a script to touch the resolv.dnsmasq. A nice exercise, I have programming and Windows scripting skills but not Linux Smile

In the meantime, if I can be of further assistance let me know, I am on a sabbatical so I have plenty of time on my hands Smile

_________________
Router Netgear R6400, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide see Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 5993

PostPosted: Wed Jan 18, 2017 16:52    Post subject: Reply with quote
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.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 700
Location: Netherlands

PostPosted: Wed Jan 18, 2017 18:21    Post subject: Reply with quote
Yes this Broadcom /Arm on Linux 4.4. with Open VPN2.4.

I looked in the /tmp/opnvpncl directory here is the listing:
-rw-r--r-- 1 root root 2025 Wed Jan 18 17:33:09 2017 ca.crt
-rw-r--r-- 1 root root 22 Wed Jan 18 17:33:09 2017 credentials
-rw-r--r-- 1 root root 447 Wed Jan 18 17:33:09 2017 openvpn.conf
-rwx------ 1 root root 99 Wed Jan 18 17:33:09 2017 route-down.sh
-rwx------ 1 root root 574 Wed Jan 18 17:33:09 2017 route-up.sh

The most ineresting seems the route-up.sh:
#!/bin/sh
iptables -D POSTROUTING -t nat -o tun1 -j MASQUERADE
iptables -I POSTROUTING -t nat -o tun1 -j MASQUERADE
iptables -D INPUT -i tun1 -j ACCEPT
iptables -D FORWARD -i tun1 -j ACCEPT
iptables -D FORWARD -o tun1 -j ACCEPT
iptables -I INPUT -i tun1 -j ACCEPT
iptables -I FORWARD -i tun1 -j ACCEPT
iptables -I FORWARD -o tun1 -j ACCEPT
stopservice dnsmasq -f
startservice dnsmasq -f
cat /tmp/resolv.dnsmasq > /tmp/resolv.dnsmasq_isp
env | grep 'dhcp-option DNS' | awk '{ print "nameserver " $3 }' > /tmp/resolv.dnsmasq
cat /tmp/resolv.dnsmasq_isp >> /tmp/resolv.dnsmasq

As I said my Linux knowledge is below average, so I can not comment on it, pherhaps I should add: Sleep 5 after startservice dnsmasq -f ? (don't know what the -f option means)

It's fun and very instructive Smile

_________________
Router Netgear R6400, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide see Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 5993

PostPosted: Wed Jan 18, 2017 18:27    Post subject: Reply with quote
There it is!!!

stopservice dnsmasq -f
startservice dnsmasq -f

That's the restart. My script does NOT have the restart.

Code:
#!/bin/sh
iptables -D POSTROUTING -t nat -o tun1 -j MASQUERADE
iptables -I POSTROUTING -t nat -o tun1 -j MASQUERADE
iptables -D INPUT -i tun1 -j ACCEPT
iptables -I INPUT -i tun1 -j ACCEPT
cat /tmp/resolv.dnsmasq > /tmp/resolv.dnsmasq_isp
env | grep 'dhcp-option DNS' | awk '{ print "nameserver " $3 }' > /tmp/resolv.dnsmasq
cat /tmp/resolv.dnsmasq_isp >> /tmp/resolv.dnsmasq


That makes this a bug.

And that's how bugs often get in. Developers don't always realize the implications of what appears to be an inconsequential change.
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum