We use Juniper Network Connect to connect to the VPN. This works reasonably well on Ubuntu, but on Ubuntu 12.04LTS and later, it causes an ocassional problem with /etc/resolv.conf.

Presenting symptoms

After disconnecting from the VPN, webpages load very slowly. Trying to make an SSH connection to somewhere, at first seems like the network is unavaialble, but after ~30 seconds it connects. After making an SSH connection, there's no delay in transfering text back and forth. (which may seem strange, because while connecting, it acts like the network connection is extremely slow)

How to confirm this is your issue

  1. confirm your system uses 'resolvconf'
  2. confirm that your resolv.conf isn't a symlink
  3. if your system uses 'resolvconf', but your /etc/resolv.conf is not a symlink, then your problem is the one described on this page

Background

In Ubuntu 12.04LTS, Ubuntu switched to using resolvconf (article, filelist) to manage the /etc/resolv.conf file. A particular feature of the tool is that it symlinks /etc/resolv.conf ⇒ /run/resolvconf/resolv.conf

If that symlink is ever broken (if other software overwrites it with a normal file), then resolvconf stops working. The symlink has to be manually fixed, and rebooting doesn't help.

While Juniper NetworkConnect is connected, it overwrites /etc/resolv.conf with a non-symlinked file. When NetworkConnect disconnects, it restores /etc/resolv.conf to its previous state — a symlink to /run/resolvconf/resolv.conf. When NetworkConnect runs normally, everything works fine.

The problem

Rarely, NetworkConnect doesn't restore /etc/resolv.conf to a symlink when it disconnects. I haven't yet pinned down why or how often this occurs. Possibly it's because NetworkConnect crashes.

Solution #1

Fix it manually:
  1. sudo ln -sf /run/resolvconf/resolv.conf /etc/resolv.conf
  2. reboot

Solution #2

Modify the system so it automatically self-corrects.

(TODO: figure out how to rebuild /run/resolvconf/resolv.conf without having to reboot; figure out an appropriate place to run our fix_resolvconf script from, so it gets triggered sometime shortly after NetworkConnect closes... or, if nothing else, when a network interface is bounced)