This document details how to make your Debian machine work with a Cisco VPN
Concentrator (occaisionally these may be called a PIX something-or-other) using
vpnc, with resolvconf to make handling resolv.conf updates
easier. It's
pretty much assumed that you know all the passwords necessary to use the Cisco
box, but this may not always be the case. Cisco VPN client software uses a
login/passwd pair to access the Concentrator. This login/passwd pair is
separate from the creditials used to authenticate the user, and can be left in
a hashed form in a config file, given out by your sysadmin. Unfortunately,
vpnc cannot use the hashed password, and I don't
know how to reverse the
hashing (though it is possible - they aren't using a one-way hash), so you'll
have to bother your sysadmin to find out what the password really is.
As usual, this guide pertains primarily to Debian Linux users. Other Linux users, and *BSD users are, unfortunately, screwed.
This guide is no longer being actively maintained. If you find an error,
please let me know and I'll update the site. However, as my use of
vpnc has greatly declined recently, I'm no longer keeping this
page up to date myself.
Recently my employer deployed a campus-wide 802.11b network, with connectivity
in most buildings, common areas, and a few popular eating holes. Unfortunately,
the powers that be require some sort of authenticated VPN system to access a
working router - either Cisco's VPNclient (which is closed-source, proprietary,
X86-specific, and buggy) or PPTP (which is a Micro$oft protocol, has
questionable crypto, and is proprietary). Initially, I used various Linux
PPTP clients; for more details, see my notes.
Of course, those wacky Debian people had added a new program, vpnc,
by the time I had made everything work correctly. Figures.
VPNC is an open-source client specifically designed to work with Cisco's VPN Concentrator, and it doesn't require any kernel modifications, or packages from wierd APT servers, or patching. Obviously, I started using that. A little while later, I wrote down my notes from that, so random other folk could use it as well. Enjoy!
VPNC's upstream source seems to just include one program, vpnc,
that takes a series of arcane options and builds a tunnel to your Cisco VPN
Concentrator. No kernel patches are required; at most, you may just need to
add generic tap and tunnel support to your kernel (though, since I use Debian's
packaged kernels, I didn't need to do this - it's already in there).
The Debian package provides a few extra scripts, vpnc-connect and
vpnc-disconnect that automate everything. Put all the VPN
concentrator's options in one config file, and everything will come up when
you run the vpnc-connect script (and, of course, come down when
you run vpnc-disconnect). This package is in unstable now, and
should be a part of the upcoming Sarge (aka Debian 3.1) release. To get
started, do this:
apt-get install vpnc
Then write a config file. vpnc-connect configs live in
/etc/vpnc. The default config is
/etc/vpnc/default.conf. Below is the config I use to connect to
the wireless service at Purdue University (aka PAL, the
Purdue Air Link). I keep
this in /etc/vpnc/PAL.conf:
Interface name pal IKE DH Group dh2 Perfect Forward Secrecy nopfs IPSec gateway vpn.airlink.purdue.edu IPSec ID vpnusers IPSec secret vpnusers
Obviously, replace vpnusers in the sample above with the VPN
Concentrator credentials at your site.
To bring up a tunnel, just run vpnc-connect [. Without
arguments, vpnc-connect loads the config in
/etc/vpnc/default.conf. To load PAL.conf instead,
run vpnc-connect PAL as root.
Pretty simple, eh? See why I stopped using PPTP?
Ever find yourself joining multiple networks simultaneously, and having to
manually edit /etc/resolv.conf to reflect the "proper" name
server for whatever network is used for most of your traffic? You might, if
you use a VPN tunnel. For example, you may DHCP at home, get a DNS from your
local broadband provider, then use a VPN to reach the office - where you need
another DNS server configured in /etc/resolv.conf, to see machines
on your employer's internal network. Wouldn't it be nice if there were a
Debian package to manage resolv.conf, and select the right DNS
depending on which networks are available? Well, there is. That'd be the
resolvconf package. Go, install it:
apt-get install resolvconf
Yes, you want resolvconf to manage /etc/resolv.conf for
you. Yes, you want it to create a symlink for /etc/resolv.conf
for you - it should be linked to /etc/resolvconf/run/resolv.conf
when the package is installed. Keep this in mind when answering debconf
questions.
So, once resolvconf is installed you'll have an
/etc/resolvconf directory. You'll want to edit
interface-order; it's a config file that lists interfaces in
their "preferred" order. As nameservers are identified to the system
(via DHCP responses, or vpnc tunnels being created) they are
sorted based on the interface they use and that interface's order in this file.
A nameserver using an interface near the top of this file will always be near
the top of your resolv.conf. Simple. If you use vpnc,
you'll want to add the tunnel interface to interface-order.
Mine, including the interface for Purdue's wireless network (as defined in
PAL.conf in the previous section) is:
# interface-order(5) lo.inet* lo.dnsmasq lo.pdnsd lo* tun* tap* pal eth* ath* wlan* ppp* *
The other file you'll probably want to edit is
/etc/resolvconf/resolv.conf.d/base. This lists options that
should always be in your resolv.conf. Yes, resolvconf is
smart enough to merge any search list you provide here with whatever a DHCP
server provides. Mine is:
search fmepnet.org options ndots:2
Incidentally, the "options ndots:2" line means that a hostname
must have at least two dots (.) to be considered a fully qualified
domain; with this option, ping bob.cx will try to ping
bob.cx.fmepnet.org, if it exists, rather than pinging a server
in the Christmas Islands.
So, that's all there is to it. Set up those few files, and your list of nameservers will be quietly, correctly updated any time you DHCP or set up a VPN tunnel. Nice. Gotta hand it to those Debian folks, don't ya?