Debian openvpn client DNS leak after interface change (wired to wifi)

[zoof]

Openvpn appears to have (DNS leaking problems) over wifi using the Debian command line openvpn client. There is no such problem with a wired connection. I have tried the stock Debian, backported Debian and openvpn repo version of the openvpn client and all of them suffer from DNS leaking. I don't know if this problem is particular to GCE or not.

[cpu]

@zoof Some follow-up questions to help for this issue:

• What Debian version are you testing from?
• What test tool are you using to generate that screenshot?
• What controls your network interfaces? (e.g. NetworkManager, netctl, other?)
• What are the contents of /etc/resolv.conf when you're connected to the VPN and on Wired, what about when connected to the VPN and on wireless?
• Have you tried spinning up a Streisand instance in another provider to rule out whether it is GCE related or not?

It seems strange that it would only affect wireless connections.

[zoof]

• I am using Debian Jessie
• https://dnsleaktest.com/
• NetworkManager
• wired

$ cat /etc/resolv.conf
# Generated by resolvconf
search lan
nameserver 10.8.0.1
nameserver 192.168.2.1

wireless

$ cat /etc/resolv.conf 
# Generated by NetworkManager
search lan
nameserver 192.168.2.1

The openvpn command line output for the wireless connection is:

$ sudo openvpn /etc/openvpn/xx.xx.xx.xx-stunnel.ovpn 
Fri Apr 14 10:22:24 2017 OpenVPN 2.4.0 i586-pc-linux-gnu [SSL (OpenSSL)]
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jan 21 2017
Fri Apr 14 10:22:24 2017 library versions: OpenSSL 1.0.1t  3 May 2016, LZO
2.08
Fri Apr 14 10:22:24 2017 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
Fri Apr 14 10:22:24 2017 Outgoing Control Channel Authentication: Using 256
bit message hash 'SHA256' for HMAC authentication
Fri Apr 14 10:22:24 2017 Incoming Control Channel Authentication: Using 256
bit message hash 'SHA256' for HMAC authentication
Fri Apr 14 10:22:24 2017 TCP/UDP: Preserving recently used remote address:
[AF_INET]127.0.0.1:41194
Fri Apr 14 10:22:24 2017 Socket Buffers: R=[87380->87380] S=[16384->16384]
Fri Apr 14 10:22:24 2017 Attempting to establish TCP connection with
[AF_INET]127.0.0.1:41194 [nonblock]
Fri Apr 14 10:22:24 2017 TCP connection established with
[AF_INET]127.0.0.1:41194
Fri Apr 14 10:22:24 2017 TCP_CLIENT link local: (not bound)
Fri Apr 14 10:22:24 2017 TCP_CLIENT link remote: [AF_INET]127.0.0.1:41194
Fri Apr 14 10:22:25 2017 TLS: Initial packet from [AF_INET]127.0.0.1:41194,
sid=2e8aea2e c953d365
Fri Apr 14 10:22:25 2017 VERIFY OK: depth=1, C=US, ST=California, L=Beverly
Hills, O=ACME CORPORATION, OU=Anvil Department, CN=ca-certificate
Fri Apr 14 10:22:25 2017 Validating certificate key usage
Fri Apr 14 10:22:25 2017 ++ Certificate has key usage  00a0, expects 00a0
Fri Apr 14 10:22:25 2017 VERIFY KU OK
Fri Apr 14 10:22:25 2017 Validating certificate extended key usage
Fri Apr 14 10:22:25 2017 ++ Certificate has EKU (str) TLS Web Server
Authentication, expects TLS Web Server Authentication
Fri Apr 14 10:22:25 2017 VERIFY EKU OK
Fri Apr 14 10:22:25 2017 VERIFY X509NAME OK: C=US, ST=California, L=Beverly
Hills, O=ACME CORPORATION, OU=Anvil Department, CN=Bukharan.nastic
Fri Apr 14 10:22:25 2017 VERIFY OK: depth=0, C=US, ST=California, L=Beverly
Hills, O=ACME CORPORATION, OU=Anvil Department, CN=Bukharan.nastic
Fri Apr 14 10:22:25 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3
ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Apr 14 10:22:25 2017 [Bukharan.nastic] Peer Connection Initiated with
[AF_INET]127.0.0.1:41194
Fri Apr 14 10:22:26 2017 SENT CONTROL [Bukharan.nastic]: 'PUSH_REQUEST'
(status=1)
Fri Apr 14 10:22:26 2017 PUSH: Received control message:
'PUSH_REPLY,dhcp-option DNS 10.8.0.1,redirect-gateway
def1,block-outside-dns,route 10.8.0.0 255.255.255.0,topology net30,ping
1800,ping-restart 3600,ifconfig 10.8.0.10 10.8.0.9,peer-id 0,cipher
AES-256-GCM'
Fri Apr 14 10:22:26 2017 Options error: Unrecognized option or missing or
extra parameter(s) in [PUSH-OPTIONS]:3: block-outside-dns (2.4.0)
Fri Apr 14 10:22:26 2017 OPTIONS IMPORT: timers and/or timeouts modified
Fri Apr 14 10:22:26 2017 OPTIONS IMPORT: --ifconfig/up options modified
Fri Apr 14 10:22:26 2017 OPTIONS IMPORT: route options modified
Fri Apr 14 10:22:26 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
Fri Apr 14 10:22:26 2017 OPTIONS IMPORT: peer-id set
Fri Apr 14 10:22:26 2017 OPTIONS IMPORT: adjusting link_mtu to 1627
Fri Apr 14 10:22:26 2017 OPTIONS IMPORT: data channel crypto options
modified
Fri Apr 14 10:22:26 2017 Data Channel Encrypt: Cipher 'AES-256-GCM'
initialized with 256 bit key
Fri Apr 14 10:22:26 2017 Data Channel Decrypt: Cipher 'AES-256-GCM'
initialized with 256 bit key
Fri Apr 14 10:22:26 2017 ROUTE_GATEWAY 192.168.2.1/255.255.255.0 IFACE=wlan0
HWADDR=00:23:4e:80:24:62
Fri Apr 14 10:22:26 2017 TUN/TAP device tun0 opened
Fri Apr 14 10:22:26 2017 TUN/TAP TX queue length set to 100
Fri Apr 14 10:22:26 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Apr 14 10:22:26 2017 /sbin/ip link set dev tun0 up mtu 1500
Fri Apr 14 10:22:26 2017 /sbin/ip addr add dev tun0 local 10.8.0.10 peer
10.8.0.9
Fri Apr 14 10:22:26 2017 /etc/openvpn/update-resolv-conf tun0 1500 1555
10.8.0.10 10.8.0.9 init
Fri Apr 14 10:22:26 2017 /sbin/ip route add 127.0.0.1/32 via 192.168.2.1
Fri Apr 14 10:22:27 2017 /sbin/ip route add 0.0.0.0/1 via 10.8.0.9
Fri Apr 14 10:22:27 2017 /sbin/ip route add 128.0.0.0/1 via 10.8.0.9
Fri Apr 14 10:22:27 2017 /sbin/ip route add xx.xx.xx.xx/32 via 192.168.2.1
Fri Apr 14 10:22:27 2017 /sbin/ip route add 10.8.0.0/24 via 10.8.0.9
Fri Apr 14 10:22:27 2017 Initialization Sequence Completed

Could NetworkManager be overwriting the result of update-resolv-conf?

• I have not.

[cpu]

Could NetworkManager be overwriting the result of update-resolv-conf?

That seems very likely - you can see in /etc/resolv.conf when you're on wireless that the line for the Streisand DNS server (nameserver 10.8.0.1) is missing, so you are sending queries to 192.168.2.1 which is likely your local router's stub resolver that talks to your ISP's DNS servers.

[cpu]

I updated the title of the issue to clarify that it isn't GCE related. Thanks for the info!

[zoof]

After disabling the wireless connection and plugging in an ethernet cable to the laptop with the DNS leak, I am still getting the same contents to /etc/resolv.conf. Both laptop and desktop are running the same Debian Jessie (bunsenlabs). The contents of /etc/network/interfaces is the same on both. Not sure what other difference there could be.

[zoof]

I have now tried openvpn on a 3rd Debian Jessie computer also revealing a DNS leak.