It's impossible to ignore VPN provided DNS servers

[Alkis Georgopoulos]

I have a desktop Precise installation with a normal dnsmasq installed, so I disabled the nm-spawned dnsmasq instance from NetworkManager.conf.

I create a VPN connection in Network Manager without specifying any DNS servers. When I connect to it, I get:
$ cat /var/run/dnsmasq/resolv.conf
nameserver 150.140.1.4
nameserver 150.140.1.25
nameserver 127.0.0.1
nameserver 194.63.238.4
nameserver 8.8.8.8

I want to ignore the first two entries which are provided by my VPN. So I go to the VPN connection editor and I declare DNS=127.0.0.1. But again I get the same /var/run/dnsmasq/resolv.conf, so my DNS server entry there is completely ignored by network-manager and/or resolvconf.

How can I tell Network Manager and/or resolvconf to ignore the DNS servers provided by my VPN connection?

[Mathieu Trudel-Lapierre (cyphermox)]

So the VPN connection is set to "addresses only"?

Setting Confirmed/Medium, since this would indeed be a bug in that case.

[Mathieu Trudel-Lapierre (cyphermox)]

I can't reproduce this on my system (though dns=dnsmasq is enabled, of course), with, or without a DNS being set, with the vpn configured as "addresses only". What I used was network-manager-vpnc.

[Alkis Georgopoulos (alkisg)]

> So the VPN connection is set to "addresses only"?

Yes.

> I can't reproduce this on my system (though dns=dnsmasq is enabled, of course), with, or without a DNS being set, with the vpn configured as "addresses only".

I removed the standalone dnsmasq and I'm using the nm-spawned one now. Same problem. Details:

# Everything fine so far:
$ ps -fC dnsmasq
UID PID PPID C STIME TTY TIME CMD
nobody 6982 1413 0 09:50 ? 00:00:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec

$ cat /run/nm-dns-dnsmasq.conf
server=10.160.31.1
server=194.63.238.4
server=8.8.8.8

# There's the problem - I don't want those DNS servers:
$ cat /run/resolvconf/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 150.140.1.4
nameserver 150.140.1.25
nameserver 127.0.0.1

# So, my DNS is broken:
$ dig +short www.launchpad.net
<no answer, the VPN DNS server is contacted and it doesn't know launchpad>

