How (I think?) I solved DNS leakage on my CentOS 7 PC

taylorkh · 03-30-2017, 03:06 PM

I have tired of playing with this issue so I decided to apply my normal BFH technique

openvpn is SUPPOSED to support an option "block-outside-dns" in the .ovpn configuration file from my reading. It does not seem to work.

Debian and Debian based distros ('buntus etc.) have a package resolvconf which provides scripts to manage this mischief. No such thing in CentOS. I found reference to openresolv which works in Arch but I have not gotten it to work in CentOS.

Using an Ubuntu 16.04 VM I did some testing and observing. It seems that by adding these lines to the bottom of the .ovpn configuration file

Code:

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

the first referenced script will fire when the VPN is enabled and the second script after the VPN closes. In this case update-resolv-conf is called both times. It determines what happened and acts accordingly. Having no luck with this script on CentOS I decided to create my own scripts.

In observing what happened on Ubuntu during this process I determined that the net result (sorry for the pun) was that the file /etc/resolv.conf was modified to stuff the VPN provider's DNS address at he top of the file. Based on my observations and confirmed by correspondence with my VPN providers I determined that their DNS addresses were:

usenetserver.com VPN 10.18.0.1 and 10.0.18.2
protonmail.ch VPN (beta) 10.8.8.1

I created these files in /etc/

Code:

# resolv.conf.usenetserver
# Generated by Ken - hard coded DNS for this VPN
nameserver 198.18.0.1
nameserver 198.18.0.2

# resolv.conf.proton
# Generated by Ken - hard coded DNS for this VPN
nameserver 198.8.8.1

My scripts are placed in /etc/openvpn. These are for the protonmail VPN. Two more for usenetserver - same concept

Code:

proton_on.sh
============
#!/bin/bash
# replace /etc/resolv.conf with special version for protonmail VPN
mv /etc/resolv.conf /etc/resolv.conf.save
cp /etc/resolv.conf.proton /etc/resolv.conf

proton_off.sh
=============
#!/bin/bash
# restore original /etc/resolv/conf after exiting VPN
rm /etc/resolv.conf
mv /etc/resolv.conf.save /etc/resolv.conf

To fire these scripts at the appropriate time I added these lines to the .ovpn file

Code:

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

This seems to be working. Several of the "test for DNS leak" web sites gave me a clean bill of health. The others offered me a bill if I purchased their service/product but the results listed looked reasonable to me. I have yet to have one of these sites display my REAL (ISP assigned) address.

I will be setting this up on my "router" PC which resides between my Netgear "real" router and my LAN. I am using the Netgear simply because the router PC has only one wired NIC and I must connect to the Internet with the WiFi card. The PC also runs DHCP for my LAN. The PC is run headless and I would not expect to do anything on it to cause, for example, Network Manager to overwrite the resolv.conf file which I wish to have in place.

I await your slings and arrows (torpedoes, broadsides or rotten tomatoes)... What have I screwed up with my simplistic approach?

TIA,

Ken

taylorkh · 03-31-2017, 01:05 PM

To take a pot shot at my own "solution"...
The openvpn command e.g.

Code:

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

requires administrative permissions to execute and will tie up a bash terminal as long as it is running. To accommodate these limitations I use screen to allow me to hide the running terminal after invoking openvpn. I can then reattach the screen at a later time to cancel openvpn. As to permissions, I have two options:

I can su in the bash terminal and then run the openvpn command. This leaves a root terminal running (although hidden by screen).

If I run the command with sudo and supply a password I do not have this rouge root terminal floating around. However, by the time I cancel openvpn my escalated permissions will probably have timed out. This will cause the second script - restoring /etc/resolv.conf to fail due to file permissions.

I prefer the second scenario. I would rather not have connectivity rather than having connectivity outside of the VPN.

Ken

p.s. As I am using the "router" PC as a DHCP server for my LAN I had a DNS address (for openvpn.com) hard coded in /etc/dhcp/dhcpd.conf. This caused a DNS leakage which it too a little time to track down. I replaced this address with the address of the "router" PC. Problem solved.