Build a Flexible VPN with FreeS/WAN and Linux, Part 2

Part One of this article discussed the advantages of FreeS/WAN, a
Linux-based VPN package that allows even older Pentiums to be pressed
into service as flexible VPN servers and offered an overview of how to
build a test-bed network. In Part Two, Carla Schroder
discusses basic installation and configuration.

In part 1 we discussed what FreeS/WAN does. Now we put it to work.

The basic steps are: -installation -configuration -testing Must have:
-Internet access with a static IP -A correctly configured, working LAN.

Installation

If you’re not up to speed on Linux, the quickest way to get up and
running is to install Red Hat Linux 7.2 on a test box, then download
and install the FreeS/WAN rpms. Sun, BSD, and all other Unix users
should have no trouble mastering Linux. Be sure to install GMP,
ncurses, and patch- they are not included in every prefab installation
option. Red Hat is the platform that FreeS/WAN is built and tested on.

Now go to Steamballoon, to get
the two FreeS/WAN rpms. Be sure to find the rpm compiled for your
CPU, or it won’t work. Also download freeswan-1.91-0.i386.rpm, this
contains essential utilities. Please see the resource section below
for additional links and detailed installation instructions.

This will not replace the kernel that came with RH 7.2, but will add
an IPsec-enabled kernel to your system. Linux allows installing as
many different kernel images as you like.

After installing the rpms and rebooting, the boot loader, LILO or
Grub, should display a menu of boot options. Pick the one that says
IPsec. Verify which kernel has loaded, type uname -a at a shell
prompt. It should display something like:

Linux gateway1 2.4.9-13ipsec #2 Thu Dec 21 16:46:36 EDT 2001 i686 unknown

This verifies that the IPsec-enabled kernel is running.

Or run dmesg (type dmesg at the prompt) to find KLIPS (kernel IPsec)
and Pluto (IKE daemon) messages. KLIPS is FreeS/WAN’s implementation
of authentication and encryption protocols. Pluto manages Internet Key
Exchange. You’ll become well acquainted with both of these.

That’s my recommendation for users with little Linux
experience. Experienced Linux users can use any distribution they
like, and should consider installing FreeS/WAN from source. This is
how to get the latest, most improved version, and to have the most
control over installation and configuration. The rpms are several
versions behind the source tarballs, as of this writing the latest rpm
contains version 1.91, while the current tarball is 1.97. When
downloading the tarballs, grab everything that starts with
‘freeswan-‘. Knowing how to apply patches and compile the kernel is a
necessary skill in any case.

Configuration

The FreeS/WAN docs teach this far better than I can. See
http://www.freeswan.org/doc.html to find the docs for your
version. The mail lists are invaluable:
http://www.freeswan.org/mail.html

Testing

The challenge with FreeS/WAN, as with all network tasks, is in avoiding
getting buried by the complexity of the many interactions- LAN,
Internet, firewall, proxy, http, etc. Please be sure your test
network is actually working before running FreeS/WAN. Life presents
enough head-banging conundrums, no point in creating more.

The ideal test bed consists of two subnets connected by a
router/monitor, five computers total:

client1==gateway1—-router/monitor(“the
Internet”)—-gateway2==client2

The gateways must have fixed, routable IPs. Client machines can
have non-routable IPs, behind IP masquerading. The subnets must be in
different IP ranges, even though they are masqueraded. Be sure that
packet forwarding is enabled on the “Internet” machine. It is usually
turned off by default, a wise precaution. Also on your “Internet” box
run a packet sniffer and traceroute. Ethereal has a nice graphical
interface, and tcpdump comes in all Linuxes. See the
ping test page
for good testing scenarios.

Run an absolute minimum of services, construct as lean and clean a
test system as possible. Focus on getting comfortable with
FreeS/WAN. Once you are building tunnels and moving packets back and
forth with the greatest of ease, add new functions, testing them first
without IPsec enabled. When they work correctly, enable IPsec and see
if they still work. Most FreeS/WAN problems are either routing or
firewall errors. Use patience and a systematic approach. Keep a
detailed diary, you’ll be glad you took the trouble when your shiny
new VPN gateway goes live in the Real World.

RSA Authentication Keys

When you install FreeS/WAN yourself, RSA keys are automatically
generated and stored in the ipsec.secrets file. FreeS/WAN offers a
couple of different ways of managing key exchanges.

Version 1.91 offers “opportunistic encryption”, but warns that the
code is not yet reliable. Opportunistic encryption means that
gateways authenticate and encrypt automatically, without humans
manually exchanging keys. In version 1.95 it’s good to go. Enabling
opportunistic encryption requires some DNS tweaks. Even though it is
easy enough to exchange keys via encrypted email, snail mail, or even
fax, the great advantage of opportunistic encryption is not needing to
exchange keys with other administrators before you can connect. The
computers do the work. Chances are you’ll do both, even if you are
running the latest and greatest, you may need to interact with
gateways that are not capable of opportunistic encryption.

Happy Ending

VPN/IPsec is a complex and evolving technology. After reading this
series and looking at the documentation, it may seem rather
overwhelming. It’s really not that difficult, the main configuration
file, ipsec.conf, is organized logically, with sensible defaults. The
good news is once it’s up and running, it’s low-maintenance, it just
works.

Additional Resources


»


See All Articles by Columnist
Carla Shroder

Latest Articles

Follow Us On Social Media

Explore More