Up: Wireless

Installing Cisco VPN5000 on Linux

James F. Carter <jimc@math.ucla.edu>, 2002-01-01

UCLA Campus Telecommunications Services have installed a IEEE 802.11b wireless network as a test campaign. Transport off the net is controlled through the Cisco VPN5000 client, server and hardware. Thus, it is necessary for Linux users to install the client and make it work.

Versions and Equipment

The VPN client provided by Bruin Online is version 5.1.5. My configuration: SuSE 7.3 Linux, with a self-compiled kernel 2.4.16. Dell Inspiron 4100 with Dell Truemobile 1150 Mini-PCI (internal) wireless NIC. (The hardware is by Agere and uses the Harris-Intersil Prism II chipset with Lucent-Agere firmware.) Installation of the client was uneventful for Windows XP, and it essentially worked out of the box (once I found an access point that was working). As for Linux . . .

VPN Client Functions

The VPN client has three functions. First, only people who can give authentication credentials (BOLID and password) can get their packets off the wireless net. Second, the outgoing and incoming packets are encrypted at the third protocol layer, so they are useless to eavesdroppers. Third, the packets' addresses are translated so remote machines believe they originated on the UCLA internal network, which may be used by some services for host-based authentication or (in)security. While the focus here is on wireless networking, the VPN client can be used from anywhere.

The VPN client first interacts with a RADIUS server to prove to it that a UCLA person (you) is operating the client. Having received an authentication ticket, it then opens a TCP connection to the VPN server. It intercepts all packets to your net interface, encrypts them, and sends them to the server. The server assigns you an IP address on its output interface, translates your IP address to the assigned one (IP masquerade or NAT), and transmits the packets from there. Returning packets are encrypted and delivered to the VPN client, which places them on your net bus as if received locally.

Beware of that last point: even if you have a residential gateway with a firewall, the packets are inside it already. You should activate a firewall in the local machine. Most distros these days include an iptables or ipchains script to do this, of varying aggressiveness. The same point applies to Microsoft Windows. WinXP includes a ``black hole'' firewall. I have not done the research to determine how to make this work with the VPN5000 client, and I know I've had problems mounting shared directories with the firewall engaged, but a serious Windows user should learn how to protect himself using that firewall, or a third party product,

The VPN functions are vpn_control, open_tunnel, close_tunnel, scep_app. Now, what do they do? (Only ``useful'' arguments are shown; see the Users Guide for the rest.)

open_tunnel [-d device] [-n] vpn_server user@ucla.edu
Opens the VPN tunnel. -d is required if the device is other than eth0, which is the case on my system. -n (NAT workaround) is required if you use Network Address Translation (IP Masquerade), which is common on residential intranets, i.e. those using the ``citizens' band'' IP addresses of 192.168.0.0/16 or 10.0.0.0/8. Do not use -n with the BOL wireless network.
close_tunnel
Finds and kills the running open_tunnel process. It's OK to use control-C or the kill command.
vpn_control
Don't know, not in Users Guide. According to the builtin help, you can enable or disable the VPN module, and turn on debug output.
scep_app
Requests a root or user certificate from a server. BOL does not use this program.

Compiling and Installing the VPN Client

I obtained vpn-5000-linux-5.1.5-3des-k9.tar.Z from http://www.bol.ucla.edu/wireless/download. It unpacks into a directory called ./COMPvpn (no version number).

I read the extremely detailed and clear instructions for compiling and installing the client :-) It is recommended that users obtain the Users Guide from Cisco. The matching PDF file contained only the index; an obsolete version of the complete users guide as PDF was located in a web search: "Cisco VPN 5000 Client User Guide for Linux and Solaris" v3.3.2 dated 2000-05. See also the Release Notes.

In the source directory, I executed ./vpn_install with these parameters:
Question Answer Default
Binary install /usr/local/sbin /usr/local/bin
Library install /usr/local/lib /usr/local/lib
Kernel source /usr/src/current /usr/src/linux
Network device eth1 eth0
Auto start no yes
Module install *** /lib/modules/2.4.16/COMPvpn
Certificates *** /etc/Intraport\ Client/certificates

(Items marked *** cannot be changed but are reported by the script. The default network device can be specified but your choice is ignored; the default is always eth0. Blanks in filenames are Not Standard Practice on UNIX systems. Most users will want to take most of the defaults. Particularly, the kernel source and the modules directory must match the actually running kernel, if self-compiled, since the ``linux'' link generally must point to the distributed kernel sources and, particularly, include files.)

It failed to compile. The message was: "programs should not directly include <linux/*.h> or <asm/*.h>" etc. etc. The symbolic link mentioned in the message has been set up on my system. I did specify the source directory for the actual in-use kernel version, which should have bypassed that link anyway. The problem was that the script asked for the location of the kernel sources but did not use that information. I edited ./vpn_install adding the line: 

