How can I configure a VPN using OpenLinux Server Release 3.1.1 and FreeS/WAN

by Heath Petty

Version 1.0
Installing and configuring a basic VPN using FreeSwan and Caldera OpenLinux 3.1.1

Contents



Objectives

When you have finished reading this cookbook you should be able to:



Introduction

A VPN is a low cost way of connecting two locations in a secure manner. VPN stands for Virtual Private Network, meaning that to the user it appears as though the two remote networks are on the same private network. Instead of leasing a dedicated data line from a telco company you can use a VPN to securely route traffic over the internet (or any untrusted network). This document explains how to install and configure a basic VPN using FreeS/WAN. FreeS/WAN is an opensource project that implements the ipsec protocol on the Linux™ system.

Requirements

The most basic requirement is that you have a working tcp/ip network. For instance, if you are planning to have two offices connected to each other then the basic IP needs to work, meaning that you have full communication between the two networks. It is best to get regular IP working before adding FreeS/WAN. Also all commands in this document are to be executed by the root user. The VPN gateways on both sides should be running OpenLinux 3.1.1 Server. In order to install FreeS/WAN you must install all packages on both gateways.

Background Reading

The FreeS/WAN website provides very detailed documentation on configuring and using FreeS/WAN. Refer to this page for a table of contents:

http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/toc.html

In addition to understanding VPN's and FreeS/WAN it is also a good idea to secure your VPN gateways against attack. There are several sources of good information on securing the Linux system. A good place to start is here:

http://www.linuxworld.com/linuxworld/lw-1999-05/lw-05-ramparts.html


Installation


Getting FreeS/Wan

FreeS/WAN can be downloaded from their website. Here is the URL to the directory where FreeS/WAN can be downloaded from:

ftp://ftp.xs4all.nl/pub/crypto/freeswan/

Download the LATEST.tar.gz file. This file always points to the latest version of FreeS/WAN. As of the writing of this document the latest version was 1.95 so that will be the version that is referenced. If you are using a later version just replace all instances of "1.95" with the version that was downloaded.


Unpacking and installing FreeS/Wan

Once the file is downloaded open a terminal window and change to the directory where the file was downloaded. Now unpack the tarball file:

tar -zxvf LATEST.tar.gz

And this will create a new directory in the current directory called freeswan-1.95 and put all the FreeS/WAN files in that directory. Now change to that directory:

cd freeswan-1.95

Now we need to build and install FreeS/WAN.

NOTE: FreeS/WAN requires that the kernel be recompiled, but luckily the good folks at the FreeS/WAN project were nice enough to write some nice scripts that make this easy to do. There are a few manual steps to getting the new kernel installed, but they are trivial and explained in this document

Now this is the sequence of commands to follow:

cd /usr/src/linux

make oldconfig

cd -

make xgo

Now this will bring up the X configuration for the kernel, just simply click the "Save and Exit" button then "OK". Now the compiling will begin. It will take a while to build the new kernel and FreeS/WAN. It could take up to 1.5 hours depending on the speed of the machine. At this point go and get a drink or a snack.

Once the compling is done we need to install the FreeS/WAN utilities. To do this issue this command:

make install

Now we need to install the new kernel. This is a two part process; first we need to copy the new kernel to the correct directory, then we need to configure GRUB to boot the new kernel.

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.4.13-freeswan

To configure grub open the /boot/grub/menu.lst file in your favorite text editor and add this entry:

title = FreeSWAN kernel
root = (hd0,?)
kernel = /boot/vmlinuz-2.4.13-freeswan vga=274 quiet root=/dev/[s|h]da?
initrd = /boot/initrd-2.4.13.gz

The added entry should look very similar to the entry already contained in the file except the title and the name of the kernel should be changed as detailed in the above entry (replace all the ? with the appropriate values, and specify s or h depending on whether the hard drive is a SCSI or IDE drive respectively). Depending on you configuration the initrd line may not be needed. If the existing entry in the menu.lst file has an initrd line then you will need to add it to the entry for the FreeS/Wan kernel. Otherwise, it can be omitted.

This new entry can be at the end of the file or right under the "default = 0" line. If you want this kernel to be the default kernel to boot (recommended) then set the default value here to the appropriate value (0 is the first entry listed in the file, 1 is the second entry in the file, etc). Now that we have the kernel built, installed, and ready to boot, reboot the computer. Make sure to choose the FreeS/WAN kernel from the boot menu if you did not make it the default.