I also attach a screenshot of my VPN configuration. Is there any other info that I can provide? I can give VNC access to my PC, if desired (alkisg at irc.freenode.net, e.g. in #ltsp).

[Mathieu Trudel-Lapierre (cyphermox)]

We don't need VNC access.

So what I can think of here; it that I still don't know what kind of VPN you used. Was it vpnc, openvpn, openconnect or pptp? This is important because the behavior may change radically from one to the other.

What I tried was VPNC, seemed to work properly. I'll re-test shortly in case something happened to break my results. Could you also start the vpn plugin you use in debug mode (see http://live.gnome.org/NetworkManager/Debugging) and send me the logs via email? Mind that these logs may contain sensitive information like usernames and password, so you'll certainly want to review it first and "sanitize" it.

Unless you mean that you're not actually using the VPN plugins from NetworkManager and instead use the binaries directly? That's pretty much the one way I can think of for them to modify resolv.conf directly. Perhaps as another data point you could attach /run/resolvconf/interface/NetworkManager, that should contain everything that comes from NetworkManager.

[Alkis Georgopoulos (alkisg)]

> Could you also start the vpn plugin you use in debug mode
> and send me the logs via email?

I've mail you the output of:
$ sudo /usr/lib/NetworkManager/nm-pptp-service --debug
(it's a pptp connection)

But, there was one try today were I couldn't reproduce the problem anymore:

1. As I said, when I filed the bug report, I had the "real" dnsmasq running.
   The problem existed there.

2. At my next feedback I stopped the "real" dnsmasq and restarted
   network-manager so that it spawned its own instance. Problem was there too.

3. Today, when I booted I had both dnsmasq instances running,
   using --except-interfaces=lo and --bind-interfaces.
   On my first `nm-pptp-service --debug` try today
   I could *NOT* reproduce the problem.

4. Then I stopped the "real" dnsmasq and restarted network-manager.
   So I again had the nm-spawned dnsmasq like in (2).
   The problem happened again.

...so it's either a race condition, or something else that makes the problem not always reproducible.

alkisg@alkis:~$ cat /run/resolvconf/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 150.140.1.4
nameserver 150.140.1.25
nameserver 10.160.31.1

alkisg@alkis:~$ cat /run/resolvconf/interface/NetworkManager
nameserver 10.160.31.1
nameserver 194.63.238.4
nameserver 8.8.8.8

alkisg@alkis:~$ ping www.launchpad.net
ping: unknown host www.launchpad.net

[Mathieu Trudel-Lapierre (cyphermox)]

Thanks.

Can you confirm exactly which DNS servers are the "bad" ones? I thought it was:
nameserver 150.140.1.4
nameserver 150.140.1.25

But those don't appear in NetworkManager's interface file for resolvconf, which makes it look like it may be a bug directly in n-m-pptp's way of getting DNS information from pptp (how the process gets spawned, which makes pptp update DNS itself), or n-m-pptp is updating DNS independently from NM. Reassigning to network-manager-pptp.

[Mathieu Trudel-Lapierre (cyphermox)]

Clearly a bug in either how n-m-pptp spawns the vpn process, or how it goes out to update DNS. Regardless, then this may need to be reassigned if pptp doesn't provide a way to avoid updating DNS directly.

[Alkis Georgopoulos (alkisg)]

> Can you confirm exactly which DNS servers are the "bad" ones? I thought it was:
nameserver 150.140.1.4
nameserver 150.140.1.25

Yup, those are the bad ones and the ones I want to ignore.
And while they don't show up in /run/resolvconf/interface/NetworkManager, they do in /run/resolvconf/resolv.conf, and they are the ones that answer all my DNS requests (and fail).
They also don't show up in the network-manager connection properties nor in nm-tool.

[Mathieu Trudel-Lapierre (cyphermox)]

Seems like this might also affect PPPoE connections; I'm still investigating though :)

[Mathieu Trudel-Lapierre (cyphermox)]

New tag: nm-ppp-dns-settings

I can't really mark other bugs related to this as duplicates yet, because I'm not certain enough that it's really the same issue; it's possible this may be in pptp or ppp too; so for now I'll use this to track down all the similar symptoms bugs like this one.

[James E. Blair (corvus)]

Could this be because network-manager-pptp always sets the "usepeerdns" flag to pppd (regardless of any settings the user may have made in network manager)? See this line:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/network-manager-pptp/quantal/view/head:/src/nm-pptp-service.c#L851

[Alkis Georgopoulos (alkisg)]

I tried deleting /etc/ppp/ip-up.d/0000usepeerdns but it didn't help, my /var/run/dnsmasq/resolv.conf still contained the VPN-provided DNS servers.

[Thomas Hood (jdthood)]

Hi Alkis,

Do you still have this problem? Or was it fixed in resolvconf 1.67ubuntu2:

resolvconf (1.67ubuntu2) quantal; urgency=low
  [...]
  * Update ppp hooks to also exit when passed
    /org/freedesktop/NetworkManager/PPP/* (LP: #994575)

[Alkis Georgopoulos (alkisg)]

Hi Thomas,
sorry, I'm only using LTS releases so I'm still on 12.04 here:

$ dpkg-query -W resolvconf
resolvconf 1.63ubuntu16

[Thomas Hood (jdthood)]

If you have a chance to test a more recent resolvconf release, please report back with your findings.

[Alkis Georgopoulos (alkisg)]

Thomas thank, this appears to be working fine with resolvconf 1.69ubuntu1 on Trusty, so I'm marking it as a duplicate of the bug you referenced.