FreeSwan - Linux Based Virtual Private Network

1. Synopsis
2. Description
3. Usage
4. Requirements
5. Installation
6. Troubleshooting
7. See Also



1. Synopsis

This document describes both the benefits of using the Freeswan implementation of the
IPSEC based Virtual Private Network and some basic installation instructions.

Freeswan is an implementation of the IPSEC set of protocols. When the word Freeswan is
referenced, this includes references to IPSEC in general (if that makes any sense which it shouldn't).


2. Description

2.1 Diagram - Basic VPN layout

vpn_dia file
Note: these addresses are fictional and are used as an example only


2.2 Description of VPN layout

Address Function
192.168.9.10 Local machine on the 192.168.9.0 network
226.122.11.69 Freeswan Gateway machine that sits on the 192.168.9.0 network and the internet
226.122.111.1 Internet gateway (usually provided by an ISP)
111.222.101.1 2nd Internet gateway (usually provided by the remote users ISP)
111.222.101.15 Remote Freeswan gateway that sits on both the Internet and the 192.168.0.0 network
192.168.0.5 Remote machine on the 192.168.0.0 network


 

 3. Usage

The primary benefit of using a VPN is to use the Internet as an active (secured) bridge between two private networks. In the example above, the network
192.168.9.0 is bridged to the network 192.168.0.0. Normally, there is no communication between these private networks (Internet routers do not
pass 192.168 addresses). Within a VPN, the basic IP communication is encapsulated and allowed to pass as if these networks were connected with
a bridge.


The benefit of this "bridge" is the ability to use the following services in the same way as you would if the 192.168.9.10 system was directly
connected to the 192.168.0.0 network.
          
email
Intranet web servers
databases - reached via ODBC or JDBC
telnet
nfs
samba

As an added benefit, the encapsulated communication between these networks can be encrypted so both the packet payload
and the originating IP address cannot be easily determined from the IP packets that traverse the Internet

4. Requirements

These are some basic packages that you'll need for the installation.
    2.1 Freeswan tarball/rpm package from http://www.freeswan.org (latest is 1.98)
    2.2 gmp library from gnu (http://www.swox.com/gmp/)
    2.3 Linux Kernel Source (2.4+ or 2.2)



5. Installation   

5.1 Installation - General Steps

1 GMP  - Download, unpack, and build the gmp library (./configure,make, make install, etc.)
2 Freeswan - Download, unpack, and build using 'make menugo' command (see below)
3 Kernel - Return to the kernel configuration utility, and check any IPSEC configuration choices under 'Network Options.'

5.2 Installation - Specific Steps

1. Run the kernel configuration program (make menuconfig) and save the current kernel configuration
2. Download and expand freeswan (using tar -xfzf freeswan.1.98.tar.gz)
3. type make menugo (this will start the kernel config and build the ipsec program).
4. Build a new kernel that includes ipsec
5. Include the new kernel in lilo.conf
6. Run lilo.conf to invoke the changes to lilo.conf
7. Reboot the system
8. Generate new rsa keys (if needed) with the command ipsec rsasigkey 2048
9. Update ipsec.secrets with updated key (see sample configs below)
10. Update the ipsec.conf (see sample config below)


           

5.3 Configuration Files

Freeswan uses the following two files:
ipsec.conf        - communication configuration options
ipsec.secrets    - Pre-shared keys and RSA signatures


The first sets up the communication parameters between the two Freeswan gateway machines. It is very important
that the communication parameters between the two gateways matches exactly since these are used as the first
part of a two step authentication process.

The second file (ipsec.secrets) holds RSA signature keys used for each gateway to identify itself to
the other. Each gateway will have a different ipsec.secrets file (generated with the next step).


5.4 Generating RSA Signature Keys


       
Command:
ipsec rsasigkey 2048 > rsa_keys.txt
Result:
        # RSA 2048 bits   pent166   Sun Aug  4 14:26:09 2002
        # for signatures only, UNSAFE FOR ENCRYPTION
        #pubkey=0sAQOp/C72f+VuPZCQsmXZorysKI3G55UmRb34CTXTJ9nqg2mZMfyo+d22xt5hiDgN6z0iQU9M
Z0pvGhBqeOLy5AU4Ftfeq2sK9llvS2S7IyziN2pF+qn4Gko4U3BuvPqJFoPZy464UoZyAQ/r2lJPu6EWCP3H4QlDuB
17Ps2sCs1t0sRB+8+jw6V+nUWmeOAS+T/Okr5zt0ToBLnkL+bxNnBmn5kbzMmY5AXfeNDjH5EWKQv8H7ZkglZ7PGWY
FRr33EMwpp8B3V9Mb0ct+ZUrktJA/c2bxe6JAbFbuB3w/e0CoGOK1Ou9OKf+CHEE3Xz6/3JC0yW8Oba8DjLesjFcfp
e7
        #IN KEY 0x4200 4 1 AQOp/C72f+VuPZCQsmXZorysKI3G55UmRb34CTXTJ9nqg2mZMfyo+d22xt5hiDg
N6z0iQU9MZ0pvGhBqeOLy5AU4Ftfeq2sK9llvS2S7IyziN2pF+qn4Gko4U3BuvPqJFoPZy464UoZyAQ/r2lJPu6EWC
P3H4QlDuB17Ps2sCs1t0sRB+8+jw6V+nUWmeOAS+T/Okr5zt0ToBLnkL+bxNnBmn5kbzMmY5AXfeNDjH5EWKQv8H7Z
kglZ7PGWYFRr33EMwpp8B3V9Mb0ct+ZUrktJA/c2bxe6JAbFbuB3w/e0CoGOK1Ou9OKf+CHEE3Xz6/3JC0yW8Oba8D
jLesjFcfpe7
        # (0x4200 = auth-only host-level, 4 = IPSec, 1 = RSA)
        Modulus: 0xa9fc2ef67fe56e3d9090b265d9a2bcac288dc6e7952645bdf80935d327d9ea83699931f
ca8f9ddb6c6de6188380deb3d22414f4c674a6f1a106a78e2f2e4053816d7deab6b0af6596f4b64bb232ce2376
a45faa9f81a4a3853706ebcfa891683d9cb8eb8528672010febda524fbba11608fdc7e10943b81d7b3ecdac0ac
d6dd2c441fbcfa3c3a57e9d45a678e012f93fce92be73b744e804b9e42fe6f13670669f991bccc998e405df78d
0e31f9116290bfc1fb66482567b3c6598151af7dc4330a69f01dd5f4c6f472df9952b92d240fdcd9bc5ee8901b



5.5 Update FreeSwan Configuration Files


Once the RSA signature key has been generated, it needs to be added to the ipsec.secrets and the ipsec.conf
files. The ipsec.secrets file will contain the whole key generated above. The ipsec.conf (communication parameters
file) will use the public portion of the sig key.


In the example below, the key generated above has been added below the line that starts with ": RSA"
( the PSK [pre-shared key] line at the top is used for VPN connections that do not use the RSA signatures)

               
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication.  See ipsec_pluto(8) manpage, and HTML documentation.

226.122.111.69 111.222.101.15 : PSK "vERIsECRETkEY"

# RSA private key for this host, authenticating it to any other host
# which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".
: RSA   {
       # RSA 2048 bits   pent166   Sun Aug  4 14:26:09 2002
        # for signatures only, UNSAFE FOR ENCRYPTION
        #pubkey=0sAQOp/C72f+VuPZCQsmXZorysKI3G55UmRb34CTXTJ9nqg2mZMfyo+d22xt5hiDgN6z0iQU9M
Z0pvGhBqeOLy5AU4Ftfeq2sK9llvS2S7IyziN2pF+qn4Gko4U3BuvPqJFoPZy464UoZyAQ/r2lJPu6EWCP3H4QlDuB
17Ps2sCs1t0sRB+8+jw6V+nUWmeOAS+T/Okr5zt0ToBLnkL+bxNnBmn5kbzMmY5AXfeNDjH5EWKQv8H7ZkglZ7PGWY
FRr33EMwpp8B3V9Mb0ct+ZUrktJA/c2bxe6JAbFbuB3w/e0CoGOK1Ou9OKf+CHEE3Xz6/3JC0yW8Oba8DjLesjFcfp
e7
       
}
     

 
In this example, the public portion of the RSA signature key has been added to the ipsec.conf (communication
parameters file).

       
# basic configuration
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        uniqueids=yes

# remote to hq
conn remote-hq
        leftid=@gw.remote.net
        leftrsasigkey=0sAQOp/C72f+VuPZCQsmXZorysKI3G55UmRb34CTXTJ9nqg2mZMfyo+d22xt5hiDgN6z0iQU9M
Z0pvGhBqeOLy5AU4Ftfeq2sK9llvS2S7IyziN2pF+qn4Gko4U3BuvPqJFoPZy464UoZyAQ/r2lJPu6EWCP3H4QlDuB
17Ps2sCs1t0sRB+8+jw6V+nUWmeOAS+T/Okr5zt0ToBLnkL+bxNnBmn5kbzMmY5AXfeNDjH5EWKQv8H7ZkglZ7PGWY
FRr33EMwpp8B3V9Mb0ct+ZUrktJA/c2bxe6JAbFbuB3w/e0CoGOK1Ou9OKf+CHEE3Xz6/3JC0yW8Oba8DjLesjFcfp
e7

        left=226.122.111.69
        leftsubnet=192.168.9.0/24
        leftnexthop=226.122.111.1
        rightid=@gw.hq.com
        rightrsasigkey=0sAQN8MTDa1Z1uDX6w+ckdmGkHfAJtP+B2xsl7NN2DKVmXgHsbp+gMbI9jpn7XclTK
zKJT4PzbvMi2LQVm68TpWzIlMasfas929DJ9Ajd9ujd9u93jf9ud9j92wUSt7TdqqyQ87
Bo6A7OvDNxzl+3vwQ2yUN+rxyMB8KHoNJQP6MVKdxz+cTcw6aBRtfALdQ==
        right=111.222.101.15
        rightsubnet=192.168.0.0/24
        rightnexthop=111.222.101.1
        keyingtries=0
        auto=start
        auth=esp
        authby=rsasig

       


5.6 Workstation settings

Add an entry into the routing table for local machines to find remote machines via the freeswan gateway.
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.9.5

Turn on packet forwarding (instructions for this will depend on your
distribution).

Create an opening in the firewall to allow the IPSEC protocols to get through and allow communication
between the two networks (this example is from ipchains):
/sbin/ipchains -I forward -j ACCEPT -s 192.168.9.0/24 -d 192.168.0.0/24
/sbin/ipchains -A input -p UDP -d
111.222.101.15/32 500 -j ACCEPT
/sbin/ipchains -A input -p 50 -d
111.222.101.15/32 -j ACCEPT
/sbin/ipchains -A input -p 51 -d
111.222.101.15/32 -j ACCEPT


IPSEC uses the UDP protocol 500 for the negotiation process and either the two TCP
based protocols on ports 50 and 51.

5.7 Starting the connection

Before any communication takes place between the VPN gateways, the two gateways have to
negotiate the communication parameters. This process, called the "key exchange" is where the
the two gateways begin exchanging both connection information (contained within ipsec.conf) and
identification information. If this process completes successfully, a tunnel is set up between the
gateways.

To start this process, use the following commands:

ipsec auto --add remote-hq
ipsec auto --up remote-HQ
ipsec auto --route remote-HQ

Note: remote-HQ refers to the connection labeled remote-HQ in the ipsec.conf file.


       

6. Troubleshooting

When troubleshooting, use the basic network tools listed below

6.1 Ping remote hosts

Troubleshooting the connection begins with pinging the remote hosts.
If the ping works then the connection is successful!   
   


6.2 IFCONFIG and ROUTE

Use ifconfig to see if ipsec is bound to correct network device.
You should see something similar to this:
               

eth0      Link encap:Ethernet  HWaddr 00:50:BA:6C:1D:97
          inet addr:192.168.9.5  Bcast:192.168.9.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:52727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43212 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:10390283 (9.9 Mb)  TX bytes:6848180 (6.5 Mb)
          Interrupt:3 Base address:0x300

ipsec0    Link encap:Ethernet  HWaddr 00:50:BA:6C:1D:97
          inet addr:192.168.9.5  Mask:255.255.255.0
          UP RUNNING NOARP  MTU:16260  Metric:1
          RX packets:4176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5085 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:1405299 (1.3 Mb)  TX bytes:668950 (653.2 Kb)



      
     
 Use route to see if route tables are correct.
 You should see something like this:


           
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     192.168.9.1  255.255.255.0   UG    0      0        0 ipsec0
localnet        *               255.255.255.0   U     0      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 ipsec0
loopback        *               255.0.0.0       U     0      0        0 lo
default         192.168.9.1  0.0.0.0         UG    1      0        0 eth0



6.4 Other Tools


Check firewall to make sure not blocked (ipchains -L)
Use 'ipsec barf' (this will create a large file containing all the Freeswan settings and portions of the Freeswan log)
Use tcpdump to confirm encryption
                tcpdump -vvv -i eth0        - displays IKE authentication exchanges)
                tcpdump -vvv -i ipsec0     - displays (hopefully) encryted communications


       

7. See Also

As I've setup Freeswan VPN connections I've found these sites to be extremely helpful.
Most of these provide diagrams of different setups (connections without local gateways
and so on).

http://vixen.tripod.com
http://bec.at/support/ipsec/configs
http://www.natecarlson.com



Presented to the Bozeman Linux Users Group by Joe Haynes of Terra Firma Software Solutions, Inc.