Opened 6 months ago

Closed 3 months ago

#5697 closed (fixed)

OpenVPN client -- intermittent DNS leaks

Reported by: eibgrad Owned by:
Keywords: Cc: egc112

Description

There's a bug in the OpenVPN client that causes intermittent DNS leaks. It was discovered while dealing w/ the following thread.

http://www.dd-wrt.com/phpBB2/viewtopic.php?t=306779

The OpenVPN client uses a route-up script to add the VPN's DNS servers to DNSMasq. On my own (older) dd-wrt router (Asus RT-N10+ rev D1, Firmware Version DD-WRT v24-sp2 (12/13/14) kong - build 25630M), that script is as follows (and works fine):

#!/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

However, the OP of that thread is using a different, more recent router (Netgear R7000, DD-WRT v3.0-r30910M kongac (12/02/16)), and that route-up script has been modified to restart DNSMasq:

#!/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

Frankly, I don't know why a DNSMasq restart was added. Perhaps it was for some other purpose. But it's certainly not necessary for the purposes of updating the active DNS servers. Unless DNSMasq is configured w/ the no-poll directive, it will reread resolv.dnsmasq should its timestamp change. IOW, DNSMasq is always monitoring that file for changes.

By adding the DNSMasq restart, that has introduced an intermittent DNS leak. Because DNSMasq is daemonized, the script continues on. Every once and awhile, resolv.dnsmasq gets updated after DNSMasq has already read the file, and before DNSMasq has fully daemonized. So the fact the timestamp changed in that split second between those two events is missed. And now DNSMasq continues to use the ISP's DNS servers rather than the VPN's DNS servers.

This is a very hard bug to detect. I don't think anyone else even knows about it since it requires monitoring connection tracking to see where port 53 UDP packets are being directed. When the problem occurs, all you have to do is "touch" the resolv.dnsmasq file and it fixes it, causing DNSMasq to re-read it.

Again, I don't know why this restart of DNSMasq was added. But it certainly isn't necessary for updating the VPN's DNS servers. If it must be included for some other reason, then it should (imo) be placed at the end of the script so that it RELIABLY captures the changes to resolv.dnsmasq.

I consider it a serious bug because it compromises security, and being intermittent, is hard to detect.

Change History (5)

comment:1 Changed 6 months ago by eibgrad

Found another problem caused by this same bug. It happened in the following thread.

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1063054#1063054

He (warui111) couldn't get DNS to work across the tunnel AT ALL, despite the connection clearly being good; a ping of 8.8.8.8 worked. So we knew it was a DNS problem. So I had him dump his dnsmasq files.

root@DD-WRT:~# cat /tmp/dnsmasq.conf
interface=br0
resolv-file=/tmp/resolv.dnsmasq
strict-order
domain=hawaii.rr.com
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-lease-max=50
dhcp-option=br0,3,192.168.1.1
dhcp-authoritative
dhcp-range=br0,192.168.1.100,192.168.1.149,255.255.255.0,1440m
stop-dns-rebind

root@DD-WRT:~# cat /tmp/resolv.dnsmasq
nameserver 198.18.0.1
nameserver 198.18.0.2
nameserver 209.18.47.61
nameserver 24.25.227.55

root@DD-WRT:~# cat /tmp/resolv.dnsmasq_isp
nameserver 209.18.47.61
nameserver 24.25.227.55

I became suspicious that his lack of DNS might be due to this same bug, so I had him touch resolv.dnsmasq, and voila, it solved the problem.

Presumably DNSMasq was still pointing to the ISP's DNS servers, and they happened to not be available over the VPN. But once resolv.dnsmasq was touch'd, that caused the reread by DNSMasq, and now the DNS servers were those of the VPN and got things working again.

comment:2 Changed 6 months ago by egc112

Still present in build 31205M Kong

Version 0, edited 6 months ago by egc112 (next)

comment:3 Changed 5 months ago by egc112

Still present in Kong 31550.

In route-up.sh line:

touch /tmp/resolv.dnsmasq

was added but still my router R6400 is too fast. Suggestion, add: sleep 2

sleep 2
touch /tmp/resolv.dnsmasq
Last edited 5 months ago by egc112 (previous) (diff)

comment:4 Changed 3 months ago by egc112

Seems resolved in 31870M

comment:5 Changed 3 months ago by egc112

Cc: egc112 added
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.