Basic configuration of FreeS/Wan using Network-to-Network layout


Map of our network

Here is a basic map of our sample configuration

network

Explanation of our network: The west (left) subnet has the network address of 10.0.0.0/255.255.255.0(24). All clients are configured to use the internal network card of the west VPN gateway as their default gateway. The 12.1.2.1 router is the first hop that the west gateway uses to contact the east gateway (and vice-versa for the East gateway). The east (right) subnet has the network address of 10.0.1.0.255.255.255.0(24). Both VPN gateways have FreeS/WAN installed on them. They both contain 2 network cards, eth0 will be the external address, and eth1 will be the internal address.


Configuring FreeS/Wan using RSA authentication

RSA is based on public key cryptography. For the two VPN gateways to "talk" to each other they need to exchange public keys. In this example we are going to configure FreeS/WAN to use RSA keys for authentication.

First we need to edit the /etc/ipsec.conf file. This is the main configuration file for FreeS/WAN. It is very important that this file be correct. If the file is not correct then FreeS/WAN will not start, or run correctly. There are many different ways to configure a VPN but we will configure just a basic one. The configuration detailed here will allow two networks to securely communicate over an untrusted public network. You can use your favorite text editor to edit this file.

NOTE: You will need to replace all IP's and id's and rsa keys with the right information for your network

Here is the entirety of the ipsec.conf file, I will explain what needs to be changed after this listing (the line numbers are not required in the ipsec.conf file, they are listed here for easy referencing):

1  # /etc/ipsec.conf - FreeS/WAN IPsec configuration file
2
3  # More elaborate and more varied sample configurations can be found
4  # in FreeS/WAN's doc/examples file, and in the HTML documentation.
5
6
7
8  # basic configuration
9  config setup
10     # THIS SETTING MUST BE CORRECT or almost nothing will work;
11     # %defaultroute is okay for most simple cases.
12     interfaces="ipsec0=eth0"
13     # Debug-logging controls: "none" for (almost) none, "all" for lots.
14     klipsdebug=none
15     plutodebug=none
16     # Use auto= parameters in conn descriptions to control startup actions.
17     plutoload=%search
18     plutostart=%search
19     # Close down old connection when new one using same ID shows up.
20     uniqueids=yes
21
22
23
24 # defaults for subsequent connection descriptions
25 # (mostly to fix internal defaults which, in retrospect, were badly chosen)
26 conn %default
27     keyingtries=0
28     disablearrivalcheck=no
29     authby=rsasig
30     #leftrsasigkey=%dns
31     #rightrsasigkey=%dns
32 # our connection
33 conn west-east
34     # Left security gateway, subnet behind it, next hop toward right.
35     leftid=@west.ourdomain.com
36     leftrsasigkey=0sAQPo6Eh1r/0dzjBkPt5WSwDAR9lQNByg5sszyjp ....
37     left=12.1.2.4
38     leftsubnet=10.0.0.0/24
39     leftnexthop=12.1.2.1
40     # Right security gateway, subnet behind it, next hop toward left.
41     rightid=@east.ourdomain.com
42     rightrsasigkey=0sAQPm3znW9H1tq7PBIBGD+9FB+PHhaYje17bB ...
43     right=13.1.3.4
44     rightsubnet=10.0.1.0/24
45     rightnexthop=13.1.3.1
48     auto=add

Now this gives you a pretty good idea of the format of the file. Basically sections start with a header then all the parts of the section are set off with a tab (it is important that it is a tab that sets these off. If it is not a tab then FreeS/WAN will not start properly). You should be able to follow this file very closely replacing the ip addresses and the id's with the appropriate names. Here is an explaination of some of the options:

The option "interfaces" on line 12 tells FreeS/WAN which physical interface packages should go through. This should be your external interface. In this example the external interface is eth0 and that Network Card would have the IP of 12.1.2.4 on the west gateway, and 13.1.3.4 on the east gateway. The interface can be any Linux network device. For example if one of our gateways connected to the internet through a dial up connection then the device would be ppp0. If the ppp connection has a static IP then the only thing to change on the dial up gate way would be the device FreeS/WAN needs to attach to. If the IP is static then refer to the section Configuring Road Warriors for setting up FreeS/WAN to use dynamic routing and interfaces.

