- Ubuntu 9.04 Jaunty Jackalope
- vpnc 0.5.3
- resolvconf 1.43
Connecting to a cisco vpn device with vpnc on jaunty. If you use
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
# 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.
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
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
So to make things clear, resolvconf will:
- Take the base config files from
# 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
# 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
# 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.
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 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
tun0 with your interface if it’s different.
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
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.
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.