Free Software user-mode VPN client

• the IP address of the server's VPN gateway
• the VPN group name
• the VPN group password

The tricky part is the group password. Simply asking an existing user of the VPN client software what group password they're using is impractical, because the password is stored in an encrypted form within their configuration, so they will not usually be aware of what it is. This guide tries to explain how to locate the required configuration files within an already-configured system (usually running a Microsoft operating system), and how to recover the VPN group password from them.

Some reasons to use vpnc rather than the Cisco VPN client

The major advantage vpnc has (as an open-source VPN client) over the proprietary Cisco implementation is that you don't need to do anything special if you change your kernel. This is because vpnc runs in user-space, in contrast to the Cisco vpn implementation, which depends on a proprietary binary-only kernel module. There is usually only extremely limited community support is available for binary-only kernel modules.

In general, tainted kernels tend to be viewed with suspicion, especially if they're involved in bug reports to the Red Hat and SuSE developers. As you can imagine, clean kernels are much more acceptable as starting points for an investigation of any kernel problem.

Get the source for vpnc

Build the software

Once the above libgcrypt11 and libgpg-error sources have been built, you're ready to build vpnc as follows.

Configuration

     /etc/CiscoSystemsVPNClient/Profiles

Start your VPN connection

Unsolved puzzles

The INVALID_PAYLOAD_TYPE message

When connecting to some Cisco VPN servers, vpnc may give the following error message:

Connection dropping after 8 hours

Firewall considerations

iptables setup

TCP window scaling considerations

Graphical User Interfaces

vpnc on 64-bit platform: x86_64

Alternatives to vpnc

A couple of other ways of setting up VPN tunnels are good to know about, e.g. ipsec-tools and the VPN support recently added to OpenSSH.

Open-source user-mode VPN client

This guide is to help Linux users configure client access to a VPN gateway managed by a Cisco3000 VPN Concentrator, when the VPN administrator has chosen to deploy clients using a group password. It has been written to be useful in actually getting the Linux client VPN software vpnc set up and interoperating with the Cisco3000 VPN server system.

The configuration details you'll be looking for include the IP address of the VPN gateway, and the VPN group name and the VPN group password. Simply asking an existing user of the VPN client software for the group password is impractical, because the password is stored in an encrypted form within their configuration, so they will not usually be aware of what it is.

This document explains how to locate the required configuration files and recover the VPN group password from them, once you have access to a configured Cisco VPN client system (e.g. on a Microsoft Windows system).

1. Get the source

The major advantage of this open-source VPN client implementation project is that it doesn't require you to rebuild it if you change your kernel, because it runs in user-space. This is not to say that there would be anything wrong with a GPL kernel module implementation, but the Cisco vpn implementation depends on a binary-only kernel module for which only extremely limited community support is available.

Kernel modules, especially those that depend on binary-only object code (i.e. code to which you do not have the source-code), tend to be difficult to build in such a way that they load cleanly into the enterprise kernels from Red Hat and SuSE without "tainting" the kernel.

Tainted kernels tend to be viewed with suspicion, especially if they're involved in bug reports to the Red Hat and SuSE developers. As you can imagine, clean kernels are much more acceptable as starting points for an investigation of any kernel problem.

Get the source for the user-mode VPN client "vpnc" from here: http://www.unix-ag.uni-kl.de/~massar/vpnc

At this time, the latest download is:

http://www.unix-ag.uni-kl.de/~massar/vpnc/vpnc-0.2-rm+zomb.1.tar.gz

The latest development code is available in the Subversion repository:

http://svn.unix-ag.uni-kl.de/vpnc

For building vpnc, you'll also need version 1.1.90 or later of the GNU Libgcrypt Cryptographic library: http://www.gnu.org/directory/security/libgcrypt.html Version 1.2.0 (stable) was released on April 15, 2004: ftp://ftp.gnupg.org/gcrypt/libgcrypt/README ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.0.tar.gz ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.0.tar.gz.sig

Libgcrypt also needs libgpg-error, which will someday be at: ftp://ftp.gnupg.org/gcrypt/libgpg-error/ but since libgpg-error has not yet reached 1.0, it's currently only available as an "alpha" release from: ftp://ftp.gnupg.org/gcrypt/alpha/libgpg-error/ The latest as of Jul 25, 2004, seems to be version 0.7: ftp://ftp.gnupg.org/gcrypt/alpha/libgpg-error/libgpg-error-0.7.tar.gz ftp://ftp.gnupg.org/gcrypt/alpha/libgpg-error/libgpg-error-0.7.tar.gz.sig

2. Build the software

     tar zxvf vpnc-0.2-rm+zomb.1.tar.gz
     cd vpnc-0.2-rm+zomb.1
     make