The options "leftid" and "rightid" are the FQDN, Fully Qualified Domain Name, of the respective gateways, preceeded by the @ symbol. In our example the FQDN of the left gateway is west.ourdomain.com and the FQDN of the right gateway is east.ourdomain.com. Eventhough we are using FQDN's for the id's DNS is not required to be setup as long as ip addresses are used for the left (line 37) and right (line 43) options.

The options "leftrsasigkey" and "rightrsasigkey" (lines 36 and 42 respectively) are the public keys for the respective gateways. These are used for authentication. To generate these keys you run the commands:

ipsec showhostkey --left

ipsec showhostkey --right

on the west and east vpn gateways respectively, meaning that you run the `ipsec showhostkey --left` command on the west gateway (from a commandline on the machine), and the `ipsec showhostkey --right` command on the east gateway(again from a commandline on the machine). Take both of these and insert them in the appropriate places in the ipsec.conf file. If the machines are very far apart then the keys will need to be traded in a secure manner. This can be done by using encrypted email, snailmail, or faxing. Make sure THAT ONLY TRUSTED PEOPLE SEE THESE KEYS, otherwise your vpn could be compromised! You then take the output of those commands and cut and paste them into the file in the correct place (line 36 and line 42, respectively, in our sample configuration). NOTE: the rsa keys are shortened in our example for clarity. Here is a sample output of the above command with the --left option:

leftrsasigkey=0sAQPm3znW9H1tq7PBIBGD+9FB+PHhaYje17bwK8rrVkXzryLYh541Tevz/ZrfalScoUcEQhcxValPrLTCGwfUre3jf8J55SvEBkS8IKBdW7UbaW4Oz1io2Y4u4z024dUkOIwKfmNuTxYkpAt6pI5eBdQYbbdAZGte/DRz4IhpSpqY9jbgm1msoHBQNvd1Dh3sO+5gDC/c9JIAvGtMOxKKaXqMkp4wVyDofN6tvIaaOpnLh3ps7kBFsT+zdduy906pQ1cGHmEzJTLfkMAIwsv6LQKxg3DHQyFAEKulsD8N3/qC4HBa58dImKBaCWTGvdzZtUEgD10BvY8jCRBZfQYrmygB

The options "leftnexthop" and "rightnexthop" (lines 39 and 45 respectively) are required if the vpn gateways are not on the same network. The IP values for these options are the first router the vpn gateway goes through to reach the other vpn gateway. For these values either contact the network administrator, or run the command:

traceroute -n [east.ourdomain.com | 13.1.3.4]

The first hop is the router that the server goes through to reach the other gateway. In our example the above command is run from the west gateway. The first hop reported would be 12.1.2.1. We would then use that value for the leftnexthop option. Repeat the process for the east vpn gateway.

The sample ipsec.conf file used above with further comments and help can be found here . You can also use this file, after making the necessary changes for a test enviroment or to setup a VPN.
 

NOTE: the ipsec.conf file needs to be exactly the same on both vpn gateways (except the interfaces option this is dependent on which interface you want FreeS/WAN to run on). It is best to send the file using PGP signature through email or use the scp command so that the rsasigkeys don't fall into the wrong hands.
For a more detailed description of this file, see the ipsec.conf(5) man page:

man ipsec.conf


Running FreeS/WAN

Once the ipsec.conf file is written and configured correctly we simply run this command on both gateways to restart the service:

ipsec setup restart

Once FreeS/WAN is running on both gateways, from one gateway issue this command:

ipsec auto --up west-east

This will start the actual connection. If everything is good then you will see the above command return something like this:

104 "west-east" #30: STATE_MAIN_I1: initiate
106 "west-east" #30: STATE_MAIN_I2: sent MI2, expecting MR2
108 "west-east" #30: STATE_MAIN_I3: sent MI3, expecting MR3
004 "west-east" #30: STATE_MAIN_I4: ISAKMP SA established
112 "west-east" #31: STATE_QUICK_I1: initiate
004 "west-east" #31: STATE_QUICK_I2: sent QI2, IPsec SA established


Testing the configuration

Now that we have the connection up and running we can run a simple ping test. I will use our example here to illustrate how it is done. From a machine on the west subnet (10.0.0.0/24) I run this command:

