Network Manager w/ dnsmasq Dies when VPN-ing

[Thomas Ward]

Hello.

Within the past week or so, a new bug has cropped up on Network Manager on 16.04.

When Network Manager on 16.04 is configured to use dnsmasq and not systemd-resolved, one is expecting VPN DNS servers to be properly set and dnsmasq to properly route DNS requests to the Internet.

However, when connecting to my OpenVPN connection, dnsmasq now fails extremely hard and no longer replies or routes data for DNS requests properly. This results in me having to use a fail-over workaround of enforcing resolvconf to use my local `bind9` instance on my own system for DNS, which is configured to route to Google for DNS requests. This, however, prohibits me from using my own DNS on my VPN connect, which are on the remote location and serve internal ranges and domains that I should be permitted to access.

Given these issues, with `dnsmasq` just outright exploding in our faces and no longer being usable for DNS request routing over the VPN, I'm not even sure we can consider VPN DNS as a viable option anymore with 16.04.

Note that this is only *very* recently a problem within the past few weeks, and I can't find any updates which would have impacted this.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: network-manager 1.2.6-0ubuntu0.16.04.1
ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44
Uname: Linux 4.4.0-66-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Mar 23 14:04:06 2017
InstallationDate: Installed on 2016-12-20 (92 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.2.6 connected started full enabled enabled enabled enabled enabled

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sergio Callegari (callegar)]

Can we safely assume that bug 1675820 is a duplicate of this one?

In that case, dnsmasq seems to operate correctly. In fact, setting the domain server with an explicit dbus command, that is

sudo qdbus --system org.freedesktop.NetworkManager.dnsmasq /uk/org/thekelleys/dnsmasq \
    org.freedesktop.NetworkManager.dnsmasq.SetDomainServers "(" "8.8.8.8" ")"

makes the trick and gets name resolution operate correctly. It looks like the fault is on network manager not passing the domain servers to dnsmasq via dbus in the correct way (or at all).

Was a test of this sort practised in this case?

[Thomas Ward (teward)]

Sergio,

No, however I would be happy to test later today. The primary reason for my
having a backup local resolving bind9 was just for cases like this, but I'll test the DBUS method in a few hours and get back to you

[Thomas Ward (teward)]

Interesting, I can't reproduce with standard WPA2 wifi connections.

I wonder if it's specific to the combination of WPA2 Enterprise (with custom DNS settings in the system) and then that being overridden by the VPN and that causes some breakages.

I'll test in a few hours when I'm on such a network where I can test it. (At my apartment, I have a WPA2 Enterprise network, but that seems to properly show the right DNS and such... and I can't VPN to the apartment when I'm *on* the Apartment's networking).

[Thomas Ward (teward)]

Sergio,

Also, I'm not 100% certain the other bug is not a dupe of this one, because Yakkety. Their workarounds of restarting dnsmasq, etc. still didn't work on a 16.04 system (even restarting Network Manager didn't help - dnsmasq was still dead for *everything*), and now I'm getting issues where the domain is set proper with search domains, but I'm 'refused' from querying the domain assigned.

The DNS servers that *should* be assigned by the VPN are properly handling the requests, so I don't know what's going on and will check more later. (Falling back to local `bind9` resolver in the mean time)

[Mahlon E. Smith (mahlon)]

Some additional (but minor) information:

After a fresh boot, everything appears to work perfectly as expected for the -first- connection to the VPN. That is to say, the DNS servers pushed from the OpenVPN server are used to resolve VPN domains, and all is well.

After a subsequent disconnect and reconnect, it no longer works. Direct connections to IP addresses are fine, but resolution refuses to function properly.

I've worked around this for now with the sub-optimal method of hardcoding a resolver:

   echo "server=/[DOMAIN]/[RESOLVER IP]" > /etc/NetworkManager/dnsmasq.d/vpn.conf

... and restarting dnsmasq.

This seems to imply the problem lies somewhere in dbus communication, as Sergio mentioned above.

[Kevin (fibou)]

Hi everybody,

I had this problem too on LinuxMint 18 (based on 16.04).
I solved the problem by reverting the network-manager package to the version 1.2.2 (instead of 1.2.6) using synaptic.

Maybe it can help someone
Cheers

[CaptaFrak (captafrak)]

Hi, I had the same problem on Linux Mint 18.1
First time i start openvpn connexion all is ok. But if i stop it and start again via networkmanager, there are no DNS (but ping ip is ok).
A reboot of the computer make dns come back.

Or i found a temporary solution, modify the file /etc/NetworkManager/NetworkManager.conf
and comment the line #dns=dnsmasq
After this i stop / start many times openvpn connexion via network-manager and it works well.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.