Build a Flexible VPN with FreeS/WAN and Linux, Part 2
Having learned about the advantages of a VPN solution built around low-cost FreeS/WAN, it's time to move on to configuration and testing.
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.
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 unknownThis 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.
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
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:
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.
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.
- Downloads and instructions:
- Download rpms
- Source tarballs
- Main FreeS/WAN documentation index
- Red Hat Linux
- Build a Flexible VPN with FreeS/WAN and Linux, Part 1
- Some Linux-based VPN products:
- Commercial VPN products
- Free VPN/Firewalls On Bootable CD
Because CDs are non-writable, theoretically they are more secure. In the event of a successful intrusion, a simple reboot should cure all. After repairing the breach, of course.
- VPN Clients