When DNSMasq is restarted, that kicks off immediately as a background process and the script continues on. DNSMasq then reads the resolv.dnsmasq file, but sometimes that occurs before resolv.dnsmasq has been updated w/ the DNS servers of the VPN. And even though resolv.dnsmasq is eventually updated, the startup process of DNSMasq has not yet finished, so it misses the fact that resolv.dnsmasq just changed in that split second. What Kong should have done is updated resolv.dnsmasq first, then restarted DNSMasq. Or perhaps not restart DNSMasq at all. It's not obvious to me why he added it.
Joined: 18 Mar 2014 Posts: 4315 Location: Netherlands
Posted: Wed Jan 18, 2017 18:58 Post subject:
Great!
Of course my suggestion (putting in sleep) was nonsense, I knew that the minute after I uploaded my message, these files are of course not persistent
Joined: 18 Mar 2014 Posts: 4315 Location: Netherlands
Posted: Fri Jan 20, 2017 13:59 Post subject:
Good Job!
I cobbled a script together which can be saved as startup script from the Administration commands tab, which "touches" the file to give it a later timestamp so that DNSMasq rereads the file and uses the pushed DNS servers. I did not test extensively so check!
Code:
#!/bin/sh
file="/tmp/resolv.dnsmasq"
Number=0
logger "File attempting to touch: $file"
logger "Starting number $Number of 10 attempts"
if [ ! -f "$file" ]; then
until [ ! -f "$file" ]; do
sleep 2
Number=$((Number+1))
logger "Wating for $Number"
if [ -f "$file" ]; then
touch "$file"
logger "$file has been touched"
break
elif [ $Number -eq 10 ]; then
logger "Can not execute touch, Beware of DNS Leak"
break
fi
done
elif [ -f "$file" ]; then
sleep 2
touch "$file"
logger "$file has been touched"
else
logger "Can not execute touch, Beware of DNS Leak"
fi
In my case, I look for the creation of the backup resolv file (resolv.dnsmasq_isp) to signal the change, wait a few seconds, then touch resolv.dnsmasq.
Note, there's not much point in using echo to send messages since there is no console. That's why I send all output to the syslog. Makes it easier to debug as well.
I also turned it into an infinite loop so in case the VPN was stopped (i.e., disabled) and started again (i.e., enabled), it would fix the DNS leak again. However, that part of it isn't working (at least on my build) since doing a disable/enable doesn't create the resolv.dnsmsq_isp file. Either the VPN is not shutting down properly, or is otherwise getting confused when started again. Whatever the reason, it *should* be working correctly, and not like this.
I have to say, it's stuff like this and the DNS leak that make me less than happy w/ the OpenVPN implementation in dd-wrt. We shouldn't have to reboot.
Anyway, I guess given how the restart process doesn't work, my script could be simplified even further. But I left the infinite loop in place just in case some other dd-wrt build restarts correctly.
I seem to have a much more basic problem with getting my DNS queries routed through the VPN. Short story: the pushed PIA DNS servers don't seem to replace the static ones even though OpenVPN connects correctly and "Use DNSMasq for DNS" is checked.
Details:
I have PIA and set up my dd-wrt router (a Netgear WNDR3700 v4 with the DD-WRT v3.0-r31722 std (03/21/17) firmware) to route all traffic through the VPN.
Whether you're experiencing the same or different problem is hard to say. But let's put that aside for the moment.
IMO, I don't think it's important whether you use the VPN's DNS servers, as much as you DON'T use the ISP's DNS servers. Because it's the use of the ISP's DNS servers that defines a DNS leak. And I would go farther and not even allow the ISP to snoop on your DNS queries (or worse, manipulate them) by routing them over the VPN.
So w/ that in mind, why not just route those *non* ISP DNS servers over the VPN by adding them to the Additional Config field?
Code:
route 4.2.2.1
route 4.2.2.2
route 4.2.2.3
So now, whenever the VPN is down, those DNS servers are accessed over the WAN. But when the VPN comes up, they're routed over the VPN.
IOW, who cares about the VPN provider's DNS servers? The only reason I can imagine wanting to use them is under the assumption they might respond faster (which makes sense). But beyond that, they aren't really necessary since they don't provide any particular advantage. All we're really interested in is just making sure we get the ISP out of the loop wrt DNS.
Now one caution is in order here. If you use the policy based routing field of the GUI, this technique won't work. And that's because when you use that field, the router adds the route-noexec directive to the OpenVPN client config (that's what stops the gateway from being changed to the VPN). But a side effect of that directive is that now the OpenVPN client is responsible for handling any routes defined in Additional Config. But the router has a bug in this regard. It doesn't handle them. It ignores them! IOW, your routes won't get bound to the VPN whenever policy based routing is enabled in the GUI. So just keep that in mind.
thanks for that quick and substantial response. I was wondering about policy-based routing myself, thanks for anticipating that question and answering it as well.
Not sure if I sould start a new topic but this one looks like most relevant for me.
I have set up routed OpenVPN client (tun) on DD-WRT 3.0-r39715 to connect local LAN to remote LAN.
Everything is working fine with only exception that pushed remote DNS by OpenVPN server is not updating Dnsmasq resolv.
GUI settings
Setup->Basic [ Network Address Server Settings (DHCP) ]
Code:
Use DNSMasq for DNS - checked
DHCP-Authoritative - checked
Forced DNS Redirection - unchecked
Services->Services [ Dnsmasq ]
Code:
Dnsmasq - Enable
Cache DNSSEC data - Disable
Local DNS - Enable
No DNS Rebind - Enable
Query DNS in Strict Order - Enable
Add Requestor MAC to DNS Query - Disable
RFC4039 Rapid Commit support - Disable
Maximum Cached Entries - 1500
Additional Dnsmasq Options - blank
Generated dnsmasq.conf
Code:
less /tmp/dnsmasq.conf
interface=br0
resolv-file=/tmp/resolv.dnsmasq
strict-order
domain=local.net
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-lease-max=50
dhcp-option=br0,3,192.168.7.250 //LAN IP address of dd wrt router
dhcp-range=br0,192.168.7.129,192.168.7.178,255.255.255.128,1440m
bogus-priv
conf-file=/etc/rfc6761.conf
dhcp-option=252,"\n"
cache-size=1500
dd wrt OpenVPN client receives remote DNS address along with static routes:
Code:
May 4 12:27:58 gate daemon.notice openvpn[7589]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.3.201,route 10.0.0.0 255.255.0.0,route 192.168.3.0 255.255.255.0
However /tmp/resolv.dnsmasq remains unchanged - only my ISP's DNS adresses there:
Not sure if I sould start a new topic but this one looks like most relevant for me.
I have set up routed OpenVPN client (tun) on DD-WRT 3.0-r39715 to connect local LAN to remote LAN.
Everything is working fine with only exception that pushed remote DNS by OpenVPN server is not updating Dnsmasq resolv.
GUI settings
Setup->Basic [ Network Address Server Settings (DHCP) ]
Code:
Use DNSMasq for DNS - checked
DHCP-Authoritative - checked
Forced DNS Redirection - unchecked
Services->Services [ Dnsmasq ]
Code:
Dnsmasq - Enable
Cache DNSSEC data - Disable
Local DNS - Enable
No DNS Rebind - Enable
Query DNS in Strict Order - Enable
Add Requestor MAC to DNS Query - Disable
RFC4039 Rapid Commit support - Disable
Maximum Cached Entries - 1500
Additional Dnsmasq Options - blank
Generated dnsmasq.conf
Code:
less /tmp/dnsmasq.conf
interface=br0
resolv-file=/tmp/resolv.dnsmasq
strict-order
domain=local.net
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-lease-max=50
dhcp-option=br0,3,192.168.7.250 //LAN IP address of dd wrt router
dhcp-range=br0,192.168.7.129,192.168.7.178,255.255.255.128,1440m
bogus-priv
conf-file=/etc/rfc6761.conf
dhcp-option=252,"\n"
cache-size=1500
dd wrt OpenVPN client receives remote DNS address along with static routes:
Code:
May 4 12:27:58 gate daemon.notice openvpn[7589]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.3.201,route 10.0.0.0 255.255.0.0,route 192.168.3.0 255.255.255.0
However /tmp/resolv.dnsmasq remains unchanged - only my ISP's DNS adresses there:
In the future, please, *always* start a new thread. Posting to someone else's thread often causes confusion. In our haste to support users on many other threads (and even other forums), we often assume it's the OP and miss the fact it's someone else posting w/ their own problems. Pretty soon things get confusing, esp. if others follow suit, or the OP chimes back in. If you find one or more existing threads that seem relevant to your problem, just provides links in your new thread.
As far as your stated problem, be aware that only Kong builds update DNSMasq w/ the pushed DNS servers. If using BS (Brainslayer) builds, he completely ignores them!
Yeah, I know, not very consistent. And not obvious unless you happen to examine the underlying route-up scripts used by each developer. They differ in this one particular area. Don't ask me why. I have no clue.
If using a BS build, I recommend adding the following to the Additional DNSMasq Options field on the Services page.
Code:
no-resolv
server=8.8.8.8
server=8.8.4.4
What this does is tell DNSMasq to ignore all other public DNS servers and just use the ones named herein w/ the server directive(s). This prevents DNS leaks!
Of course, that's not going to help in the case of a *private* DNS server pushed from your own OpenVPN server. In that case, I would instead include the private IP of your remote DNS server for that remote domain. IOW, if the domain across the tunnel is xyz.local, then the DNSMasq configuration of the OpenVPN client would look like the following.
Code:
server=/xyz.local/192.168.3.201
You could even combine the two so that you never had DNS leaks for public IPs *and* be able to use the remote DNS server when necessary.
In the future, please, *always* start a new thread.
OK. Noted.
eibgrad wrote:
You could even combine the two so that you never had DNS leaks for public IPs *and* be able to use the remote DNS server when necessary.
I think I will switch this one to Kong's build as this solution is not elegant enough. Having a bunch of remote domains and keeping them "hardcoded" in additional options is a bit inconvenient and hard to administer.
)