Ubuntu 9.04 (Jaunty Jackalope), vpnc, and resolvconf

The environment

• Ubuntu 9.04 Jaunty Jackalope
• vpnc 0.5.3
• resolvconf 1.43

The problem

Connecting to a cisco vpn device with vpnc on jaunty. If you use vpnc and vpnc-disconnect to bring the connection up and down, all works fine. If you leave the connection idle too long and are disconnected from the other end, the resolv.conf is not always updated. This is a problem because, when you do a DNS lookup in a browser you’ll experience delays, the DNS servers from your vpn connection are no longer available.

The easiest way to check this is to login to your vpn and check the contents of /etc/resolv.conf. For example, before you log in, your resolv.conf may look something like this (only the IPs have been changed to protect the innocent).

# cat /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 192.168.0.1
nameserver 192.168.0.2
search yourdomain.com

After connecting, you’ll see a different resolv.conf.

# cat /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 192.168.50.1
nameserver 192.168.50.2
nameserver 192.168.0.1
nameserver 192.168.0.2
search yourVPNdomain.com

It would be easier to see with real IPs, but the vpnc daemon adds two more servers, and sometimes changes or adds the search domain. This is great—the first DNS servers you will lookup against on your vpn connection are those for the vpn, which makes it easier to resolve IPs on the corporate network.

The trouble begins when the connection times out. vpnc is very good about cleaning up its routing tables, but for some reason it does not always fix the resolv.conf as it should. This is because vpnc is not telling the resolvconf package to remove the config for the tunnel device.

Interlude: resolvconf

resolvconf is a package used primarily by the system to manage the name server information in /etc/resolv.conf dynamically. It replaces the old static resolv.conf file. Before moving to jaunty, I was using 8.04 Hardy Heron, and still do at work. The addition of resolvconf seems to coincide with the rise of network-manager for managing network interfaces in Linux. They work great when they work, but when problems arose, the old methods were much less confusing.

Networking utilities wishing to make use of resolvconf will drop a file into the /etc/resolvconf/run/interfaces directory. resolvconf will then combine this with other base files (located in /etc/resolvconf/resolv.conf.d) to create /etc/resolvconf/run/resolv.conf. This file is symbolically linked to /etc/resolv.conf.

So to make things clear, resolvconf will:

• Take the base config files from /etc/resolvconf/resolv.conf.d:

  # ls -al
  total 16
  drwxr-xr-x 2 root root 4096 Apr 26 23:18 .
  drwxr-xr-x 6 root root 4096 Apr 26 23:18 ..
  -rw-r--r-- 1 root root    0 Aug  9  2006 base
  -rw-r--r-- 1 root root  151 Aug  9  2006 head
  -rw-r--r-- 1 root root  116 Apr 26 22:06 original
  -rw-r--r-- 1 root root    0 Apr 26 23:18 tail

• Combine them with the information for each interface in /etc/resolvconf/run/interface;

  # ls -al
  total 16
  drwxr-xr-x 2 root root 4096 Jun 15 22:10 .
  drwxr-xr-x 3 root root 4096 Jun 15 22:48 ..
  -rw-r--r-- 1 root root   87 Jun 10 23:04 NetworkManager
  -rw-r--r-- 1 root root   91 May 23 21:41 eth0

• Output one happy DNS configuration in /etc/resolvconf/run . . .

  # cat 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 192.168.0.1
  nameserver 192.168.0.2
  search yourdomain.com

•  . . . which is a symbolic link to /etc/resolv.conf

  # ls -al /etc/resolv.conf
  lrwxrwxrwx 1 root root 31 Apr 29 16:06 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf

There you go—clear as mud.

End Interlude

So you have been disconnected from the vpn. If you look in /etc/resolvconf/run/interface, you will see a file left around from the session. For example, if your vpn connection is interface tun0 (which mine always is), there will be this file.

ls -al /etc/resolvconf/run/interface
-rw-r--r-- 1 root root   91 Jun 15 21:41 tun0

All this information just to get to . . .

The workaround

The workaround for this is simple. resolvconf can be used from the command line to add, remove, or update this information, on the fly. In this case, we want to remove an interface. You’ll need to know what the interface for your vpn tunnel is. tun0 is the most common with vpnc, but if you are not sure, you can consult the /etc/resolvconf/run/interface directory as shown above and check the file name. Once you have that, the solution is simple.

# sudo /sbin/resolvconf -d tun0

Replace tun0 with your interface if it’s different.

Scheduled workaround

It occurred to me that if I need to do this, it’s annoying to do it by hand every time. Since vpnc is not cleaning up after itself, it makes sense to do the cleanup automatically. We can do this using a cron job. For ease of use, I will add this to /etc/crontab file as root, because the vpnc scripts need to be run as root to work.

sudo vi /etc/crontab

Note: As we all know I prefer vi from the command line, but you can use any old editor that you want, providing you are running it with root credentials so that you can write to the crontab file.

Now you need to add this line at the bottom of the file (allowances must be made here for paths, this works on my Ubuntu system). For the sake or argument, we’ll run this every 10 minutes.

*/10 * * * * root if [ -e /etc/resolvconf/run/interface/tun0 -a "`pidof vpnc`" == "" ] ; then /sbin/resolvconf -d tun0; fi

What this does, is checks to see if the tun0 file exists, and if it does, it will run the command to remove it, which will then regenerate the resolv.conf and remove the bad DNS information.

Epilogue

I know this was a lot of ‘splaining for a simple one-line fix, but having worked through this from scratch, I thought it might interest someone to see the process.

There is an open bug on this issue, and you can find it here: “vpnc does not always call resolvconf -d on termination. This bug has been around for a couple of versions now. The vpnc project home page also states in its known bug list, “vpnc looses [sic] connection with some targets, even before the rekey-timer expires most probably due bugs with keepalive, dead-peer-detection or something else,” which may be the cause of this issue, because if the session does not die cleanly, it may also not clean up properly.

I have downloaded the source and straced my last session, so I may try my hand at fixing it myself. An initial look at it yielded no results, but I have not worked with C in many, many years, so it will take time. If you would like to help fix this bug check the bug report or contact the maintainer.

Till next time.