vpnshift.sh
vpnshift.sh copied to clipboard
crasm
DNS leak on Ubuntu 17.04
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.
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]
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.
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.
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
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.
Humm... don't know why the browser only is affected... all browsers so far I've tested, chrome, chromium, firefox, vivaldi.
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
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
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
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.
Do you want this change to individual clients or the vpnshift script?
On Sun, Dec 16, 2018 at 11:14 AM Mike [email protected] wrote:
Maybe this helps... (i am on ubuntu 18.04, so maybe not)
apt install openvpn-systemd-resolvedThen 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-preStart 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.comWhich 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.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/crasm/vpnshift.sh/issues/7#issuecomment-447646601, or mute the thread https://github.com/notifications/unsubscribe-auth/ABum-wDWCSpyX5tqAU5R3gcpVxSOk6v5ks5u5lUugaJpZM4OWVmW .