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
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.
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.
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.
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
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
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.
- 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
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
change the " interfaces="ipsec0=eth0" " to read: interfaces=%defaultrouteNow 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).
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 "
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.
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.