DNS leak on Ubuntu 17.04

[jonpolak]

The application running in the new namespace uses the real host's DNS ( from the host's /etc/resolv.conf ) not the hardcoded cryptostorm address.

[jonpolak]

Further information:
when using dig I see that the nameserver that is being queried is indeed the hardcoded cryptostream dns server. However, when I use a browser, e.g. firefox, vivaldi, then the host system dns-server is being used -- I see this at dnsleaktest.com

From within the namespace:

ip route show
0.0.0.0/1 via 172.111.202.193 dev tunvpn 
10.10.10.10/31 dev veth_vpn proto kernel scope link src 10.10.10.11 
128.0.0.0/1 via 172.111.202.193 dev tunvpn 
172.111.202.2 via 10.10.10.10 dev veth_vpn 
172.111.202.192/26 dev tunvpn proto kernel scope link src 172.111.202.195 

from the host:

jojo-> ls
frootvpn  vpnshift
[/etc/netns]
jojo-> cat vpnshift/resolv.conf 
nameserver 108.62.19.131
nameserver 104.238.194.235
[/etc/netns]
jojo-> ip route show
default via 192.168.86.1 dev wlp4s0 proto static metric 600 
10.10.10.10/31 dev veth_default proto kernel scope link src 10.10.10.10 
169.254.0.0/16 dev wlp4s0 scope link metric 1000 
192.168.86.0/24 dev wlp4s0 proto kernel scope link src 192.168.86.135 metric 600 
[/etc/netns]

[crasm]

Did a little test and DNS wasn't leaking in chromium/firefox for me. The contents of /etc/resolv.conf were the cryptostorm addresses.

When I re-enter the vpnshift netns with sudo ip netns exec vpnshift sudo -u $USER $SHELL it sticks, but if I use nsdo then I see the non-cryptostorm DNS nameservers. Not sure if related...

Basically, I can't reproduce. What does your /etc/resolv.conf look like when inside the vpnshift netns? What's your distro? I'm on Arch Linux and /etc/netns/vpnshift/resolv.conf appears to be copied or otherwise used to set /etc/resolv.conf.

[jonpolak]

I'm on Ubuntu 17.04.
Within /etc/netns/vpnshift/resolv.conf i find cryptostorm from the host or the namespace terminal. From the namespace terminal /etc/resolv.conf contains cryptostorm as well -- though from a regular terminal /etc/resolv.conf I have google dns 8.8.4.4 (NOTE -- I make the resolv.conf file immutable to stop network-manager from changing it when I connect to wifi -- I used to have it set to point to localhost and ran dnsmasq and dnscrypt-proxy to do dns).

I confirm that commands ran from any terminal that are preceded by sudo ip netns exec vpnshift sudo -u $USER execute the command in the vpnshift namespace -- I tried a tracepath and it shows it is going over vpn.... dig also shows that it is using cryptostorm... though any browser (chromium, vivaldi, firefox) -- they do go over vpn but dnsleaktest shows that the dns requests are heading to google.... (the host's dns).... very strange.

I made sure that no other instances of firefox vivaldi chromium were running.

[jonpolak]

FYI the

openvpn config:

client
nobind
dev tun
proto udp
remote ie1-ovpn-udp.purevpn.net 53
redirect-gateway def1 bypass-dhcp
persist-key
persist-tun
ca ca.crt
tls-auth Wdc.key 1
cipher AES-256-CBC
comp-lzo yes
verb 1
mute 20
auth-retry interact
explicit-exit-notify 2
ifconfig-nowarn
user nobody
group nogroup

[crasm]

Huh, I spun up an ubuntu vm and it's happening to me also. If I had to guess, maybe it's systemd-resolved, but issuing a systemctl restart systemd-resolved.service within the vpnshift netns didn't fix it.

[jonpolak]

Humm... don't know why the browser only is affected... all browsers so far I've tested, chrome, chromium, firefox, vivaldi.

[jonpolak]

Running tcpdump -n port 53 on the host while doing dig queries shows that the query is going over the tun connection -- shows all the responses from port 53 coming from the openvpn node.

Doing the tcpdump -n port 53 in the namespace while running dig shows that the query is being correctly sent to cryptostorm servers.

However, all webbrowser traffic completely bypasses the namespace tcpdump - doesn't even show up. Shows up in the host tcpdump (unencrypted and does not go over the tun bridge -- thus leaking your IP address also)

The problem might be "namespace aware applications" as discussed in a comment on stackoverflow... very strange

[jonpolak]

Ubuntu 17.10 (beta 2) also affected

[jonpolak]

Solution!
Systemd-resolve is the culprit

The resolver is systemd-resolvd (by default since 17.04 Ubuntu)

To solve it you need to add
dhcp-options DOMAIN-ROUTE
to the ovpn file

[jonpolak]

hmm -- it's not that simple. The above doesn't seem to work.

Since systemd-229, the systemd-resolved service has an API available via DBus which allows directly setting the DNS configuration for a link. This script makes use of busctl from systemd to send DBus messages to systemd-resolved to update the DNS for the link created by OpenVPN.

from github

[mmjo]

Maybe this helps... (i am on ubuntu 18.04, so maybe not)

    apt install openvpn-systemd-resolved

Then add this fragment to your openvpn client.conf file:

    dhcp-option DOMAIN-ROUTE .
    verb 3
    script-security 2
    up /etc/openvpn/update-systemd-resolved
    down /etc/openvpn/update-systemd-resolved
    down-pre

Start the vpn: systemctl restart openvpn@client replacing client with whatever you have.
Run ip r to verify that the tunnel is up.
Maybe check /var/log/syslog for messages (as verb 3 logs more than default).
Now run systemd-resolve --flush-caches (for the next checks only).
Check with systemd-resolve --status, do you see DNS Domain: ~.?
and run the test at https://www.dnsleaktest.com

If the connected network uses its own suffix, e.g. example.com, then you could also try

    dchp-option DOMAIN-ROUTE example.com

Which makes lookup for e.g. www.example.com go to the vpn-dns.
In the output of systemd-resolve --status you should see DNS Domain: ~example.com

The DOMAIN-ROUTE dhcp-option does not append .example.com to short names (without dots). For that you may want to add dchp-option DOMAIN-SEARCH example.com

Any of this might fail to prevent all dns leakage:

• shortly after the tunnel goes down, you may be initiating sensitive lookups to your isp again;
• your local dns names may leak into the vpn-dns, if you have a search domain confiigured.