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

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.

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.

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.

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.

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.

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.

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!!
-jatin

PYTHIAN®, LOVE YOUR DATA®, and ADMINISCOPE® are trademarks and registered trademarks owned by Pythian in North America and certain other countries, and are valuable assets of our company. Other brands, product and company names on this website may be trademarks or registered trademarks of Pythian or of third parties. Use of trademarks without permission is strictly prohibited.