Build a Flexible VPN with FreeS/WAN and Linux, Part 1
FreeS/WAN is an ideal solution for the overworked, harassed network admin who needs to bring together branch offices, telecommuters, and road warriors from anywhere over the Internet, and it does it all for the price of the hardware, with requirements that are surprisingly low.
S/WAN is short for Secure Wide Area Network. FreeS/WAN is a free Linux implementation of IPsec (IP security) protocols. IPsec is built into IPv6, and is optional for IPv4, the current IP (Internet Protocol) deployment. IPsec provides two levels of protection: encryption and authentication, at the IP level of the network protocol stack. Because IPsec operates at the network layer, it secures nearly any type of Internet traffic.
One common scenario creates a secure 'tunnel' between two networks, over an untrusted network; in effect, creating a single large private network over the Internet, or inside any company or institution with departments that need to protect their data. Another common scenario is creating a secure connection between a network and a single remote host.
Not only is the entire transmission encrypted, authentication ensures that data have not been altered en route. The founder of FreeS/WAN, John Gilmore, calls it "Securing the Internet against Wiretapping." It's an elegant solution to a serious problem for business and commerce- the wide-open nature of the Internet. Wide-open is dandy for exchanging information and ideas, but not so good for sensitive customer data, financial transactions, and the like. The other option is to build a physical private network, with attendant costs that go beyond stringing a few wires.
It's not quite a complete solution. Network-to-network tunnels are easy, that's just your FreeS/WAN gateways talking to each other. Network-to-host, or server-to-client if you prefer, is a little more difficult. Linux clients are easy, many of the current major distributions include the client software, such as Red Hat, Mandrake, and SuSE. It's a simple matter to enter the configuration settings that point to your VPN gateway. Windows and Mac clients present some challenges. Windows 2000 includes its own IPsec implementation. It varies amongst the many Windows 2000 releases, some support subnets, some support a single client only. For the least headaches, using a commercial IPsec client may be the best choice for Windows and Mac users. These are not free, they cost actual money. But freedom from headaches is worth much money.
The nicest part is it once you set it up, it just works. The user does not need to take any extra steps. Which is nirvana for network admins, who know all too well how difficult it is getting users to take even a single extra step. And really, why should they? Make the computers do the work.
FreeS/WAN is flexible and fits into just about any network design. Incorporate it into a firewall, run in parallel, run behind, run in front of your firewall. Unless you're using some way offbeat network hardware, FreeS/WAN should work anywhere IP works, including IEEE 802.11 wireless LANs. There are many free and commercial implementations of IPsec based on the FreeS/WAN code base, so you ought to be able to find one that suits your exact needs. It's a natural fit to combine with a firewall, and many firewalls incorporate it.
For building a meaningful test bed, the FreeS/WAN team recommends linking five PCs: two VPN gateways, two clients, and a router/monitor machine between the gateways. Once you've torture-tested and configured to your heart's content, remove the router/monitor, reconfigure the gateway boxes to point to your real networks instead of the router/monitor, and voila! You have two gateway boxes ready to work.
It is possible to use a single machine as a test bed, using User Mode Linux, http://user-mode-linux.sourceforge.net/. Since version 1.92, (current version is 1.95) FreeS/WAN has included a directory named 'testing', containing test scripts and sample configurations. User Mode Linux allows building VPN tunnels between several virtual Linux sessions. It's worth getting acquainted with User Mode Linux for all kinds of testing, not just FreeS/WAN. Virtual machines require some horsepower, the FreeS/WAN documentation recommends a minimum 128 MB RAM and a 500 MHz CPU. 256 MB RAM is more realistic.
For FreeS/WAN testbeds, a simple Internet connection with a static IP address is essential. Clients can use dynamically-assigned IP addresses, but not the gateway. Access to a dial-up account allows for basic simulations of 'road warrior' connectivity, making it easy to test a complete VPN from two computers.
For the least pain and hassle, I recommend downloading the latest
and installing it on a nothing-to-lose test machine running Red Hat
7.2. Both are free downloads. If you want to leap right in and not
wait for the second part of this article, see the Quick Start page:
http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/quickstart.html#quick_guide An old Pentium 166 with 64 MB RAM makes a lovely stand-alone FreeS/WAN gateway. Of course this varies with the load, and whatever other apps are installed on the machine, such as a firewall. I've seen this type of setup used successfully for a medium-sized office on a T1 with 150 or so users.
How It Works
The first step is gateway authentication. FreeS/WAN supports manual and automatic keying. Automatic is preferable- it is more secure. Two systems authenticate each other and negotiate their own secret keys. Should a key somehow be intercepted by a person with nefarious intent, no problem, new keys are periodically generated and exchanged, so any damage is automatically limited. The FreeS/WAN team prefers using RSA key pairs, the standard public/private sets. Once a connection is validated and established, encrypted traffic flows and away you go.
The `tunnel' image is a bit misleading. Your packets are still wide-open to interception, there's no barrier to packet-sniffers. FreeS/WAN uses 3DES- 168-bit encryption, so anyone spying on your packets will see nothing but gibberish. Single DES, 56-bit encryption, has been long proven to be vulnerable to brute-force cracking, it should not be used at all. Be warned- some commercial implementations of IPsec use single DES.
A great starting point to get a handle on all this is Richard Guy Briggs' excellent slide presentation: "http://www.conscoop.ottawa.on.ca/rgb/freeswan/ols2k/" The documentation is abundant and well-organized: "http://www.freeswan.org".
Part 2: Make It So:
In part two, we'll walk through typical network-network and network-host configurations, and discuss a few 'turnkey' options.