/etc/openvpn/update-resolv-conf and DNS leakage

taylorkh · 06-26-2017, 08:24 AM

The script referenced in the subject is SUPPOSED to eliminate DNS leakage when using a VPN. In my experience it is not doing so. The .ovpn files supplied by my VPN provider (two different providers actually) contain the final stanza

Code:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Using Ubuntu Mate 16.04 as my test platform (also CentOS 7.3 as my production platform) I have installed the necessary packages openvpn and NetworkManager-openvpn-gnome. I have created the VPN connections using NetworkManager and can connect to the VPN server of my choice. ipleak.net shows me the DNS server specified by the VPN provider AND the DNS servers specified by my ISP.

If I connect to the VPN and examine "Connection information" from NetworkManager I see that the VPN "Active Network Connection" indicates a primary DNS corresponding to the VPN provider. I further see a connection "tun(0) default" is created. It also has the desired DNS. However, my WiFi connection is also present of course - that is how the PC connects to the nework - and it points to my router 192.168.0.1 as its DNS. The router picks up its DNS from the ISP.

Something is obviously not working as intended.

I can and have addressed this by running the VPN connection from the command line and substituting my own scrips which brute force replace /etc/resolf.conf with one containing the appropriate DNS for the VPN provider I am using. I have also hard coded the VPN providers' DNS values into the router. On the other hand, the VPN providers claim that the NetworkManager and update-resolv-conf approach is supposed to fix the leakage issue. I do have a ticket in to one of the VPN vendors and I am waiting for them to digest the last batch of requested data which I sent them last Thursday.

I sure would like to get this working. Just on principle. Any suggestions?

TIA,

Ken

ferrari · 06-27-2017, 03:21 AM

Since you're using NetworkManager to manage your network connections, it takes care of the DNS management as well. This Ubuntu bug report describes what is likely to be happening here
https://bugs.launchpad.net/ubuntu/+s...n/+bug/1211110
Not really a bug as such, since NM is working as designed, but it does impact on those trying to take care of DNS via scripts like you are apparently

The following workaround has been suggested

Quote:

Works for me after disabling NetworkManager's own dnsmasq.

Edit /etc/NetworkManager/NetworkManager.conf

Code:

#dns=dnsmasq

and restart NetworkManager

Code:

sudo restart network-manager

I wonder if you could reconfigure the VPN connection to take care of IP addresses only and manually add your preferred DNS server manually?

taylorkh · 06-27-2017, 08:31 AM

Hello ferrari and thank you for the reply.

The bug report reads like a summary of what I have found when searching for DNS leaks and Ubuntu. Fixed in the next version...Not!, works for me, doesn't work for me etc.

I tried the edit to networkManager.conf on an Ubuntu Mate 16.04 virtual machine. No change. CentOS 7.3 does not have that option by default (it also leaks). I am reimaging my test machine back to Ubuntu and will check the edit on a physical machine in a minute.

That said, Network Manager on Ubuntu is flaky. A couple of years back I was setting up a little Dell Inspiron 3050 Micro (small Intel NUC size PC) which I wanted to connect by WiFi and run headless. I installed Ubuntu, configured my hidden WiFi network with security, credentials etc. Worked fine. Rebooted the PC and it would not connect until I logged on. I tried the recommended Ubuntu fixes - make sure WiFi connection is available to all users (it was) some other configuration tweaks, circling a chicken bone counterclockwise around the PC in the light of a full moon while on my left foot etc. No go. I installed CentOS 7 + Mate. Configured WiFi, rebooted and it connected as expected.

The Ubuntu test machine is back. Made changes per your request. No difference. I still see the ISP provided DNS servers. Oh well. Ubuntu is not proving to be a stable Linux distro for me these days. This test PC locked up twice overnight during this VPN testing. The cooling fan was running full speed each morning so the CPU must have been doing something. However, the machine did not appear on the network nor did it respond to the keyboard. I restored a CentOS 7.3 image and it had run since last Saturday morning and stayed connected to the VPN (3 days).

As to my REAL solution...

On my router I hard coded the DNS addresses of my two VPN providers (10.x.x.x addresses which can only be addressed via the VPN tunnel)

In the .ovpn files I have substituted the IP address of the VPN server for the name (one provider, other already had the IP address specified)

On my CentOS 7 "router" PC I am running openvpn. I make the connection using a script e.g.

Code:

sudo openvpn --config ~/bin/us-04.protonvpn.com.udp1194.ovpn --auth-user-pass ~/bin/propw

To the .ovpn files I have added

Code:

script-security 2
up /etc/openvpn/proton_on.sh
down /etc/openvpn/proton_off.sh

The up script is

Code:

#!/bin/bash
# replace /etc/resolv.conf with special version for protonmail VPN
rm /etc/resolv.conf
cp /etc/resolv.conf.proton /etc/resolv.conf

resolc.conf.proton contains

Code:

# Generated by Ken - hard coded DNS for this VPN
nameserver 10.x.x.x

which in actuality contains the correct value for this provider. I am not using the down script currently - it is just a stub.

In use I perform the following

1 - ssh to my "router" PC
2 - issue the screen command
3 - execute the script for the desired VPN connection
4 - when the connection is established I detach the screen with "Alt-r d" thus leaving the process running and allowing me to close the ssh connection.
5 - if I need to change or restart the connection I reconnect to the screen with "screen -r" cancel the process with Ctrl-c and make a new connection.

I have found this to be very robust and reliable. As a side benefit I have noticed that if/when the VPN connection drops MOST internet traffic is blocked due to a loss of access to a DNS server. Not a true kill switch but it stops browser and email traffic from accessing the Internet without benefit of the VPN.

I think I will let someone else "fix" Ubuntu NetworkManager. The folks at ProtonVPN (same folks as Protonmail.ch) are working on a Linux VPN utility to compliment their Windoze, Mac and Android programs. I will give it a try some day when it becomes available. In the mean time I will continue to use my cave man "big stone hammer" approach of clobbering resolv.conf when I connect.

Ken

p.s. If you recall the issue of the ancient Brother MFC vs. modern USB controller issue which we discussed earlier this year... The MFC is working fine on my $5US "high speed" USB 2.0 card from ebay in my Dell workstation. I should probably invest another $5 in a spare card

Cheers!

ferrari · 06-27-2017, 01:46 PM

Thanks for the update Ken. Yes, configuring the DNS servers on the router is probably the best approach as you have done, and yes I do remember the 'ancient' Brother printer.