For those lucky folks running Debian, vpnc is available as a pre-built binary package, so you can save yourself quite some time by just using:

     apt-get install vpnc
     cd /dev && mkdir net
     cd /dev/net && mknod tun c 10 200

For SuSE, see Section 10 "Builds for Various Linux Distributions" below. You also need to make sure your kernel has the tunneling option either built in or as a module. Most commercial distributions supply the module, look for:

     /lib/modules/`uname -r`/kernel/drivers/net/tun.o

If you don't find it, then when you're configuring your kernel, look in the section "Universal TUN/TAP device driver support". Usually, it's sufficient to just make sure that your kernel .config has:

     CONFIG_TUN=m

This configuration turns on TUN support, which provides packet reception and transmission for user space programs. It can be viewed as a simple Point-to-Point or Ethernet device, which instead of receiving packets from a physical media, receives them from a user space program and instead of sending packets via physical media, writes them to the user space program.

If you have the kernel sources installed, you can read more about this in

   /usr/src/linux/Documentation/networking/tuntap.txt

3. Configuration

At the time of this writing, the Cisco VPN client software needs a steering file containing all of its configuration information. The steering files are usually named according to the location of the gateway where the VPN server is running.

On a linux installation, the steering files reside in the directory:

     /etc/CiscoSystemsVPNClient/Profiles

On linux, the steering files have names ending with the ".pcf" suffix.

In a Microsoft Windows installation, the steering files reside in the following directory, and the steering files also have names ending with the ".pcf" suffix.

    C:\Program Files\Cisco Systems\VPN Client\Profiles

When looking through the steering files, with a view to creating the configuration file for "vpnc", you need to take note of the following lines. Only the labels of the lines are shown here:

   Host=
   BackupServer=
   GroupName=
   enc_GroupPwd=
   Username=
   UserPassword=

Any other lines are irrelevant.

The only file that you need to edit to configure vpnc is /etc/vpnc.conf

The "vpnc" configuration file is much shorter than the Cisco VPN client's steering files. You'll need lines as follows in your /etc/vpnc.conf file. Note that capitalization matters in the /etc/vpnc.conf file.

   IKE DH Group dh2
   IPSec gateway README_1
   IPSec ID README_2
   IPSec secret README_3
   Xauth username README_4
   Xauth password README_5
   Interface name tun0
   Application version Cisco Systems VPN Client 3.7.3 (A):Linux

The IKE DH Group is the internet key exchange implementation to use. Diffie-Hellman is an asymmetric cipher, chosen by setting this to dh2. Asymmetric ciphers are currently too slow to use for encrypting the vpn traffic itself, so they are only used to share the key to use for the symmetric cipher (usually DES) used to encrypt the vpn traffic. The "vpnc" project implements around six or so key exchange mechanisms.

For README_1, put whatever you noted down from either the "Host=" or the "BackupServer=" fields of the .pcf file earlier.

For README_2, put whatever you noted down from the "GroupName=" field of the .pcf file earlier. This is the name of the VPN group.

For README_3, you need to decode the hex contents of the "enc_GroupPwd=" field you noted down from the .pcf file earlier, to retrieve the "plaintext secret" corresponding to the contents of the "GroupName=" field.

If you want to do the password decoding job yourself, use "ltrace" on the Cisco VPN client version 4.0.3.B-k9, as follows:

First make sure the steering file is in place and is readable:

     ls -l /etc/CiscoSystemsVPNClient/Profiles/EXAMPLE.pcf 

then run:

     ltrace -i ./vpnclient connect EXAMPLE 2>&1 | fgrep 805ac57

Note: Don't include the '.pcf' extension, when giving the steering file name to use to the Cisco vpnclient program. See below for info on downloading the Cisco VPN client itself to use with this method, as the specific version will be needed to match the ltrace. The above method depends on a vulnerability in the Cisco VPN client reported to Cisco by Karl Gaissmaier, University of Ulm, Germany: http://www.cisco.com/warp/public/707/cisco-sn-20040415-grppass.shtml Anyone in possession of the Group Passwords will have the ability to either hijack a connection from a valid user, or pose as a VPN head end for stealing user names and passwords.

If you don't have "ltrace" installed, you can still use "strace":

   strace -s 500 -o $HOME/secret/vpnclient.strace.out vpnclient connect EXAMPLE

although you'll need to search for the password string manually because strace doesn't seem to provide a way of displaying the offsets. The "-s" parameter is suggested to increase the displayed length of the contents of the string buffers containing the password. The default is only 32.

