/etc/ppp/ip-up.d/000resolvconf should "exit 0" if pppd was run by NM, since NM will register the nameserver addresses itself

After doing a bit of research, I found that dnsmasq usage is controlled via the "dns=dnsmasq" line in /etc/NetworkManager/NetworkManager.conf. I commented out this line and restarted, and can confirm that this fixed my problems with DNS resolution on the VPN.

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

Also an issue for me as I recently did a clean install of 12.04. I have several OpenVPN servers, and they worked perfectly fine under 11.04 and 11.10 but as soon I installed 12.04, I could no longer access the internet through them....I could connect fine, and ping individual IPs, which made me narrow it down to a DNS issue. Appearently, there were major changes to DNS stuff in 12.04 so I am not surprised it is currently broken....

More information about the changes can be found linked below, but basically, my temporary fix is to disable a new addon in 12.04 called "dnsmasq":

http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

Linux damir-ubuntu 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Since upgrade to 12.04 I have encountered the same problem here with DNS name resolution while connected to VPN. DNS name resolution worked fine under prior Ubuntu version 11.10 but stopped after upgrade.

DNS servers and search domains are specified in VPN settings. Host names on the VPN network do not resolve even when fully qualified. It's necessary to use the IP addresses while connected to VPN to RDP into machines. Running "host {machine name} {dns server}" from terminal works to resolve names to IP's.

I have tried disabling dnsmasq in /etc/NetworkManager/NetworkManager.conf and vice versus. These changes do not seem to have any affect. Any workaround besides using IP addresses?

Brian: That commenting out "dns=dnsmasq" did not solve your problem indicates that the problem is not the same as Jeff Licquia's. His problem was probably bug #1003842 in dnsmasq.

Brian: Did you reboot or restart network-manager after editing its configuration file? If not, please do so and try again.

Thomas: Yes, tried restarting network-manager but used UI 'enable networking' checkmark to disable and re-enable. Would this be consistent with using command line to restart service?

I have reviewed the resolv.conf file before and after connecting and the problem appears to be that the VPN DNS servers are not getting added to the file although search domains are getting added. The VPN settings are specified as automatic vpn addresses only through network manager ui. DNS servers and search domains are both entered as comma-delimited entries into the ui settings. If I add the nameserver entries manually to resolv.conf and test host command in term then it works. Of course resolv.conf is overwritten by network manager later.

I can hard-code the entries in head of /etc/resolvconf/resolv.conf.d/ directory but this is probably not a good long-term solution. Is this a bug in dnsmasq or resolvconf or do I have a broken component in my system? dnsmasq v2.59-4 and resolvconf 1.63ubuntu14 shows installed via synaptic.

Brian Marks wrote:
> Yes, tried restarting network-manager but used UI 'enable
> networking' checkmark to disable and re-enable.  Would this be
> consistent with using command line to restart service?

Using the indicator to dis-"Enable Networking" and re-"Enable Networking" does not restart the NetworkManager daemon, which is necessary for changes to /etc/NetworkManager/NetworkManager.conf to become effective. You have to open a Terminal and do "sudo restart network-manager" or reboot.

> I have reviewed the resolv.conf file before and after connecting and the
> problem appears to be that the VPN DNS servers are not getting added to
> the file although search domains are getting added.

Well, when NM is in "dns=dnsmasq" mode you will only see "nameserver 127.0.0.1" in /etc/resolv.conf. No further addresses will be added there. The addresses of the upstream nameservers including the VPN ones should appear in /var/run/nm-dns-dnsmasq.conf instead.

If you comment out "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf and restart network-manager then up to three upstream nameserver addresses will be included directly in /etc/resolv.conf and there will be no /var/run/nm-dns-dnsmasq.conf file.

If, in either case, you don't see your VPN nameserver addresses in the appropriate file then there is something wrong with, e.g., your DHCP server configuration, DHCP client, ....

But I suspect that you have also hit #1003842 and that you will find that everything works after you restart network-manager with "dns=dnsmasq" commented out.

Okay, Thomas, I've done some more testing based on your response in #9. I'd be interested to hear your opinion on what may be going on. Here's the results...

TESTING WITH DNSMASQ DISABLED
I disabled dnsmasq in /etc/NetworkManager/NetworkManager.conf by commenting out the dnsmasq setting like:
#dns=dnsmasq

Then restarted networkmanager using the command:
sudo restart network-manager