ping 10.0.1.2

where 10.0.1.2 is the ip of a machine on the east subnet. If the pings are coming back then the tunnel is up and running. this can also be repeated from a machine on the east subnet to a machine on the west subnet.

To make sure that the packets are in fact traversing the vpn and not being routed a different way, we can use the tcpdump utility to see what packets are being sent on the ipsec0 device. From either of the gateways run this command:

tcpdump -i ipsec0

Now from one of the clients on either network, ping a client on the opposite network (ie from east network to west network). You should now see icmp packets going back and forth between the two clients. Here is a sample output:

17:11:51.934229 10.0.0.2 > 10.0.1.2: icmp: echo request (DF)
17:11:51.934633 10.0.1.2 > 10.0.0.2: icmp: echo reply
17:11:52.934339 10.0.0.2 > 10.0.1.2: icmp: echo request (DF)
17:11:52.934727 10.0.1.2 > 10.0.0.2: icmp: echo reply
17:11:53.934475 10.0.0.2 > 10.0.1.2: icmp: echo request (DF)
17:11:53.934843 10.0.1.2 > 10.0.0.2: icmp: echo reply

Of course the IP address show here will reflect the IP addresses of the machines used to ping.

NOTE: The ipsec0 network device is the device that FreeS/WAN uses to securely send packets to the other gateway. This is a virtual device meaning that there is no piece of hardware associated with it. Packets traversing the ipsec0 device are encrypted and only travel to the other gateway. The packets shown above are not encrypted yet, but if you took another computer and put it between the two gateways and then sniffed the packets (using a utility such as tcpdump or ethereal) you would see that the contents of the packet would be encrypted.

Some suggestions for when things don't work

- Check the log files: /var/log/messages and /var/log/secure for any error messages then address those error messages.

- Make sure that the underlying IP infastructure is okay and working correctly. Make sure that the two gateways can ping each other. If the machines in the various subnets have regular routable addresses then make sure that they can ping through the gateways to each other

- Make sure that there are no firewalls blocking communication between the two networks. For more information on using FreeS/WAN with a firewall see the FreeS/WAN documentation referenced in additional reading.

- Make sure that the ipsec0 device is up and has the right IP address (this will be the same as the external network device) To see the network devices run this command:

ifconfig


Configuring Road Warriors

Many times we will want to give telecommuters, or traveling employees secure access to our network. In  VPN terminology this type of connection is a Network-to-Host connection. Usually the remote computers get a dynamic IP address, either through a dial-up account or by using broadband connection such as DSL or Cable. In this section we will define a Road Warriors as any computer that has a dynamic IP address. The Road Warrior is the Host in our Network-to-Host configuration.
road warrior
So, now here is a new map of our connection. In this configuration we have the same subnet on the west side as our above examle . The Roadwarrior connects to the internet either through a dial-up or through a broadband connection. The Roadwarrior uses a dynamic IP address, so we have to account for this. This configuration will allow the Road Warrior to connect securely to the 10.0.0.0/24 network. Configuring a Road Warrior is very similar to the configuration specified above. Unlike the Network-to-Network configuration there will be two different ipsec.conf files. The Road Warrior machine is also running OpenLinux Server or Workstation 3.1.1, with FreeS/WAN installed .

VPN Gateway (server) configuration

On the West VPN gateway we are simply going to add another connection definition for the Road Warrior. At the end of the file we will add this:

conn road-warrior1
        leftid=@west.ourdomain.com
        leftrsasigkey=0sAQPo6Eh1r/0dzjBkPt5WSwDAR9lQNByg5sszyjp8Y5TD5Q9iSH8PAvjIlxMRrXbHfi8HAq0pRTax2M ...
        left=12.1.2.4
        leftsubnet=10.0.0.0/24
        leftnexthop=12.1.2.1
        #the road warrior definition.
        rightid=@road-warrior1.ourdomain.com
        rightrsasigkey=0sAQN/8fgN7InWLZWFDYA8Us8aCo6FwkvBhdR1FMspVrkjNn4VrvQC7L0g3Wy04uBfrvhXPxbEB3ed ...
        right=%any
        keyingtries=1
        auto=add
In the above example the leftrsasigkey is the same public key that we used in the previous example. The rightrsasigkey is the public key of the specific road warrior machine. This again is generated using the "ipsec showhostkey --right" command on the road warrior machine.

