Can't resolve OpenVPN DNS while using a 3G connection with resolvconf installed

[Ignacio Huerta]

Ubuntu version: fresh install of Ubuntu 12.04.1 LTS 64 bits (3.2.0-29-generic)
Resolvconf package version: 1.63ubuntu15

What I expected to happen: Connect through 3G (bluetooth DUN), connect to a OpenVPN and be able to resolve the internal domain names to access some servers.

What happened instead: I can't resolve internal hostnames.

Additional information: It only breaks when connecting through 3G. When connecting through Wifi/Cable it works perfectly.

Workaround: Uninstalling the package resolvconf seems to solve the problem.

Other users probably affected: http://mobilesociety.typepad.com/mobile_life/2012/07/ubuntu-1204-the-network-manager-3g-internet-and-vpn.html

I've looked at other bug reports and tried other solutions:
* #922578. Removing "resolvconf" is a workaround that works, but I imagine this is resolvconf bug and there must be a more elegant solution.
* #994575. This looks related, but I already have the patched version and it didn't help.
* #924013. I have already checked that my OpenVPN servers are pushing the right information (DNS + DOMAIN) back to the client.

With resolvconf installed: cat /etc/resolv.conf:
    nameserver 195.81.137.130
    nameserver 195.81.155.194
    nameserver 192.168.163.200
    search dummy.intranet

With resolvconf uninstalled: cat /etc/resolv.conf
    domain dummy.intranet
    search dummy.intranet
    nameserver 127.0.0.1

Please tell me if you need any additional information

[Steve Langasek (vorlon)]

I'm confused by your "with resolvconf" configuration. Are you using NetworkManager? Do you have NetworkManager configured to not use dnsmasq, which it will do by default?

I'm also confused as to why the *without* resolvconf config shows a nameserver of 127.0.0.1. That doesn't look like a value that should be pushed by the openvpn server. What are the DNS and DOMAIN values being pushed by the server?

The openvpn package ships a script, /etc/openvpn/update-resolv-conf, which is meant to integrate with resolvconf; but it must be added to your openvpn .conf file in order to be used (as described at the top of the script). Have you done this? If *not*, then I don't see anything else in the openvpn package which handles updates to /etc/resolv.conf at all.

[Ignacio Huerta (iox8)]

Yes Steve, I'm using the default Ubuntu configuration: I'm using network manager and dnsmasq.

The server is pushing this information (I replaced the client company name with "dummy"):
    push "dhcp-option DNS 192.168.163.200"
    push "dhcp-option DOMAIN dummy.intranet"

About the script you mentioned (/etc/openvpn/update-resolv-conf), how can I tell network manager to use this script?

[Thomas Hood (jdthood)]

Hi there iox.

Your system is probably misconfigured in one or more ways.

If you are using NetworkManager and dnsmasq and resolvconf then /etc/resolv.conf will list only "nameserver 127.0.0.1". But you say that you are using NetworkManager and dnsmasq and with resolvconf installed you had

    nameserver 195.81.137.130
    nameserver 195.81.155.194
    nameserver 192.168.163.200
    search dummy.intranet

Here 127.0.0.1 is not listed. It looks as if dnsmasq is not really activated. The internal nameserver is, I take it, 192.168.163.200. This should be listed first, not last.

If you are using NetworkManager to establish openvpn connections then you don't need to change any scripts. NetworkManager receives the nameserver addresses from openvpn and submits them to resolvconf.

Your original problem may have been due to bug #1003842. The fact that the connection type (and thus speed) was a factor makes it more probable that #1003842 was the problem.

In your initial attempts to solve the original problem it is possible that you changed the NetworkManager, resolvconf, etc., configurations. These should be returned to their original state. The workaround for #1003842 is to comment out the line

    dns=dnsmasq

in /etc/NetworkManager/NetworkManager.conf.

[Ignacio Huerta (iox8)]

Hi Thomas,

Thanks again for your help! I did comment out once "dns=dnsmasq" in
/etc/NetworkManager/NetworkManager.conf. But I rebooted, tested, it didn't help,
and I left it the way it was again. I just checked and this is my file:

ignacio@cherokee:~$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
dns=dnsmasq

[ifupdown]
managed=false

I have decided to reproduce the problem again from scratch: I installed resolvconf again, rebooted, connected to 3G

1. This is my /etc/resolv.conf before connecting to the VPN (resolvconf installed):
# 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 195.81.137.130
nameserver 195.81.155.194
nameserver 127.0.0.1

2. And after connecting to the VPN (resolvconf installed - resolving fails):
# 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 195.81.137.130
nameserver 195.81.155.194
nameserver 127.0.0.1
search dummy.intranet

3. This is my /etc/resolv.conf before connecting to the VPN (resolvconf uninstalled):
# Generated by NetworkManager
nameserver 127.0.0.1

4. And after connecting to the VPN (resolvconf uninstalled - resolving works):
# Generated by NetworkManager
domain ecotec.intranet
search ecotec.intranet
nameserver 127.0.0.1

Oh, this is not nice: I am getting different the same results now. I must have messed up something
last time.

[Thomas Hood (jdthood)]

