Ubuntu – Is it possible to remove the default gateway from /etc/resolv.conf after successful VPN connection

dnsnetwork-managerpptpvpn

I have configured PPTP VPN connection on Ubuntu 16.04.3 LTS via NetworkManager (nm-pptp-ppp-plugin) and it works. My configuration:

VPN
- Gateway
- User name
- Password
- Advanced – set some options on PPTP Advanced Options
IPv4 Settings
- Method: Automatic (VPN) addresses only
- DNS servers : 192.168.1.1 (internal IP address of VPN's default gateway)
IPv6 Settins
- Method: Ignore

I commented out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf, ran sudo dpkg-reconfigure resolvconf and sudo resolvconf -u.

Without VPN connection my /etc/resolv.conf contains the following line:

nameserver 192.168.3.1

where 192.168.3.1 is IP of my router.
After that, VPN connection /etc/resolv.conf changes to:

nameserver 192.168.1.1
nameserver 192.168.3.1

But as far as I can understand it should contain only 192.168.1.1.

Is it possible to remove my router's IP (192.168.3.1) from /etc/resolv.conf programmatically?
I mean by NetworkManager dispatcher or similar.

It seems that I do not have the DNS leak issue with my current configuration.

P.S. I understand that my question may have been discussed before, but possible duplicates do not fit my needs.

Update 1. On my other 16.04 laptop I also needed to disable systemd-resolved.service with:

sudo systemctl stop systemd-resolved.service
sudo systemctl disable systemd-resolved.service

Best Answer

This is a well known bug of NetworkManager, specifically it is #1211110. It goes back to Ubuntu 13.04 up to 16.04 and to a worse extent to Ubuntu 16.10.

It seems that I do not have DNS leak issue with my current configuration.

Then consider yourself pretty lucky. :) Most users (including myself) experienced severe DNS leaks and tried different approaches to solve them.

Here are some approaches suggested in the bug report (summarized):

Comment #22 by Mac Bassett

Make a backup copy of this NetworkManager file:

sudo cp /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper.orig

Add the following 3 lines to the file.

#!/bin/bash
/etc/openvpn/update-resolv-conf $@
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper.orig $@

Then:

sudo chmod +x /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper

Caveat: you need to run the following command after disconnecting the VPN.

sudo script_type=down dev=tun0 /etc/openvpn/update-resolv-conf

Comments #27 and #29 by myself

Edit your VPN connection (via NM) and set up static DNS, for example using Google servers:
8.8.8.8, 8.8.4.4
This way, the DNS request is sent through an external IP, hence it is routed using the VPN.

Then also set up your wireless connection to use those static DNS servers.

Comment #31 by DaveHenson

Run openvpn through the command line.

(... some other cumbersome solutions that I won't discuss here ...)

Comment #81 by Çağatay Yüksel

Remove this configuration file:
sudo rm -rf /etc/resolv.conf
Add this line to the [main] section of /etc/NetworkManager/NetworkManager.conf:
dns=dnsmasq
If you have the dnsmasq package installed, you should make sure the dnsmasq service is not enabled otherwise this will not work. You should also reboot.

The real solution

This bug has been fixed in Ubuntu 17.04. Rather than trying random patches on your system, it is probably a better idea to simply upgrade. :)

DNSoverTLS 1.1.1.1 OpenVPN configuration.

First you need systemd-resolved installed and configured to use stub-resolv.conf.

ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
cat /etc/resolv.conf

Output

nameserver 127.0.0.53
options edns0

systemd-networkd

/etc/systemd/resolved.conf (example):

[Resolve]
DNS=8.8.8.8 8.8.4.4
FallbackDNS=1.1.1.1 1.0.0.1
LLMNR=no
MulticastDNS=no
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
Cache=yes
DNSStubListener=yes

/etc/systemd/network/ethX.network (example):

[Match]
Name=eth*

[Link]
RequiredForOnline=yes

[Network]
DHCP=yes
MulticastDNS=no
LLMNR=no
LinkLocalAddressing=no

[DHCP]
UseDNS=yes
UseHostname=no
CriticalConnection=yes

/etc/systemd/network/tunX.network (important!):

(in order for openvpn to be able to administer tun link, the link must be unmanaged)

[Match]
Name=tun*

[Link]
Unmanaged=yes

I use update-resolved to configure systemd-resolved. (you can use update-systemd-resolved or aptitude install openvpn-systemd-resolved, but when you need to follow README.md instead).

Installing update-resolved:

cd /etc/openvpn
git clone https://github.com/bac0n/update-resolved.git

Add update-resolved to your openvpn.conf:

# Include update-resolved up/down script.
config /etc/openvpn/update-resolved/update-resolved.ovpn

Restart openvpn:

systemctl restart openvpn

Journald:

journalctl -t update-resolved

Output

-- Logs begin at Sat 2019-09-21 12:28:01 CEST, end at Sun 2019-09-22 17:05:01 CEST. --
Sep 21 12:28:11 foobar update-resolved[914]: Note: Successfully configured resolved on link 3 (tun0)

Note:

As default it uses openvpn supplied dns´s. if you like to use static dns´s you need to filter the dns´s supplied by openvpn in 'update-resolved.ovpn' and set your own dns´s in 'update-resolved.conf'

Example:

resolve_options=(DOMAIN ~. DNS 1.1.1.1 DNS 1.0.0.1 LLMNR no MulticastDNS no)

(when using domain ~. resolved will use the tun link for all your dns queries (unless other too carry such a route-only domain). When the tun link is removed resolved will start using 'global' and 'isp' dns´s in parallel, Protocols and Routing)

Ubuntu – Openconnect in network-manager does not update resolv.conf

I found the solution. Basically, if the dns server sents ipv6 dns servers to lookup ipv4 addresses things go wrong. Openconnect will put ipv6 addresses in INTERNAL_IP4_DNS and the "network-manager-openconnect" does not expect that, treats the whole variable (and basically all dns servers) as garbage and goes on. I compiled my own network-manager-openconnect from master which has a fix for this, and that works fine.

I don't know why I have this problem after upgrading. Maybe something changed in openconnect? Or maybe in the day I upgraded my company network admin added an ipv6 dns server? (I think that is unlikely...)

If you are using network-manager-openconnect 1.2.6 or 1.2.7-dev (or maybe even a lower version, which does not contain the fix) you can compile your own version from master like so:

sudo apt-get build-dep network-manager-openconnect
mkdir ~/network-manager-openconnect_build
cd ~/network-manager-openconnect_build
git clone https://gitlab.gnome.org/GNOME/NetworkManager-openconnect.git
cd NetworkManager-openconnect
./autogen.sh
make
sudo mv /usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper /usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper_bak
sudo cp src/nm-openconnect-service-openconnect-helper /usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper

Note: I only copied over the helper bin. In theory this could give incompatibility problems. I had no problems with it. But if you have, you might try to copy over the main bin as wel from src.

If you want, you can use the following to have extra logging for the vpn module to see in the syslog if openconnect received any dns data:

sudo nmcli general logging level KEEP domains VPN_PLUGIN:TRACE

If you see the INTERNAL_IP4_DNS being set with both ipv4 and ipv6 addresses, and you use the openconnect network manager version mentioned above, you are affected with this bug.