network-manager does not configure local resolver or dnsmasq to use the nameserver addresses received from the VPN server

[Oscar Tiderman]

NetworkManager/dnsmasq does not set the DNS servers given by the OpenVPN server when I connect. I can see in my syslog that I do receive the name server addresses correctly along with all the routes:

Apr 16 08:14:09 homer NetworkManager[4014]: <info> Internal DNS: 192.168.11.90
Apr 16 08:14:09 homer NetworkManager[4014]: <info> Internal DNS: 192.168.11.190

However, they are not used:

oscar@homer:~$ nmcli -f IP4 dev list | grep DNS
IP4.DNS[1]: 192.168.0.1
oscar@homer:~$

(That is my default DNS/Gateway and it should still be queried for all DNS queries outside of VPN network)

If I comment out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf and restart NetworkManager then DNS starts to work properly again, VPN nameservers are used for domain names on the VPN network and others through my default nameserver. Let me know if I kan provide further info about this issue.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: network-manager 0.9.6.0-0ubuntu7
ProcVersionSignature: Ubuntu 3.5.0-28.47-generic 3.5.7.9
Uname: Linux 3.5.0-28-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.6.1-0ubuntu10
Architecture: amd64
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Date: Tue Apr 16 08:16:42 2013
EcryptfsInUse: Yes
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2012-11-22 (144 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
IpRoute:
 default via 192.168.0.1 dev eth1 proto static
 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.44 metric 9
MarkForUpload: True
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2013-04-16T08:12:17.691993
nmcli-con:
 NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
 Wired connection 1 179bc6d7-cd13-4cfb-b73f-e8da8362a511 802-3-ethernet 1364485020 tor 28 mar 2013 16:37:00 yes no /org/freedesktop/NetworkManager/Settings/2
 Wiggum 2a818c4e-494c-4b91-be56-630636608f07 802-11-wireless 1366092808 tis 16 apr 2013 08:13:28 yes no /org/freedesktop/NetworkManager/Settings/1
                   81e14bde-0b0b-42be-8b56-3bfda6ca60fc vpn 1366092850 tis 16 apr 2013 08:14:10 yes no /org/freedesktop/NetworkManager/Settings/0
                aad98317-a8e1-4ff7-b3b5-7c43c1bcfd32 802-11-wireless 1358879064 tis 22 jan 2013 19:24:24 yes no /org/freedesktop/NetworkManager/Settings/3
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth1 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/1
 eth0 802-3-ethernet unavailable /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.6.0 connected enabled enabled enabled enabled disabled

[Oscar Tiderman (oscar-tiderman)]

Forgot to add, setting the name servers manually under Additional name servers in Network Manger GUI setting still doesn't acyually add the name servers

[Mathieu Trudel-Lapierre (cyphermox)]

I noticed this before, the openvpn plugin seems to be writing DNS configuration directly for some reason, which gets trampled by whatever NM is doing. Or at least, that what looked like was happening.

Confirming for now, needs to be further investigated in the NM openvpn code.

[Oscar Tiderman (oscar-tiderman)]

This bug still exists after upgrading to 13.04, commenting out dns=dnsmasq fron NetworkManager.conf still is a valid workaround.

[Hans Berglund (hans-c)]

I have upgraded to 13.04 too, but the workaround did not work for me. After trying different suggestions, I found that removing the "resolvconf" package fixed the problem. Now it works perfectly.

[Aaron_Seibert (aaron-bits)]

The workaound of commenting dns=dnsmasq worked for me

[Juan Moyano (wincus)]

The workaound of commenting dns=dnsmasq worked for me too

[Thomas Hood (jdthood)]

Please look through the bugs already filed against network-manager-openvpn to see if this issue has been reported before.

[Zeyelth (zeyelth)]

Confirmed to still be an issue in 13.04.

It is also worth pointing out that this bug has potential security and privacy implications if the DNS server provided by the local ISP can't be trusted.

[Thomas Hood (jdthood)]

This report was originally filed against network-manager and I reassigned it to network-manager-openvpn under the assumption that the submitter is using NetworkManager and network-manager-openvpn to configure and control the VPN. Is that the case for everyone who has commented above? Does anyone who has commented above use just the openvpn package and openvpn conf files, or something initiated by ifup?

[Thomas Hood (jdthood)]

P.S. Oscar, and everyone else who has commented, please say what version of network-manager-openvpn you are using.

I have just done some testing. I have the following package versions.

    network-manager 0.9.8.0-0ubuntu17
    network-manager-dev 0.9.8.0-0ubuntu6
    network-manager-gnome 0.9.8.0-1ubuntu2
    network-manager-openvpn 0.9.8.2-1ubuntu2

When I make an OpenVPN connection to corp.com via my home LAN which has local TLD "mydom" I see the following in /var/log/syslog.

    [...] NetworkManager[1247]: <info> Internal DNS: 172.17.1.2

Whether dns=dnsmasq or not I get the following.

    $ nmcli -f IP4 dev list | grep DNS
    IP4.DNS[1]: 192.168.1.254
    IP4.DNS[1]: 192.168.1.254

In fact, nmcli seems to have no knowledge at all of the VPN. But this doesn't seem to matter.

Now (a) if "dns=dnsmasq" then NetworkManager passes the address 127.0.1.1 (which is the listen address of the dnsmasq instance that it controls) to resolvconf

    $ cat /run/resolvconf/interface/NetworkManager
    domain mydom
    search corp.com mydom
    nameserver 127.0.1.1

which turns up in resolv.conf .

    $ cat /etc/resolv.conf
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 127.0.1.1
    search mydom corp.com

and passes the correct addresses to the dnsmasq instance that it controls, as evidenced by dnsmasq's messages in syslog.

    [...] dnsmasq[5803]: setting upstream servers from DBus
    [...] dnsmasq[5803]: using nameserver 172.17.1.2#53 for domain 17.172.in-addr.arpa
    [...] dnsmasq[5803]: using nameserver 172.17.1.2#53 for domain corp.com
    [...] dnsmasq[5803]: using nameserver 192.168.1.254#53
    [...] dnsmasq[5803]: using nameserver 192.168.1.254#53

Testing reveals that LAN, Internet and VPN names are all resolved correctly and I can see with wireshark that the DNS queries are forwarded to the correct addresses by dnsmasq. That is *.corp.com queries go to 172.17.1.2 and other queries to 192.168.1.254.

If (b) "dns=dnsmasq" is commented out then NetworkManager passes the VPN nameserver and LAN nameserver addresses, in that order, to resolvconf.

    $ cat /run/resolvconf/interface/NetworkManager
    domain mydom
    search corp.com mydom
    nameserver 172.17.1.2
    nameserver 192.168.1.254

    $ cat /etc/resolv.conf
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 172.17.1.2
    nameserver 192.168.1.254
    search mydom corp.com

Testing reveals that Internet and VPN names are resolved correctly but LAN names are not and I can see that all queries go to the VPN nameserver.

This is all as I would expect, except (as I mentioned earlier) for the nmcli output, which fails to include any VPN information.

Conclusion: I can't reproduce the bug. Name service works for me with or without "dns=dnsmasq" insofar as I would expect.

[Thomas Hood (jdthood)]

The submitter Oscar wrote in the original description:
> If I comment out dns=dnsmasq in NetworkManager.conf and
> restart NetworkManager all DNS start to work properly again,
> VPN DNS's are used for those resources on the VPN network
> and others through my default DNS.

Oscar, I don't know how that could be the case. The glibc resolver does not route DNS queries according to the name looked up. The resolver just tries one nameserver, waits the timeout period, then tries another nameserver, etc., until it receives an answer.

VPN nameservers are often set up to resolve Internet names as well as names on the remote LAN. That may have been true in your case.

Oscar wrote in comment #1
> Forgot to add, setting the name servers manually under
> Additional name servers in Network Manger GUI setting
> still doesn't acyually add the name servers

I can confirm this. This may be bug #1072899 again.

To everyone who has a malfunction and solves it by commenting out "dns=dnsmasq": perhaps you are hitting bug #1003842. Also make sure that /etc/resolv.conf is a symbolic link to ../run/resolvconf/resolv.conf.

To Hans, who worked around his bug by removing resolvconf: you probably had a different problem and removing resolvconf fixed it as a side-effect.

[Clemens Wehrmann (cwehrmann)]

My NetworkManager OpenVPN configuration had a domain listed under "Additional search domains".

With dns=dnsmasq this resulted in the domains pushed from openvpn via 'push "dhcp-option DOMAIN mydomain"to be ignored.

After removing the entry domains are added to dnsmasq (seen in /var/log/syslog) and resolving works.

The wording "additional" is misleading in the NM OpenVPN configuration , as is "search" -- this field is affecting which fully qualified domains are being resolved by dnsmasq, instead of adding additional resolution to unqualified names as I'd expect.

Without dns=dnsmasq in Network Manager, this works as expected because resolvconf adds the nameservers to the global list for all queries

13.10, network-manager-openvpn 0.9.8.2-1ubuntu

[Thomas Hood (jdthood)]

Clemens: Your issue is not exactly the same as the one originally reported here (bug #1169437). The issue originally reported here is that provided nameserver *addresses* are not used. Your issue is that a provided *search domain name* is not used. The issues could be related, but it would be better to file a new bug report against network-manager-openvpn.

[Reece (reece)]

I have both symptoms discussed in this thread: DHCP push options are ignored and manually provided DNS servers are also ignored.

13.10, network-manager 0.9.8.0-0ubuntu22, openvpn 2.3.2-4ubuntu1

[Oscar Tiderman (oscar-tiderman)]

Sorry for not replying earlier but I actually got this working eventually. I'm on version:
$ NetworkManager --version
0.9.8.0

I do have dns=dnsmasq now and it's working if I set the Method to "Addresses only", manually specify the DNS servers and search domain. No issues anymore. I haven't tested if NM will use the DNS servers automatically and I cant really do that right now as I need working VPN for work, so I don't dare experiment with it. :) I will test further during christmas when I get some time off.

[hashstat (hashstat)]

I'm using NetworkManager 0.9.8.8 on Arch Linux and hitting a similar problem. It looks like it boils down to a problem with the temporary dnsmasq.conf file NetworkManager writes. I found the file by looking at the arguments passed to dnsmasq:

$ ps -C dnsmasq -ww --no-headers
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=400 --proxy-dnssec --conf-dir=/etc/NetworkManager/dnsmasq.d

$ cat /var/run/NetworkManager/dnsmasq.conf
# domains and addresses changed to protect the innocent
server=/example.com/10.101.109.80
server=/101.101.10.in-addr.arpa/10.101.109.80
server=/example.com/10.101.109.47
server=/101.101.10.in-addr.arpa/10.101.109.47
server=10.20.248.22
server=10.20.128.83

NetworkManager is prepending /domain/ strings to the returned DNS servers so that they are only used for the local domain. Remaining queries are falling to the bottom two servers, which are the original pre-VPN DNS servers, for which routes no longer exists causing DNS queries to anything other than example.com domain to fail. The file should really look like this:

$ cat /var/run/NetworkManager/dnsmasq.conf
server=10.101.109.80
server=10.101.109.47
server=10.20.248.22
server=10.20.128.83

Or even better, like this:

$ cat /var/run/NetworkManager/dnsmasq.conf
server=10.101.109.80
server=10.101.109.47

Manually configuring the DNS servers in NetworkManager results in the following:

$ cat /var/run/NetworkManager/dnsmasq.conf
server=/101.101.10.in-addr.arpa/10.101.109.80
server=/101.101.10.in-addr.arpa/10.101.109.47
server=10.20.248.22
server=10.20.128.83

This is still wrong. Prepending the domain should only be used when "Use this connection only for resources on its network" is checked.

Could those of you still having trouble on your Ubuntu systems please verify this?

[Thomas Hood (jdthood)]

As of Ubuntu 13.04 NetworkManager transmits nameserver information to dnsmasq over D-Bus, but I believe it configures dnsmasq in the same way.

> NetworkManager is prepending /domain/ strings to the returned DNS server
> [addresses] so that they are only used for the local domain.

NetworkManager prepends domain names to the DNS server addresses so that those addresses are only used for those domains, which are presumably the (non-public) domains of the VPN.

> Remaining queries are falling to the bottom two servers, which are the original pre-VPN DNS servers

Thas is by design.

> for which routes no longer exists causing DNS queries to anything other than example.com domain to fail.

That is a bug in the routing configuration. I suggest you investigate it. It could be a bug specific to Arch Linux or to your own system.

[Thomas Hood (jdthood)]

As I wrote in comment #11, I can't reproduce the behavior of nameserver addresses supplied by the OpenVPN server not being used correctly. It seems that if there was a bug in Ubuntu 12.10 then it has been fixed in more recent versions. In the ensuing four months no one has contradicted these findings so I am closing this report.

Along the way other issues have been reported. Either these have already been reported or they should be reported in separate tickets.

[Thomas Hood (jdthood)]

I mentioned above (comment #11) the problem that nmcli doesn't say anything about the OpenVPN connection. I have added a comment about this to bug #1161512 which may be related.

[Thomas Hood (jdthood)]

Clemens wrote in comment #13:

> My NetworkManager OpenVPN configuration had a domain listed under "Additional search domains".
> With dns=dnsmasq this resulted in the domains pushed from openvpn via 'push
> "dhcp-option DOMAIN mydomain"to be ignored.

I have just tried to reproduce this and cannot.

I have "dns=dnsmasq" and am initially not connect to a VPN. My resolv.conf looks like the following.

    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 127.0.1.1
    search myhomelandomain

I connect to my work VPN.

    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 127.0.1.1
    search mycorp.com myhomelandomain

I disconnect from the VPN. In the connection editor I add an "Additional search domain" and connect to the VPN.

    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 127.0.1.1
    search mycorp.com foobarbaz myhomelandomain

This is what I would expect. It seems that this bug is fixed too. Or there is a bug but it only manifests itself under certain circumstances. Clemens, if you still encounter this problem then please open a new bug report against network-manager-openvpn including details about the circumstances under which adding an "Additional search domain" causes the OpenVPN server supplied search domains to be omitted from the domain search list.

[Peg Asus (pegasus-prodescargas)]

I have Mint 13 (based on ubuntu 12.04), and comment out dns=dnsmasq works for me.

[Dean Reilly (dean-reilly)]

I'm experiencing the same bug with network-manager-vpnc.

[Daniel Weisser (daniel-weisser)]

And the same issue occurs wirh network-manager-openconnect

[Björn Lundgren (bjorn-erik-lundgren)]

I can confirm this is still an issue in Ubuntu 14.04 LTS using network-manager-openvpn.

disabling dnsmasq does not fix the issue

[Andreas Mahling (andreas-mahling)]

This is still an issue for me in 14.04.2 LTS

Package Versions
network-manager 0.9.8.8-0ubuntu7.1
network-manager-gnome 0.9.8.8-0ubuntu4.3
network-manager-openvpn 0.9.8.2-1ubuntu4
network-manager-openvpn-gnome 0.9.8.2-1ubuntu4

Disabling dns=dnsmasq does fix it

[Alexander Pankov (pianisteg)]

network-manager-openvpn-gnome
0.9.8.2-1ubuntu4

The same problems:
1. additional DNS from server are ignored
2. static DNS in NM (Network Manager) configuration is also ignored

So, I use usual console openvpn and it works fine.

BTW, how can I confugure NM not to save key passphrase and always ask it on connection?

[Adam Bolte (boltronics)]

hashstat (hashstat) wrote on 2013-12-24 in comment #17:
> NetworkManager is prepending /domain/ strings to the returned DNS servers so
> that they are only used for the local domain. Remaining queries are falling
> to the bottom two servers, which are the original pre-VPN DNS servers, for
> which routes no longer exists causing DNS queries to anything other than
> example.com domain to fail.

*This* appears to sum up the core issue perfectly.

Thomas Hood (jthood) wrote on 2013-12-24 in comment #18:
> NetworkManager prepends domain names to the DNS server addresses so that
> those addresses are only used for those domains, which are presumably the
> (non-public) domains of the VPN.

That is one huge assumption you're making, and I bet is in contrast to what many people are expecting. Anyone who uses a VPN provider such as AirVPN, PureVPN, etc to bypass censorship, government snooping, etc is going to need DNS data sent over the DNS link to thwart DNS leaks.

Thomas Hood (jthood) wrote on 2013-12-24 in comment #18:
> > Remaining queries are falling to the bottom two servers, which are the
> original pre-VPN DNS servers
>
> Thas is by design.

I put it to you that this design is defective if it does not consider this important use case.

[Thomas Hood (jdthood)]

> I put it to you that this design is defective if it does not consider this important use case.

If that is an important use case then of course it should be supported.

[Mikola (panamik)]

This bug seems old, but the discussion seems to go on even years after it's been marked as "Fixed".
This bug perfectly describes what started happening after upgrading to Ubuntu 15.10

/var/log/syslog says
Nov 24 01:07:46 XXX NetworkManager[777]: <info> Internal DNS: 10.0.0.1
Nov 24 01:07:46 XXX NetworkManager[777]: <info> Internal DNS: 10.0.0.2
Nov 24 01:07:46 XXX NetworkManager[777]: <info> DNS Domain: 'my-domain.xxx'

But
nmcli device show
shows that the DNS addresses mentioned above are *not* set for tun0

Commenting out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf does *not* fix the problem.

Specifying explicit DNS addresses in NetworkManager UI does *not* fix the problem.

Anybody knows of a more recent ticket for this problem? Or should this one be re-opened?

[Atmospherian (atmospherian)]

Running 15.10. Issue still persists. Commenting out dns=dnsmasq, and specifying additional DNS servers for VPN connection works for me.

ii network-manager 1.0.4-0ubuntu5.2 amd64 network management framework (daemon and userspace tools)
ii network-manager-gnome 0.9.10.1-0ubuntu7 amd64 network management framework (GNOME frontend)
ii network-manager-openvpn 0.9.10.0-1ubuntu2 amd64 network management framework (OpenVPN plugin core)
ii network-manager-openvpn-gnom 0.9.10.0-1ubuntu2 amd64 network management framework (OpenVPN plugin GNOME GUI)

[Alexander Hall (compuguy1088)]

Looks like 16.04 still has this issue. See bug https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1211110

[QkiZ (qkiz)]

Ubuntu 16.10 has still this issue.

[Thomas Hood (jdthood)]

QkiZ: Can you please provide details of the malfunction in your case?

[Martin Vysny (vyzivus)]

For me the DNS server is also not configured properly. I'm using Ubuntu 16.10, NetworkManager OpenVPN plugin, I have specified the DNS server in the IPV4 tab explicitly, yet it is apparently not used to resolve addresses. The DNS server itself works when asked from "host". The VPN's "Use this connection only for resources on its network" is unchecked.

[Thomas Hood (jdthood)]

You may be encountering a new problem. For background read this thread: https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/039350.html

[Vincent Gerris (vgerris)]

I also have this issue on 16.04 and commenting out the dnsmasq line does not always work.
For some reason /etc/resolv.conf does NOT contain the proper DNS entries, nor the search.
If I add that manually it even gets overriden every now and then it seems.
The save button on the network manager connection seems to do something too.

Anyway, this is just another annoying, crappy bug that makes Ubuntu less suitable for being used as a business laptop or developer machine.
This, percona package bugs, docker setup bugs with vpn, suspend bugs that freeze the machine and so on.

Ubuntu, Canonical, are you going to put some developer resources on fixing this?
I am happy to report bugs, but if they don get fixed, I might lose my interest.
thank you

[Thomas Hood (jdthood)]

Vincent: Which VPN client are you using?

[Vincenzo Pii (vinc-pii)]

I confirm that the bug is still present in Ubuntu 16.10 with OpenVPN 2.3.11.

If an additional DNS server is specified in the VPN IPv4 settings of NetworkManager, the name resolution is completely lost, unless the workaround of not-using dnsmasq is used (see http://askubuntu.com/questions/320921/having-dns-issues-when-connected-to-a-vpn-in-ubuntu-13-04).

[Even Larsen (even-2)]

I can confirm the issue with VPNC in Kubuntu 16.10 and vpnc 0.5.3r550-2build1. Comment out dnsmasq seems to work.

[Tiago Peralta (tperalta82)]

Add this patch to debian/patches/
Add it to series after Support-IPv6-Servers.patch
Add usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper-script
 to network-manager-openvpn.install

Rebuild package and test.

Although this is an ugly hack, it is working for me without modifying nsswitch and/or disabling dnsmasq.

The only thing I had to do, was to restart network-manager service

Rebooted as well, and seems to be working

Hope this helps everyone

[Alexander List (alexlist)]

I just observed this on a laptop using network-manager-vpnc-gnome.

The DNS is correctly received via vpnc and added to NetworkManager, but not being handled by dnsmasq.

nmcli -f IPv4 c show 820e9fe8-8ae6-4f69-ba85-402936c38852 |grep -i dns
ipv4.dns: AA.BB.CC.DD
ipv4.dns-search:
ipv4.dns-options: (default)
ipv4.ignore-auto-dns: yes

Disabling dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf seems to be a valid workaround.

[Tiago Peralta (tperalta82)]

NEvermind my previous patch, for some reason it works on a VM, and on my desktop, but not on my work laptop.... will have to investigate more

[icesmurf (icesmurf)]

cat << EOF > /etc/network/if-up.d/zz_restart_dnsmasq
#!/bin/bash
if [[ "\$IFACE" =~ [^tun] ]]; then
  sleep 2
  logger "** Restarting DNSMASQ process because funky network manager crappyness"
  kill \`cat /var/run/NetworkManager/dnsmasq.pid\`
fi
EOF

chmod 755 /etc/network/if-up.d/zz_restart_dnsmasq

Seems to consistently fix the issue for me, nasty hack but meh, works.

[Matteo Seclì (matteosecli)]

Still here in Ubuntu 16.04. icesmurf's solution (comment #44) works for me.

[Brett Randall (javabrett)]

LinuxMint Rebecca 17.1 (Ubuntu 14.04) NM 0.9.8.8 effected.

I am also using comment #44 workaround to kill dnsmasq.

[Keera Studios (keera-studios)]

Ubuntu 16.04 here.

Workaround #42 works for me, workaround #44 doesn't (restarted the service without rebooting).

Thanks!

[stuchl4n3k (stuchl4n3k)]

LinuxMint 18.1 Serena NM 1.2.6-0ubuntu0.16.04.1 affected.

Workaround in comment #44 works.

[Machiel (mvv588)]

I can confirm this issue in 16.04, removing resolvconf and commenting out dns=dnsmasq in NetworkManager.conf resolves the issue. I configured openVPN using NetworkManager.

[Ian Cameron (mkbloke)]

I have been running OpenVPN within 16.04 for some time and didn't have any DNS issues to begin with, even though I wasn't calling any scripts such as /etc/openvpn/update-resolv-conf via the up/down commands in my configuration; it just worked.

Something must have changed through updates however, as it stopped working. Upon investigation I found this thread and tried the solution in comment #44, which doesn't seem to work for me.

I have found that commenting out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf, as in comment #42 does not entirely work for me either. The problem I've found with this solution is as follows:

The original name servers (x2) as supplied via DHCP for the base network connection are pushed to /etc/resolv.conf via resolverconf. I start OpenVPN and use /etc/openvpn/update-resolv-conf to push the name servers supplied from the VPN server to /etc/resolv.conf. After that /etc/resolv.conf contains 3 nameserver entries. The first two entries are those supplied from the VPN server; the last one is a nameserver entry as supplied by the DHCP server for the base connection.

While you could use the connection in this state, it's clearly not great because there's the potential for DNS leakage. Also, it's quite possible you won't be able to contact the ISP's DNS servers anyway, because you're no longer sending queries from within their network.

I'm writing what I have found here for the benefit of other OpenVPN users with DNS issues, although it would appear that what I've found is a revolvconf issue rather than an OpenVPN one.

I have attached a modified update-resolv-conf file which works for me. It backs up and then deletes the NetworkManager connection before adding the OpenVPN supplied DNS information. Upon disconnection it deletes the OpenVPN entry and restores the NetworkManager information from the backup.

I hope this might be useful to some folk.