If you're in a hurry, a web page provides a utility to do the job of decoding the "enc_GroupPwd=" group password field: http://www.unix-ag.uni-kl.de/~massar/bin/cisco-decode Obviously, don't connect to that web page from within the network you're trying to connect to over VPN, as otherwise the site could log the generated passwords as well as the network originating the decoding request, and put two and two together.

For README_4, Xauth username, put your normal PPP user login. For README_5, Xauth password, you can put your normal PPP password here, but it's not recommended.

Note: any config line info that is missing should be prompted for when you use vpnc-connect. It's best not to put the PPP password into the /etc/vpnc.conf configuration file.

4. Start

To connect, simply issue, from the command line as root, the command:

     vpnc-connect

Thats about it. A netstat -nr will show that your default route is now via tun0 which will connect you through to the internal network.

To come back out to normal networking simply issue 'vpnc-disconnect' and all will be returned to normal.

5. Unsolved problems

5.1 INVALID_PAYLOAD_TYPE

The above error will occur when connecting using the .pcf files from a Microsoft Windows installation of the Cisco VPN client. Instead, use the .pcf files from the linux Cisco VPN client. I haven't debugged far enough into why this error occurs to understand it, any hints would be much appreciated.

5.1 Connection dropping after 8 hours

When using vpnc, the connection will always be dropped after it has been up between 6 and 8 hours, when rekeying occurs. See the section "Alternatives to vpnc" for discussion.

6. Firewall considerations

If you are running vpnc from a machine with a personal firewall configured on its external interface (eth0 or ppp0), for example if you are running SuSE 9.0 with SuSEfirewall2-3.1-206 configured for the external eth0 interface, then in some situations incoming packets required for setting up the vpn tunnel connection might get dropped. As a workaround, I've found that using a second machine (running for example, SuSE SLES-9 and SuSEfirewall2-3.1-310.4) configured with two network interfaces, one for the internal private network, and the second for connection to the external untrusted network, and with the firewall configured to perform "Masquerading", allows the machine on the private network to always successfully connect over the vpn. Enabling masquerading is bad for security -- please note that it is more secure to communicate via proxies to the untrusted network than to use masquerading. Such a configuration may be simple to use, but remember that once the vpn tunnel is enabled, then unless you have the correct iptables setup (see next section), your private network could become part of the network on the far side of the vpn. Also, the use of masquerading in any case is not recommended because it involves enabling routing on your firewall.

On Debian, the package "guarddog" allows the firewall configuration to be customized to include the ISAKMP and ESP protocols, which "vpnc" needs. The way to enable communication over these protocols is to add a checkmark in both of the following, for the "Internet" zone:

  "Network" -> "ISAKMP - Internet security key management"
  "Network" -> "ESP - Encapsulating Security Protocol"

7. iptables setup

On Linux, "vpnc" can be configured to achieve the same goal as the Cisco VPN client (that is, to disable local LAN access while the VPN tunnel is active). This explanation is thanks to Alessandro Suardi and Maurice Massar, and took place on the vpnc-devel mailing list.

Adding the following section to the end of your "vpnc-connect" script is sufficient to block access to and from the LAN, while still allowing traffic via the VPN tunnel. If you are already using some iptables rules, remember to save them using "iptables-save" before running this script, so that you can use "iptables-restore" within your "vpnc-disconnect" to restore access to your LAN. There are some drawbacks with "iptables-restore", see for example: http://www.faqs.org/docs/iptables/drawbackswithrestore.html

# Flush the previous rules
iptables -F
#
# INPUT chain:
#   Allow ESP protocol
#   Allow UDP on isakmp, NAT, NAT-T
#   Allow traffic from the loopback device and the VPN tunnel
#   Reject everything else with "filtered" diagnostic messages
#
iptables -A INPUT -j ACCEPT -s $VPNGATEWAY -p esp
iptables -A INPUT -j ACCEPT -s $VPNGATEWAY -p udp -m multiport --sports isakmp,4500,10000
iptables -A INPUT -j ACCEPT -i lo
iptables -A INPUT -j ACCEPT -i $TUNDEV
# Enable LOG if you need to for debugging purposes:
#iptables -A INPUT -j LOG
iptables -A INPUT -j REJECT --reject-with icmp-admin-prohibited
#
# FORWARD chain: disable IP forwarding
#
iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited
#
# OUTPUT chain:
#   See the INPUT chain settings above, and adjust the parameters 
#   appropriately to allow traffic in the opposite direction.
#
iptables -A OUTPUT -j ACCEPT -d $VPNGATEWAY -p esp
iptables -A OUTPUT -j ACCEPT -d $VPNGATEWAY -p udp -m multiport --dports isakmp,4500,10000
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A OUTPUT -j ACCEPT -o $TUNDEV
iptables -A OUTPUT -j REJECT --reject-with icmp-admin-prohibited

