IPSEC is the new, standards-based way of setting up a Virtual Private Network (VPN) between two computers. Though IPSEC was originally designed for the new IPv6 (IPng) TCP/IP protocol, it is also being deployed for the TCP/IPv4 (normal TCP/IP) too.
If you don't know what a VPN is, imagine a network at work that is on the Internet but behind a strong firewall. Unless you have remote access into work, you can't get to any of those machines huh? Not anymore! If your work has a connection to the Internet and a IPSEC VPN server (be it Linux, Cisco, etc), you'll now have ability of accessing your computers internal to your work via the Internet in a secure and 168-bit+ encrypted fashion. Though you're access speeds and even availably will be Internet-weather dependant, its both a GREAT and CHEAP method of remote access.
Common questions include:
* Is IPSEC only for Linux? No way! Who else can connect?
Currerntly, there have been several ports that Linux's SWAN IPSEC VPN works with:
I'm sure other vendors will be added to this list as time goes on.
* Is it RFC complient?
Linux FreeS/WAN is an implementation of IPSEC. It does not yet implement all of IPSEC, but everything it does follows the IPSEC RFCs.
* What about Performance and CPU utilization?
Someone has tested the SWAN VPN with a Cisco 2501 and a 486/DX50 across as T1. The 486's CPU utilization was about 15% while the 2501's utilization was about 80%!
One benchmark seens with Triple DES (our default bulk encryption method) can do 1.6 megabytes per second on a Pentium 200. That's > 10 megabits/second.
(on a 100Mbit LAN: with the OLD SWAN code : Newer SWAN code should run roughly 3x faster on Intel x86 systems:
* No IPSec * DES * 3DES
P200 = >80 Mb/s P200 = 10-15 Mb/s P200 = 2-4 Mb/s
P450 = >80 Mb/s P450 = 20-25 Mb/s P450 = 10-14 Mb/s
I think encryption is what degrades performance the most, and you would be best off with a HW accelerator if you want to get closer to max.
*** NOTES:
- Please note that I haven't had the time to bring this up myself yet but I've had a few users that said that they did. If you have any comments, ideas, changes, please email me.
- Please see the Gotchas at the end of this section regarding DHCP, IPCHAINS/IPFWADM rule sets, etc.
- If you have problems with the SWAN code, please join the SWAN email list for support. I cannot help at the moment since I don't have a SWAN setup running
-- FreeSwan/IPSec installation instructions for Linux v1.20 Clarifications made and added a Gotcha regarding : dranch v1.10 Additions by David A. Ranch v1.00 by Rob Hutton <mailto://HuttonR@plymart.com>
NOTE: You should also be able to terminate the VPN on the Linux box directly. This isn't documented here yet but it will be done in the TrinityOS doc. Until then, you'll have to figure it out.
NOTE2: This document assumes that you are running this initially WITHOUT a firewall. Once its running, see the bottom for the relivant IP ports to allow though the IPFWADM/IPCHAINS/etc rule sets.
If you have not configured and built your own kernel, do so. The FreeSwan utilities depend on the results. Instructions for that can be found at
http://www.tldp.org/HOWTO/Kernel-HOWTO.html
Once you have compiled and built your own kernel, draw a simple diagram as follows:
| Machine (S) | | Machine (G) | | Machine (H) | | Machine (T) | | Remote Host |<--->|Remote Firewall/VPN|<...>|Local Firewall/VPN|<--->| Local Host | | IP: | | IP: | | IP: | | IP: |
Record all IP addresses, and their associated interface and netmask, and the routing tables from each machine. Then, it is CRITICAL to first TEST you network connectivity before you attemp to setup the VPN. It is recommended that the (S) machine can ping (T) and that (T) can ping machine (S). Also test any other services that you will be using such as TELNET, SSH, FTP, SMTP, etc .
NOTE: If *either* protected network is privately addressed, please see the note in the "Notes and Gotchas" Section.
[DO THE FOLLOWING ON BOTH MACHINES]
Download the newest version of SWAN (preferably the current "snapshot" code) from the sites found in Section 5
Uncompress the file using:
tar xvzf freeswan-X.tar.gz
or your favorite uncompress command where "X" is the newest version of SWAN.
This will create a directory called freeswan-X with the sources and installation files in it. I recommend that you print the INSTALL and doc/vpn.how file to refer to.
cd to the freeswan-X directory. Build the libraries, programs, and utilities by typing:
make
Then install them by typing:
make install
Edit the /etc/sysconfig/ipsec file. Look for the KLIPSINTERFACES variable. Change it to reflect the interface that you will be using to run the VPN across.
NOTE: This assumes you are running Redhat Linux
Next, install the kernel patches be typing:
make insert
CD to the LINUX source directory and run menuconfig:
cd/usr/src/kernel/linux
make menuconfig
The following networking options should now be set on:
If it is not enabled, set the following on:
You should also have new options at the bottom of the page for "IP Security Protocol (IPSEC)" which should be enabled. Now exit and save your configuration, and remake and install the new kernel. When you are finished, reboot to activate the changes.
Next, edit the /etc/services file and add the following (if not there already):
--
isakmp 500/tcp isakmp
isakmp 500/udp isakmp
--
Again, verify that you can ping, telnet, ftp, etc. from one host/workstation to the other (T to S and S to T) in both directions.
[DO THE FOLLOWING ON ONE OF THE FIREWALLS. I WILL USE G]
Edit the /etc/ipsec-auto file. Change the left=[id address] to be the ip address of the NIC you are running the VPN across on machine G. Change leftsubnet=[ip address/netmask bits] to the address/netmask of the private/protected subnet on machine G. If the machines are not directly connected (on the same network), change the address of leftnexthop=[ip address] to the address of the next router between G and H. Now edit the corresponding "right" variables to match the configuration of H. Exit and save your changes.
Edit the /etc/ipsec-manual file. Make the same changes to the snt connection and delete all of the other connections. Exit and save your changes
Edit the /etc/isakmp-secrets file. Change the IP addresses (the first column) to match the addresses of the nics that are running the VPN. Exit and save your changes.
Copy the ipsec-auto, ipsec-manual, and isakmp-secrets from G to H. Using a floppy is the best way to make sure that the files do not get corrupted. Make sure that the files on both machines are owned by root and have permissions rw-------.
Again, reboot both machines.
Examine the /var/log/messages (for Redhat users) to make sure that IPSEC loaded without any error messages. Also, verify that the following entries exist in the /proc/net/ directory:
ipsec_eroute
ipsec_spi
ipsec_spigrp
ipsec_spinew
ipsec_tncfg
ipsec_version
Verify that ipsec is attached to the correct NIC by typing:
cat /proc/net/ipsec_tncfg
on (host G) type:
ipsec manual snt up
Then on (Host H) type the same thing.
Now type ipsec look on either machine. You output should look something like:
foo.spsystems.net Wed Nov 25 22:52:45 EST 1998 ------------------------------------- 10.0.1.0/24 -> 11.0.1.0/24 => tun0x200@11.0.0.1 esp0x2@11.0.0.1 ------------------------------------- tun0x200@11.0.0.1 Ipv4_Encapsulation: dir=out 10.0.0.1 - > 11.0.0.1 etc. etc. etc.
If it does, your VPN is up. You can test it by doing a tcpdump in between the two machines. You should see data transmitted back and forth over IP protocol 50. Test each subsystem to make sure they work using FTP, TELNET, SMTP, etc.
Now type the following on both boxes:
ipsec manual snt down
Now type the following on both boxes:
ipsec auto snt add
ipsec auto snt up
Again, test to see that each subsystem works.
Auto-starting the VPN:
Edit the /etc/sysconfig/ipsec file on both machines. Near the bottom add "snt" to both the PLUTOLOAD and PLUTOSTART variables. Now reboot both machines, and the VPN should start automaticly.
The latest SWAN code is always in the snapshot.tar.gz file. If you cannot get SWAN to work, etc, you might want to try installing the snapshot as there have been many changes since the x.91 code was released.
If either network is privately addressed and you are running over the internet you will not be able to do this. In this case, if you can ping devices on the internet outside of your network from the VPN servers (machines G and H), routing is probably correct. Once the tunnel is up, you will not be able to see any machine on the remote subnet from the gateway machine (G or H), so make sure you are testing the VPN from client machines on the protected subnets, not the gateway machines themselves.
Currently, DHCP will return with an unknown device type error after you install the SWAN patches (It will do this whenever you set up a tunneled interface) and then exits. To fix this, download the DHCP source from the URL in Section 5. Next, in the DHCP source code, ADD the following BEFORE the "ARPHRD_ETHER" case statement:
NOTE: This issue might have been fixed in newer released of Swan
common/dispatch.c
--
case ARPHRD_TUNNEL:
/* ignore tunnel interface */
break;
--
After this done, compile DHCP per the instructions in the README
The other problem is that the automatic startup documented above does not work. They are looking at why now. There is a workaround. It is as follows:
Create a rc.ipsec in the rc.d directory. For each connection add the following to it:
ipsec auto [connection name] add
ipsec auto [connection name] up
...[eof]
Set the file permissions to rwx-------. Then run it from the rc.local
You have to allow the IPSEC traffic through your IPFWADM/IPCHAINS firewall rule sets. Port 500 is the key negotiation daemon. The ISAKMP tool does the key negotiation and then passes the keys to the daemon that runs the VPN. In FreeSwan, the daemons are called Klips and Pluto respectively.
Once you run the "ipsec auto [connection name] add" there is an interface called ipsec0, ipsec1, etc.
According to the programmer, port 92 is used in both directions, but when I set up my rules this way, I cannot get the tunnel up, so I'm going to do some more packet captures. After further investigation, I found the following rules to work:
NOTE: "other end's IP" is the remote VPN machine' Internet (external) IP address "this end's IP" is the local VPN machine's Internet (external) IP address
IPFWADM 2.0.x kernels:
--
## Inbound Ruleset
/sbin/ipfwadm -I -a accept -b -W $EXTIF -P udp -S [other end's IP] isakmp -D $EXTIP isakmp
## Outbound rule set
/sbin/ipfwadm -O -a accept -b -W $EXTIF -P udp -S $EXTIP isakmp -D [other end's IP] isakmp
--
IPCHAINS 2.2.x kernels:
--
## Inbound Ruleset
/sbin/ipchains -A input -j ACCEPT -i $EXTIF -p udp -s [other end's IP] isakmp -d $EXTIP isakmp
## Outbound Ruleset
/sbin/ipchains -A output -j ACCEPT -i $EXTIF -p udp -s $EXTIP isakmp -d [other end's IP] isakmp
--