> 1. This is my /etc/resolv.conf before connecting to the VPN (resolvconf installed):
> # 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 195.81.137.130
> nameserver 195.81.155.194
> nameserver 127.0.0.1

This is wrong and most probably the cause of your problem. There should not be entries before "nameserver 127.0.0.1".

We need to figure out where those entries are coming from.

Please reproduce this case (i.e., install resolvconf; reboot; connect to Internet but not to VPN) and run the following commands in a terminal and post the output:

    ls -l /etc/resolv.conf
    ls -l /run/resolvconf
    cat /run/resolvconf/resolv.conf
    ls -l /run/resolvconf/interface
    for F in /run/resolvconf/interface/* ; do echo === $F === ; cat $F ; done
    ls -l /etc/resolvconf/resolv.conf.d
    for F in /etc/resolvconf/resolv.conf.d/* ; do echo === $F === ; cat $F ; done
    cat /etc/resolvconf/interface-order
    cat /etc/NetworkManager/NetworkManager.conf
    cat /etc/network/interfaces
    dpkg -l resolvconf network-manager

[Ignacio Huerta (iox8)]

Hi Thomas,

Thanks again for your efforts! I just followed your instructions and I'm attaching a text file with the result of the commands.

Regards, Ignacio

[Ignacio Huerta (iox8)]

I forgot to tell you: the two "offending DNS" (195.81.137.130 and 195.81.155.194) are the DNS of my 3G network provider (Simyo). I suspect that the Bluetooth DUN internet connection is not setting the DNS the way it should.

[Thomas Hood (jdthood)]

This may be a duplicate of or a variant of bug #994575. More later.

[Thomas Hood (jdthood)]

@iox: Please do the following to help us debug this.

First, post the output of.

    md5sum /etc/ppp/ip-up.d/000resolvconf

Second, open /etc/ppp/ip-up.d/000resolvconf in an editor and add the following line to the top of the file, just after the comments at the top.

echo "The sixth argument is: $6" | logger -t 000resolvconf

Now deconfigure all interfaces and configure the 3G network interface again. In /var/log/syslog you should see a line that looks like

    Sep 7 20:38:46 tenerife 000resolvconf: The sixth argument is: xyzzy

Please post that line here.

[Ignacio Huerta (iox8)]

Ok course Thomas :). First the md5sum:

    ignacio@cherokee:~$ md5sum /etc/ppp/ip-up.d/000resolvconf
    a3a76c831a5a96917c9b293598901f72 /etc/ppp/ip-up.d/000resolvconf

And now the line from the syslog:
    Sep 7 22:54:07 cherokee 000resolvconf: The sixth argument is: /org/freedesktop/NetworkManager/PPP/0

I don't know if it's relevant, but the PPP number increases every time I turn off an on my
bluetooth. This is the log from the second time connecting:
    Sep 7 22:55:48 cherokee 000resolvconf: The sixth argument is: /org/freedesktop/NetworkManager/PPP/1

[Thomas Hood (jdthood)]

@iox: Thanks. It's possible that there are multiple problems on your system but at least we have found one bug: /etc/ppp/ip-up.d/000resolvconf was registering the nameserver addresses for your 3G connection but when NetworkManager establishes the connection only it should do the registering. And I am happy to be able to say that the bug has been fixed in resolvconf 1.67ubuntu2, released by Stéphane Graber yesterday. Please upgrade to this new release of resolvconf and test again. If resolving still doesn't work properly then we'll do some more debugging.

[Thomas Hood (jdthood)]

@iox: Instead of upgrading resolvconf (recommended) you can alternatively, for now, just apply this patch both to /etc/ppp/ip-up.d/000resolvconf and to /etc/ppp/ip-down.d/000resolvconf

--- old 2012-09-08 12:34:42.836054460 +0200
+++ 000resolvconf 2012-09-08 12:35:19.768055317 +0200
@@ -11,7 +11,7 @@
 [ -x /sbin/resolvconf ] || exit 0

 case "$6" in
- nm-pptp-service-*)
+ nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
     # NetworkManager handles it
     exit 0
     ;;

[Ignacio Huerta (iox8)]

Hi Thomas!

Thank you very much, I just tested the resolvconf package from the proposed repository and it works great. It's been a pleasure debugging a bug with you. I'm going to comment in the other bug too, so they have confirmation it's working.

A note for users looking to update their resolvconf: the working version in 12.04 proposed seems to be 1.63ubuntu16 instead of 1.67ubuntu2 (this one probably belongs to 12.10).

[Thomas Hood (jdthood)]

@iox: I am glad to hear that resolving is now working correctly on your machine. Thanks for your help in squashing this resolvconf bug!

[Launchpad Janitor (janitor)]

This bug was fixed in the package resolvconf - 1.68ubuntu1

---------------
resolvconf (1.68ubuntu1) raring; urgency=low

  * Merge from Debian. Remaining changes:
    - 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)

resolvconf (1.68) unstable; urgency=low

  * [1527598] Add sk.po. Thanks to Slavko (Closes: #683672)
  * [7713764] Update resolvconf's ppp hook also to exit when passed
    /org/freedesktop/NetworkManager/PPP/* (LP: #994575, LP: #1046154)
 -- Stephane Graber <email address hidden> Thu, 25 Oct 2012 13:59:30 +0200