After that, connected to VPN with DNS servers and search domains specified in VPN settings. /etc/resolv.conf does not contain the VPN DNS servers. The only one listed is 127.0.0.1. The search domains are listed though. The VPN DNS servers are in /var/run/resolvconf/interface/NetworkManager and /var/run/resolvconf/interface/ppp0. Running host command without specifying VPN DNS still does not resolve - "Host {myhost} not found: 3(NXDOMAIN)".

TESTING WITH DNSMASQ ENABLED
Re-enabled dnsmasq in /etc/NetworkManager/NetworkManager.conf. "dns=dnsmasq"
Restarted networkmanager

"nameserver 127.0.0.1" only DNS server in /etc/resolv.conf as expected.
/var/run/nm-dns-dnsmasq.conf file does not exist. <-- This could be the problem.
Any ideas on why this file is not being created? Could it be a permission issue?

Should I be posting this in bug #1003842 instead? Is what I'm doing helpful?

Thomas:
After doing some more research I found what was causing the VPN DNS resolution in my specific scenario. Based on some comments in bug #959037, I found that the bind9 service was installed and running. After uninstalling bind9 using synaptic and restarting the networkmanager service, name to IP resolution began working. Also the file /var/run/nm-dns-dnsmasq.conf showed up and was being correctly populated.

Here's what my config files look like now with VPN connection (edited to protect company security). Based on your prior response, I'm confused as to why resolv.conf has more than just the loopback IP. It works, though.

/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 {first vpn dns IP addr in network manager}
nameserver {second vpn dns IP addr in network manager}
nameserver 127.0.0.1
search {first vpn search domain in network manager} {second vpn search domain in network manager}

/var/run/nm-dns-dnsmasq.conf:
server={first vpn dns IP addr in network manager}
server={second vpn dns IP addr in network manager}

Hi Brian

> Is what I'm doing helpful?

Yes, very helpful. You describe exactly what you did and what the result was.

It's especially useful to know what one of the causes of the problem was. :)

Bind9. I'm not surprised.

In #9 I wrote "when NM is in 'dns=dnsmasq' mode you will only see 'nameserver 127.0.0.1' in /etc/resolv.conf." That wasn't entirely true and you have proved it! What's true is that when all interfaces are managed exclusively by NM and dns=dnsmasq then 127.0.0.1 will be the only address listed.

That you have additional addresses listed in /etc/resolv.conf indicates that something is still wrong. You wrote earlier:

> The VPN DNS servers are in /var/run/resolvconf/interface/NetworkManager and /var/run/resolvconf/interface/ppp0.

There is something wrong here. The addresses should not be included in *both* these files.

Can you please reboot and reconnect to the vpn and do "ls -l /var/run/resolvconf/interface/" again? Also post the contents of each file in that directory.

If you still get both /var/run/resolvconf/interface/NetworkManager and /var/run/resolvconf/interface/ppp0 then there is a bug somewhere.

How do you bring up the VPN? With NM? OpenVPN or PPTP? Which vpn package or daemon?

Thomas:

After rebooting here's the output you requested when connected via VPN...

ls -l /var/run/resolvconf/interface/:
-rw-r--r-- 1 root root 59 Jun 16 00:42 NetworkManager
-rw-r--r-- 1 root root 48 Jun 16 00:42 ppp0

