[Bug 1046154] Re: Can't resolve OpenVPN DNS while using a 3G connection with resolvconf installed

[Launchpad Bug Tracker]

*** This bug is a duplicate of bug 994575 ***
    https://bugs.launchpad.net/bugs/994575

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 <stgraber at ubuntu.com>   Thu, 25 Oct 2012 13:59:30 +0200

** Changed in: resolvconf (Ubuntu)
       Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1046154

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

Status in “resolvconf” package in Ubuntu:
  Fix Released

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1046154/+subscriptions