8. TCP window scaling considerations

If you prefer to use your own DSL link directly to connect to resources on the internet, rather than going via your organization's http proxies when you are connected using vpnc, you may find that the TCP window scaling feature of the Linux 2.6.7 and later kernels can interfere with such direct connections.

You can disable the new TCP window scaling feature by doing (as root):

  echo "0" > /proc/sys/net/ipv4/tcp_window_scaling
  echo "0" > /proc/sys/net/ipv4/tcp_moderate_rcvbuf

If you prefer to make this change permanent, you can use the sysctl utility:

  sysctl -w net.ipv4.tcp_window_scaling=0
  sysctl -w net.ipv4.tcp_moderate_rcvbuf=0 

or edit the file /etc/sysctl.conf and add the following:

net.ipv4.tcp_window_scaling=0 
net.ipv4.tcp_moderate_rcvbuf=0 

The recent 2.6.7 kernel's TCP changes are only exposing a pre-existing problem with a large number of poor/broken firewall implementations. These are clueless firewall implementations that strip or alter the TCP options. When the options are modified, TCP gets busted. The reason this matters now, is that when the linux kernel proposes a new window scaling, it quite sensibly expects that the other side will receive the same initial SYN request that it actually sent. If there is a clueless firewall in the middle that corrupts or strips it, then the window we send is not correctly scaled, and the result is that the other side thinks that there is not really enough space to send. The current proliferation of these clueless firewall implementations resulted in a proposal on the linux kernel mailing list by Stephen Hemminger, where he proposes a patch that will avoid sending window scaling that is big enough to break in these cases unless the tcp_rmem has already been increased. The aim is to keep the default configuration from blowing in a corrupt world. For more details on the lively ensuing discussion of Stephen's patch, search for the following string in the archive pages listed below:

  "[PATCH] fix tcp_default_win_scale." 

Jul 1 to Jul 7, 2004 lkml archives: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0407.0/index.html Jul 8 to Jul 15, 2004 lkml archives: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0407.1/index.html There's an entertaining explanation from James Janssen, a Gentoo user, here: http://www.apu.edu/imt/awg/node/view/101

9. Graphical User Interfaces

There is a GUI for vpnc for the K desktop environment "KDE":

http://home.gna.org/kvpnc/

10. Builds for Various Linux Distributions

SuSE builds

RPM builds of vpnc for SuSE 9.0 and SuSE 9.1 done by "hs-harz" are here:

http://www2.hs-harz.de/~u15119/linux/index.html http://www2.hs-harz.de/~u15119/linux/kvpnc/index_en.html

11. vpnc on 64-bit platform: x86_64

Zach Brown describes the issues he found with vpnc on the x86_64 platform: http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2005-January/000448.html He also provides a patch that may help get you going.

The Cisco VPN client binaries

The specific version of the Cisco VPN client to use for retrieving the Group Password from the encrypted "enc_GroupPwd" field, can be downloaded from:

wget http://www.uni-konstanz.de/RZ/wlan/ipsec/software/cisco-vpnclient-4.0.3/vpnclient-linux-4.0.3.B-k9.tar.gz wget http://www.uni-konstanz.de/RZ/wlan/ipsec/software/cisco-vpnclient-4.0.3/vpnclient-linux-4.0.3.B-readme.txt

This version also works with 2.6 linux kernel.

Alternatives to vpnc: ipsec-tools

ipsec-tools

http://ipsec-tools.sourceforge.net/ http://www.netbsd.org/Documentation/network/ipsec/rasvpn.html

On Wed Apr 6 2005, Joerg Mayer wrote: http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2005-April/000587.html If you are using Linux and already have SuSE 9.3, then your choice shouldn't be vpnc, it should be ipsec-tools that come with SuSE 9.3 The ipsec-tools and the kernel ipsec implementation can do certificates and hybrid stuff. When I compared vpnc to ipsec-tools (just looking over what each project says in their documentation), then ipsec-tools is the thing many people want to use. I remember that there are one or two things that vpnc does better, but ipsec-tools have certificates and also supports generating of a new sa after the lifetime of the old sa has expired. While I really like the idea of vpnc, it looks like ipsec-tools is not only catching up but in most cases already surpasses vpnc - with the big disadvantage that ipsec-tools are tied to only a few platforms. It also looks like ipsec-tools is being actively developed with more than just one patch per month or so as is currently the case with vpnc.

Using ipsec-tools may be a way to get around the problem with vpnc where the connection is dropped after it has been up between 6 and 8 hours when rekeying occurs.

-- PeterKnaggs - 06 Feb 2006