NetworkManager:
search {vpn search domain #1} {vpn search domain #2}
nameserver 127.0.0.1

ppp0:
nameserver {vpn dns server #1}
nameserver {vpn dns server #2}

/etc/resolv.conf:
nameserver {vpn dns server #1}
nameserver {vpn dns server #2}
nameserver 127.0.0.1
search {vpn search domain #1} {vpn search domain #2}

I connect to VPN through NM. Both OpenVPN and PPTP are installed according to synaptic, but it looks like pptp is the daemon connected to NetworkManager based on ps output below:

ps -ef | grep pptp
root 5598 1209 0 01:02 ? 00:00:00 /usr/lib/NetworkManager/nm-pptp-service
root 5600 5598 0 01:02 ? 00:00:00 /usr/sbin/pppd pty /usr/sbin/pptp {vpn gateway IP addr} --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-5598 ipparam nm-pptp-service-5598 nodetach lock usepeerdns noipdefault nodefaultroute noauth user vendpkr9 refuse-eap refuse-pap refuse-chap require-mppe mppe-stateful lcp-echo-failure 0 lcp-echo-interval 0 plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so
root 5602 5600 0 01:02 ? 00:00:00 sh -c /usr/sbin/pptp {vpn gateway IP addr} --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-5598
root 5603 5602 0 01:02 ? 00:00:00 /usr/sbin/pptp {vpn gateway IP addr} --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-5598
root 5611 1 0 01:02 ? 00:00:00 /usr/sbin/pptp {vpn gateway IP addr} --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-5598

Hi, Brian. As Jeff Licquia's issue is already covered by #1003842 and you have posted information here that indicates the existence of another real bug, I am taking the liberty of retitling this report to address _your_ bug.

NetworkManager is registering the VPN nameserver addresses under the name "NetworkManager" but pppd, started by nm-pptpt-service, also registers those addresses, under the name 'ppp0'.

The registration by pppd should be eliminated. The hook script /etc/ppp/ip-up.d/000resolvconf (included in the resolvconf package) will need to be changed so that it "exit 0"s if it sees that NetworkManager is the one running pppd.

Reassigned to resolvconf to reflect the fact that this report is now about the bug described in comment #14.

@Brian: Once this bug gets fixed in a future resolvconf release you will find that resolv.conf contains only "nameserver 127.0.0.1". For now it contains also the VPN nameserver addresses. If that doesn't cause you trouble I'd say leave the configuration alone. If it does cause you trouble then put "exit 0" near the top of /etc/ppp/ip-up.d/000resolvconf.

nm-pptp-service (as seen in the file nm-pptp-service.c) starts pppd with the option

    ipparam nm-pptp-service-%d

where nm-pptp-service's PID is filled in at "%d". The argument of the ipparam option is passed on to ip-up and ip-down scripts as the 6th parameter. So I propose that /etc/ppp/ip-up.d/000resolvconf and /etc/ppp/ip-down.d/000resolvconf no-op in the presence of a sixth argument matching the glob pattern "nm-pptp-service-*".

@Brian: Please try this out for me.

In /etc/ppp/ip-up.d/000resolvconf add the following line right after the line "[ -x /sbin/resolvconf ] || exit 0".

    case "$6" in (nm-pptp-service-*) exit 0 ;; esac

After adding this, disconnect VPN. Make sure the file /run/resolvconf/interface/ppp0 is now gone. Connect VPN again. Do "ls -l /var/run/resolvconf/interface/". If all is well the "ppp0" file is not there and the VPN nameserver addresses are not present in /etc/resolv.conf, but are present in /var/run/nm-dns-dnsmasq.conf.

@Tom: I made that change and tested it and everything checked out like you expected. When connected to VPN ppp0 file did not exist, and VPN nameserver addresses were not present in /etc/resolv.conf but were present in /var/run/nm-dns-dnsmasq.conf. Hope that helps. Let me know if there's anything else I can do, but it looks like one bugs down.

According to comment #18, this issue is resolved? Using that code, can we patch up the issue ourselves locally without having to build any packages or?

Also, I believe "dnsmasq does not update nameserver info after network change" was a better title for this bug as it is a common issue and that is ultimately what occurs.

@Damir: The package will be patched as described in #18 but you can apply the patch by hand yourself; you don't have to build anything.

@Damir: The original big is covered by #1003842.

Here's the patch.

The attachment "Patch to fix resolvconf's pppd hook scripts such that they don't call resolvconf if pppd was called by nm-pptp-service" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

The patch I submitted in #23 fixes the bug insofar as it changes resolvconf's pppd hook script so that it doesn't create an unneeded "ppp0" record when pppd has been run by nm-pptp-service. However, it has the shortcoming that the hook script fails to delete such a record created by an earlier version of the script. The result is that if resolvconf is upgraded while pppd is running under nm-pptp-service then the unwanted record remains in the database even after the PPP interface has been brought down. Not good. The problem disappears on reboot, but still.

The attached patch (skip-resolvconf-under-pptp_20120618th1.diff) fixes this. Patched with this patch instead of the previous one, the hook script creates the record with a different name (e.g., 'ppp0.pppd') from the name used before ('ppp0') and, on down, unconditionally deletes the old record.

The new name follows conventions whereas the old name did not, so the name change is in itself an improvement.

(The name change will also be made in Debian eventually. I'm not sure about the special casing of nm-pptp-service yet ---- I will have to look at Debian's n-m.)

Yep, Debian's n-m is the same, so the patch will be applied to Debian resolvconf as well. It will be included in 1.67.

Fixed in Debian resolvconf 1.67 which was released today.

This bug was fixed in the package resolvconf - 1.67ubuntu1

---------------
resolvconf (1.67ubuntu1) quantal; urgency=low

  * Merge from Debian. Remaining changes:
    (LP: #994575, LP: #999337, LP: #1012355)
    - Make /etc/resolv.conf a relative symlink so that it works when
      setting up chroots.
    - Instead of throwing an error that aborts the upgrade when
      /etc/resolv.conf is immutable, pop a debconf error message to let the
      user know what's happening, then clear the immutable flag and continue
      with the installation. LP: #989585.
    - debian/config, debian/templates, debian/postinst: if we don't know that
      /etc/resolv.conf was being dynamically managed before install (in at
      least some cases), link the original contents of /etc/resolv.conf to
      /etc/resolvconf/resolv.conf.d/tail so that any statically configured
      nameservers aren't lost. LP: #923685.
    - Use an upstart job instead of sysvinit script.
    - Pre-Depend on the /run-providing version of initscripts instead of
      depending, so that the preinst does the right thing when creating
      /run/resolvconf/interfaces instead of getting clobbered later by a bind
      mount on initscripts upgrade. LP: #922491.
    - Completely drop the standard_run_subdirs_created helper function from
      debian/postinst, since it serves no purpose here.
    - postinst: Set resolvconf/linkify-resolvconf to false after initial
      conversion, ensuring upgrades won't convert /etc/resolv.conf to
      a symlink if the user manually converted it back to plain text.
      (LP: #922677)
    - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf
      symlink is set, so the init script can actually start (since it expects
      /etc/resolv.conf to be a symlink).
    - Eliminate all references to /etc/resolvconf/run. This should all be done
      directly in /run, there is no reason to support making any of this
      configurable with a symlink since we already have a versioned dependency
      on the version of initscripts that introduces the /run transition.
    - Also remove debian/triggers to avoid needlessly calling resolvconf's
      postinst. (LP: #931335)
 -- Stephane Graber <email address hidden> Fri, 22 Jun 2012 17:29:50 -0400

Hello Jeff, or anyone else affected,

Accepted 1.63ubuntu15 into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/1.63ubuntu15/1.63ubuntu15 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Jeff, or anyone else affected,

Accepted resolvconf into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/resolvconf/1.63ubuntu15 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Thomas: did you actually test that change?

During verification here, a standard 3G ppp connection has $6 as the DBUS path (/org/freedesktop/NetworkManager/PPP/X) and not nm-pptp-service-* as is suggested by the patch.

So it sounds like the patch is partial at best (only working for pptp) or just not working at all.

Marking verification-failed for now.

I installed the proposed changes and performed a VPN (PPTP) connection a Windows 2008 Server. I initiated the connection via the Unity Network GUI (Right-click network icon, VPN -> MyVPN Connection). The proposed changes worked for me (Ubuntu 12.04 x64 desktop). The resolv.conf file is no longer being populated with DNS servers obtained via the VPN connection.

Moving to verification-done as it actually solves the original usecase (pptp), the fix should however be extended to support any kind of ppp connection.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package resolvconf - 1.63ubuntu15

---------------
resolvconf (1.63ubuntu15) precise-proposed; urgency=low

  * Change resolvconf's pppd hook script such that it does not call
    resolvconf if pppd was run by nm-pptp-service. (LP: #994575)
 -- Stephane Graber <email address hidden> Wed, 18 Jul 2012 16:07:01 -0400

Re-opening this bug as the fix was only partial, we need to change the condition to:
nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*

This bug was fixed in the package resolvconf - 1.67ubuntu2

---------------
resolvconf (1.67ubuntu2) quantal; urgency=low

  * Apply patch by MarianoAbsatz to remove remaining reference to
    /etc/resolvconf/run (LP: #1035076)
  * Update ppp hooks to also exit when passed
    /org/freedesktop/NetworkManager/PPP/* (LP: #994575)
 -- Stephane Graber <email address hidden> Fri, 07 Sep 2012 18:01:59 -0400

Hello Jeff, or anyone else affected,

Accepted into precise-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Thanks for the update, it works great in Ubuntu 12.04! I changed the tag from verification-needed to verification-done :)

> * Update ppp hooks to also exit when passed
 > /org/freedesktop/NetworkManager/PPP/* (LP: #994575)

This has been backported to Debian and will appear in 1.68.

This bug was fixed in the package resolvconf - 1.63ubuntu16

---------------
resolvconf (1.63ubuntu16) precise-proposed; urgency=low

  * Update ppp hooks to also exit when passed
    /org/freedesktop/NetworkManager/PPP/* (LP: #994575)
 -- Stephane Graber <email address hidden> Fri, 07 Sep 2012 18:03:35 -0400

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.