KERNELSRCDIR=$the_srcdir
just after "Making module" (could have been anywhere after $the_srcdir is set). That got it to compile.

The program tried to install the start script in a directory that may exist on Red Hat 6.1 but which doesn't exist on SuSE 7.x: 

cp vpninit /etc/rc.d/init.d/vpn
It should be either of these (due to SuSE's convenient symbolic link): 
cp vpninit /etc/init.d/vpn        # --or--
cp vpninit /etc/rc.d/vpn
I changed the script, at "Create start/stop script at right location", adding: 
iscript=/etc/init.d/vpn
and changing the filename to $iscript wherever occurring (9 places).

Post-Installation Hacks

Finally it thinks it has everything installed. However, there are no certificates. Fortunately there's a note in the BOL instructions that Macintosh users will have to download the certificate separately, and the same is true for Linux. The correct destination is /etc/Intraport\ Client/certificates/root. Use quotes around the filename or backslash-escape the embedded blank.

The script also didn't do "depmod -a"; do it manually. It installed open_tunnel and close_tunnel setUID root, without telling me. This allows ordinary users to open the tunnel. It put symlinks for libscep.so.1 in /usr/lib, pointing to /usr/local/lib. This is unnecessary (on SuSE) since /etc/ld.so.conf lists /usr/local/lib as a standard library directory. The script does run ldconfig.

/etc/init.d/vpn sources /etc/rc.d/init.d/functions which must be a Red Hat feature. No functions are actually used. I commented out the line, and it works. All the script does is load the module. However, immediately upon loading, /proc/modules shows that the module's use count is -1. This means that it has not correctly registered itself. It will be impossible to remove the module later. Ignoring minor details . . .

It's important to set up /etc/vpn_config. The provided one is just an example, not set up for UCLA. I copied the one from Windows, editing it slightly. Also, going along with the filename in vpn_config, I renamed: ``mv /etc/Intraport\ Client/certificates/root/rootcert.txt /etc/Intraport\ Client/certificates/root/rootcert''. Here is my /etc/vpn_config. Fill in your own BOLID under UserName. 

[VPN Root Cert]
CertName = rootcert

[VPN User]
UserName = joebruin@ucla.edu
IPPrimary = vpn.ucla.edu
IPEnabled = True
ExcludeLocalLAN = True
ExcludeDHCP = True
UseFTCP = False
FTCPDestinationPort = 80
LoginMethod = Manual

Open_tunnel will ask for the ``RADIUS Password''. This is your Bruin Online password. It could be put in the config file like this, but that is very bad security practice. 

RADIUSPassword = AbCdEfGh

Executing the VPN Client

You can test the installation using your own internet connection. The same procedure will be used with the BOL wireless LAN. Execute these commands. Substitute your actual internet interface (e.g. Ethernet or PPP) for ``-d eth1'', except you can omit it entirely if on eth0. 

/etc/init.d/vpn start           #You must be root for this step
open_tunnel -d eth1 vpn.ucla.edu jimc@ucla.edu
    Enter the RADIUS Password for jimc@ucla.edu : (entered, no echo)
    Tunnel open for "jimc@ucla.edu" as "128.97.50.1" to "169.232.38.2".
^Z (stop the process)
bg                              #Resumes running in the background.

Configuring Your Wireless Card

Assuming that you have identified the driver for your wireless card, or that PCMCIA services has identified it successfully, the next step is to be physically present within the coverage area of the BOL LAN. During the test campaign this means the Young Research Library (first and third floors excluding dead spots), the Northern Lights Student Facility, or some adjacent exterior areas. Physically configure your card either by using shell commands, or by using a PCMCIA scheme. These instructions should work equally for the Dell TrueMobile 1150 internal card I have, the Cisco (Aironet) cards loaned out by BOL, or other popular 802.11b cards. Here is a suitable command line (some drivers need the essid to be set last): 

iwconfig eth1 mode Managed key off essid UCLAWLAN
You can edit /etc/pcmcia/wireless.opts to provide similar information. I have called the scheme ``BOL''. This stanza goes in a big switch statement that begins ``case "$ADDRESS" in''. 
BOL,*,*,*)
    INFO="Dell TrueMobile 1150 internal (Agere ORiNOCO) (UCLA)"
    ESSID="UCLAWLAN"
    MODE="Managed"
    KEY="off"
    ;;
Then you activate the scheme just by doing ``cardctl scheme BOL''. The scheme persists across reboots.

Operating With the Client