NOTE: You will need to create a new connection definition for each road warrior that is connecting to the system. For example, if there were another road warrior that needed to connect I would make a copy of the above section right below the connection definition for road-warrior1 in the ipsec.conf file. Then I would change the name to road-warrior2 and replace the rightrsasigkey with the public key from the second road warrior. You will want to use more descriptive names for the connections to keep everything straight. The name after conn is abritrary and can be any text string.
The "right=%any" means that we accept the connection from any IP as long as the RSA authentication is valid. At least one side must have a static IP so that the client will be able to make a connection to it.

Here is a copy of the updated ipsec.conf file for the Gateway (server), with the added connection definition


Road-Warrior (client) Configuration

The  /etc/ipsec.conf file on the Road Warrior is almost the same as on the server. Here are what changes need to be made to the  "config setup" section:
change the " interfaces="ipsec0=eth0" " to read: interfaces=%defaultroute
Now after the "conn %default" section add a connection definition for the connection. For our configuration It will look like this:

conn road-warrior
        leftid=@west.ourdomain.com #the west gateway
        leftrsasigkey=0sAQPo6Eh1r/0dzjBkPt5WSwDAR9lQNByg5sszyjp8Y5TD ...
        left=12.1.2.4
        leftsubnet=10.0.0.0/24
        leftnexthop=12.1.2.1
        rightid=@road-warrior1.ourdomain.com
        rightrsasigkey=0sAQN/8fgN7InWLZWFDYA8Us8aCo6FwkvBhdR1FMspV ...
        right=%defaultroute
        keyingtries=1
        auto=start

The right and left rsasigkey Are the same as the keys in the ipsec.conf file on the gateway. There only needs to be one connection definintion in the ipsec.conf on the Road-Warrior machine.

Here is a copy of the ipsec.conf file for the Road-Warrior (client).


Summary, and starting the connection

Just to help clarify I will define the steps for setting up road warrior connections.
  1. Install FreeS/WAN on all road warrior machines.
  2. Collect all the public keys for each road warrior using the ipsec showhostkey --right command on each road warrior machine.
  3. Create a connection definition for each road warrior in the ipsec.conf file on the gateway machine, make sure to follow the format above, and to give each connection a unique name.
  4. Now on each respective road warrior add the connection definition using the format above. Make sure you use the same name for the connection as you did on the gateway.
  5. Now simply start FreeS/WAN on the gateway machine (or restart it) using the command ipsec setup restart
  6. On the road warrior either restart the machine, or restart ipsec using the above command. The connection will automatically start when FreeS/WAN starts on the client. This is due to the auto=start line in the ipsec.conf file on the road warrior

References and Further Reading

The FreeS/WAN project maintains excellent documentation. The table of contents for this can be found here:

http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/toc.html

Building Linux Virtual Private Networks  "offers concise, step-by-step instructions for building VPNs based on both standard protocols (IPSec, SSL, SSH, PPTP) and popular Linux VPN solutions (VTun, cIPe, tinc). Through numerous examples and proven practices, you will gain important insights into choosing a VPN solution, installing and configuring it, setting up routing, configuring firewalls, measuring performance, and much more "


Feedback

What did you find particularly helpful in this cookbook? Are there mistakes in this documentation?
Could it be organized more usefully? Did we leave out information you need, or include unnecessary material? If
so, please tell us.

To help us implement your suggestions please email:

olbo@caldera.com

including  relevant details, such as cookbook title and section name.

NOTE: We cannot provide technical support via the above alias. For answers to technical questions, please
contact your Caldera Support Provider or visit http://www.caldera.com/support for details of
support offerings that are availble to you.
Thank you.



(c) Copyright 2002 Caldera International, Inc.  All Rights Reserved.  Caldera International assumes no responsibility for the accuracy or completeness of the
information in this document. The use of this information or the implementation of any of these techniques is a customer responsibility and depends upon the
customer’s ability to evaluate and integrate them into the customer’s operational environment. Information in this document is subject to change without notice and
does not imply a commitment on the part of Caldera.

Caldera, the Caldera logos and OpenLinux are trademarks or registered trademarks of Caldera International, Inc. in the U.S.A. and other countries. Linux is a
registered trademark of Linus Torvalds. All other brand and product names are trademarks or registered marks of the respective owners.