Ubuntu 9.04 (Jaunty Jackalope), vpnc, and resolvconf

Posted in: Technical Track

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)
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)

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)
    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.


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.

Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

Brad is just a guy, you know? I fought my way up in the world tooth-and-nail. Starting in broadcasting and music to travel to computer support to development of mid size xBase programs. Finally I settled into the wonderful world of system administration where I have honed my skills doing many diverse tasks. I started using Solaris in the mid 80's and built my first Linux system on a 386 using 30-some floppy disks and never looked back.

9 Comments. Leave new

Thanks for wrap this up. I have been using vpn-client for years. After moving to Jaunty and vpnc, I also found this problem. I haven’t tried to find a solution yet.


is there something like ubuntu netbook remix but without the sucking ?

Brad Hudson
June 21, 2009 8:06 pm

weather, not that I know of. I do not personally use a netbook as I find them too small to be of use to me. My wife does, however. For her purposes linpus linux on the Acer Aspire does everything she needs. Since linpus is based on fedora you have the ability to install any packages that are offered in the fedora repositories, and you always have the option of installing apps from source if needed.

There’s lots of distro’s aimed at the netbook market now, so it all depends on what you want and need.


I discovered in Jaunty that if you don’t disconnect from vpnc w/ vpnc-disconnect and logout. Your resolv.conf will remain unchanged. In this case I blame the NetworkManager for not being able to restore the resolv.conf file.

Re-connecting with vpnc using an IP address for the gateway and disconnecting with vpnc-disconnect, cleaned up the resolv.conf file in my case.

Thank you Brad for the explanation.


wow this was the only explaination which worked for me. After hours of trying to fix why firefox was ‘looking up’ for so long (tried the usual networkdnsdisableipv6 set to true) ,I figured it was something to do with resolv.conf.
Resolv.conf had my corp dns entries and if i removed them things worked fine. Finally found this thread and realized those copr dns entries were left from an uncleanly terminated vpnc session. Fired up vpnc again and did a proper vpnc-disconnect and things were back to normal.
Its strange how even a reboot does not fix the leftover corp dns entries in resolv.conf.
Thanks for the great explanation it really helped a lot!!


I encountered this problem. This article made sense and the solution worked for me. Great job! ’nuff said.



Great write up, worked fine, cheers.


Thanks for detailed explanation! I’ve faced this issue also


Interfaces in Ubuntu 12.04 are found at “/run/resolvconf/interface”. So to list interfaces for Ubuntu 12.04 type in:
> ls -al /run/resolvconf/interface


Leave a Reply

Your email address will not be published. Required fields are marked *