The dhcp client, which obtains your IP address from the LAN's dhcp server, is supposed to start automatically, but in my distro this doesn't happen properly, probably because I have multiple instances for both the wireless and the wired network. I need to do (as root) ``/etc/init.d/dhclient start eth1''. This is what the init script is called on SuSE Linux (even though dhcpcd is being started); other distros may call it something else. Once you have your IP address you can execute open_tunnel (see command lines earlier), and you're ready to roll.

Before you open the tunnel you can talk to the gateway machine on the wireless LAN, but your packets go no further. The only way off the net is through the VPN tunnel. None of the relevant machines answer ping packets.

When finished, execute ``close_tunnel''. Or you can kill the open_tunnel process explicitly. If you don't send packets over the tunnel for some time, probably about 10 minutes, it will close by itself.

Coverage Area

Normally network cards have a ``client manager'' for Windows, that includes a signal strength display. Once you have associated with an access point, you could walk around, watching the signal strength, and look for a good spot. In Linux most wireless drivers, specifically the one for orinoco, produce a file /proc/net/wireless, which shows the signal to noise ratio under "link", the received signal level under "level", and the received noise or competing signal level under "noise", all in dB or dBm. A SNR of 20 decimal or more is ``good''; 10 is ``marginal'', and at lower values the card reduces the data rate. A Linux user could write a script to print that out once per second, or you could even use your favorite graphical language to turn it into a bargraph, just as good as the Windows product. Download my version here. (Unfortunately, you have to hack the driver to get equivalent data on an ad-hoc network such as I use at home.)

Here's a rundown on signal strength at various locations in the UCLAWLAN coverage area:

Northern Lights Building
One access point (00:40:96:45:d0:22). Coverage is good in the northern part, specifically the Northern Lights coffeehouse, but fades out to the south. The signal is useless among the tables outside but adjacent to the building.
Library, First Floor, Southwest
Access point 00:40:96:45:72:77 is probably located over the periodicals reading area, giving excellent signal there. It fades out on the west side of the reference area, having zero signal strength at the north end of the reference stacks.
Library, First Floor, Central
Access point 00:40:96:55:1d:47 has good strength in the Abstracts and Indices area. It is marginal in the entryway catalog computer area, where 00:40:96:45:86:cc probably gives a much better signal.
Library, First Floor, East
Access point 00:40:96:45:86:cc is near the circulation desk, and provides good signal among the couches in that area. There is no signal on the benches just outside the library entrance. But it does give a low signal in the patio between the Waffle and Northern Lights, and extending east toward the Waffle.
Tables between Rolfe and Campbell
Access point 00:40:96:45:73:8b gives a marginal signal.
MacGowan Hall, South
Access point 00:40:96:45:69:82 has good signal in some areas (better to the west). At the east end there is reasonable signal but also an interfering access point which makes the SNR low.
Scuplture Garden, West
Access point 00:40:96:45:69:82 gives a signal of low and variable quality along the bridge, better at the north end.
Sculpture Garden, Southeast
Access point 00:40:96:45:69:82 has its best signal here.
Other Areas
There are supposed to be access points on the third floor of the library. There is likely an access point to the northeast of the Sculpture Garden, but I did not identify it. Signal strengths suggest an access point associated with Campbell Hall, but I did not find it.

Summarizing: outdoors, one access point can cover at least a 100 meter radius if there are no obstructions or neighbors on the same channel. Indoors, walls and equipment, particularly metal shelves and ovens, can seriously reduce the signal, and in some areas of the library the signal can barely reach 20 meters. The interior construction of University buildings is metal studs and real plaster over metal mesh backing, which would be impervious to radio signals except at doors. Residential construction in the USA is typically wood frame covered by plasterboard, or plywood for shear walls, and at home the signals are little affected by walls.

Firewall Note

The Cisco VPN5000 product communicates between the VPN server and the local machine using protocol 50 ``IPv6-Crypt'', probably referred to as ``IPSec'' in some protocol lists. If your firewall is set to drop all packets except carefully selected protocols and ports, as it should be, you should make sure that this protocol is among the blessed. Otherwise you will be able to open the tunnel, but all tunnel packets coming back from the server will be dropped. Here is a sample command line for the VPN protocol (not a complete firewall setup): 

iptables -t nat -A PREROUTING -p IPv6-Crypt -j ACCEPT

Hmmm... Testing the firewall and the VPN client together reveals that this is not enough. I would guess that there are keepalive packets coming back from somewhere which are blocked by the firewall and hence are not being answered, so after about 20 minutes the connection is killed. Here is what I received in about 3 hours of testing. An important point is that on TCP connections, incoming packets are not seen by tcpdump, being tunneled on protocol 50, whereas my replies are reported.

The lessons from this three megabytes of packet dumps are these:

Up: Wireless