linux-ipsec: Another draft effort: vpn mini-howto
This is still a first draft in my opinion. I have just updated it to match
the 0.90 release of Freeswan.
--
Randy Dees | SCA: Talorgen nei Wrguist
Systems Administrator | Barony of Rhydderich Hael
Amherst Systems, Inc. | Kingdom of AEthelmearc
==============================================================================
This is a mini-howto on using the freeswan package to create a Virtual Private
Network.
This document is based in large part on installation documents contained in
the freeswan-0.90 package. Portions were originally written by Henry Spencer,
Richard Guy Briggs, and D. Hugh Redelmeier.
FreeS/WAN can be obtained from
ftp://ftp.xs4all.nl/pub/crypto/freeswan. All
development is done outside the U.S., so that the crypto can be used freely in
locations where cryptographic software is not just plain illegal.
There is a majordomo-run mailing list at linux-ipsec@clinet.fi .
Subscriptions and other maintenance commands go to majordomo@clinet.fi, not
the list. Subscription to this list is highly recommended if you are using
the software. Some of the content is highly technical as this seems to be the
developer's primary communications vehicle, but the list is helpful and quite
a bit of useful information flows there.
The utilities and kernel drivers in freeswan currently require a 2.0.3x (x>3)
kernel and will compile under libc5 or glibc2. 2.1 series kernels
introduce major networking changes and will not work with the ipsec code at
this time. The base platform for development is Red Hat 4.2 & kernel 2.0.33 -
but work is well underway to migrate to Red Hat 5.x. I had very little
trouble installing the system on a clean Red Hat 5.1 system.
Installation is relatively straightforward, although some knowledge of
cryptography seems helpful. Some effort is being made to clean up the user
interface and make commands more intuitive.
Obtain the latest release from the above site - this document uses 0.90, and
should be updated for new releases as the command syntax is likely to continue
changing as more people use and comment on the software.
This document will work from the assumption that you have just installed a
clean Red Hat 5.1 system and then applied any updates for applicable packages.
There have been many security and bugfixes since 5.1 was released that are
available from
ftp://ftp.redhat.com/pub/redhat/redhat-5.1/updates/
Ensure that you have a complete linux kernel source tree under /usr/src/linux.
I prefer to work from a clean source tree, and therefore unpack one in
/usr/src. It doesn't matter if you prefer to use the rpms, just make sure
that you have the complete tree installed. Installing kernel-headers and
kernel-source rpms from Red Hat will do that for you as well. Configure the
kernel for your system by doing:
cd /usr/src/linux
make menuconfig
(or xconfig, or just config. But configure the kernel.)
For "make install" to work, you also want to uncomment the line in
/usr/src/linux/Makefile that reads
# INSTALL_PATH=/boot
by removing the # from the beginning of the line.
Choose appropriate responses for your hardware configuration. We will be
re-configuring for freeswan in a moment, so don't worry about what is required
to make the package work quite yet.
Now unpack the freeswan package. I did:
cd /usr/src
tar xzf ~/freeswan-0.90.tar.gz
which gives you a freeswan directory at /usr/src/linux/freeswan-0.90
After unpacking, cd to the freeswan directory and do:
make
to build the user-level Klips utilities (eroute,spi,spigrp,tncfg, and
klipsdebug) and the Pluto daemon (pluto) and temporary command interface
(whack).
make install
installs those utilities in /usr/local/sbin
make setup
installs an ipsec startup script under /etc/rc.d/init.d and sets up
/etc/isakmp.secrets and /etc/sysconfig/ipsec with dummy files
make insert
inserts the Klips kernel code into the kernel source
Now reconfigure the kernel. You want to enable these options under Networking
Options:
IP: forwarding/gatewaying
IP: tunneling
Kernel/User Network Device
You may also want to enable
IP: optimize as router not host
You will also see a new entry for
IP Security Protocol (IPSEC)
enable it, and then you can enable
IPSEC: IP-in-IP encapsulation
IPSEC: Authentication Header
IPSEC: Encapsulating Security Payload
and at least one of the ESP transforms
ESP-3DES-MD5-96 transform
You can enable any of the other transforms that you like, but they are not
required to make the system functional. I recommend enabling all of the
ones that are listed, though.
I recommend that you do not enable the Experimental/Obsolete transforms
unless you know what you are doing with them. Several of them have proven
weak, most are not in current use, and the state of any of them is not
guaranteed by the developers.
Rebuild and install the kernel:
make dep clean zImage modules
make install modules_install
reboot
You now have the FreeSWan package installed - that's halfway. Now we will
configure it so that it does something useful.
FreeSWan is only supported in Tunnel configuration - that is, it requires 2
dual-homed hosts with one set of interfaces connected to each other
(presumably over another network, such as the internet) and the other set of
interfaces connected to networks behind them (yes, 1 computer is a network as
far as this is concerned.) The point is that the dual-homed hosts cannot talk
to each other over an encrypted interface yet, but only encrypt data coming
from their other interfaces. Confused?
The sample network I am using is set up as follows:
+---------+ +---------+
| site1 | | site2 |
+----*----+ +----*----+
eth0 * 172.28.1.1 eth0 * 172.29.1.1
* *
*******Local Network 1**** *****Local Network 2*****
* *
vpn1 eth0 * 172.28.1.254 eth0 * 172.29.1.254 vpn2
+----*-----+ +----*-----+
| firewl1 | | firewl2 |
+----*-----+ +----*-----+
eth1 * 192.168.2.1 eth1 * 192.168.2.254
* *
*Internet****or any other untrusted network, really***************
The objective is to connect Local Networks 1 & 2 so that site1 and site2 see
each other as being on the same network. Both networks need to exchange
sensitive information, so all traffic between them needs to be encrypted.
That is why we are using freeswan, right?
We must ensure that local network 1's route to firewl2 runs through firewl1,
and that network 2's route to firewl1 runs through firewl2. Before
configuring the freeswan package, we need to ensure that from site2 if we do a
ping firewl1 we get packets returned, and the same from site1 pinging firewl2.
The default /etc/sysconfig/network file for Red Hat 5.1 has the line
FORWARD_IPV4=false
which must be changed to true and then networking restarted in order to make
this work.
Assuming you have that working, we now have to edit the /etc/isakmp-secrets
and the /etc/sysconfig/ipsec files on both firewl machines.
The isakmp-secrets file consists of ip addresses followed by secrets used to
authenticate the Pluto daemon on the other side of the link. By default, it
has
# This file holds shared secrets which are currently the only inter-Pluto
# authentication mechanism. They are arbitrary byte strings and should
# be both long and hard to guess.
# If you give both Plutos the same secret, then this file can be used
# unchanged on both machines.
10.0.0.1 do_you_want_to_know_a_secret
10.0.0.2 do_you_want_to_know_a_secret
And we want to change the ip addresses and secrets to something we can use.
Given the above configuration, my isakmp-secrets file might have:
192.168.2.1 type_some_really_long_and_hard_to_guess_SECRET_without_whitespace_here
192.168.2.254 type_some_really_long_and_hard_to_guess_SECRET_without_whitespace_here
By keeping both secrets the same, I can use the same file on both machines.
The other file that must be configured is /etc/sysconfig/ipsec:
# /etc/sysconfig/ipsec
KLIPSDEBUG=none
KLIPSVIRTUAL=ipsec0
KLIPSPHYSICAL=eth1
# Parameters for ifconfig of $KLIPSVIRTUAL -- should really be figured
# out from those of $KLIPSPHYSICAL at startup.
KLIPSPUBADDR=10.0.0.1
KLIPSPUBBCAST=10.0.0.255
KLIPSPUBMASK=255.255.255.0
# How to start Pluto; current values are "active" for the side that starts
# the tunnel and "passive" for the side that doesn't; further values are
# expected when the process of tunnel setup becomes more automated and
# the details migrate elsewhere.
PLUTOTYPE=active
PLUTODEBUG=all
# delay (in seconds) to let Pluto get ready before tunnel setup
PLUTODELAY=3
# other Pluto's location (/etc/isakmp-secrets also knows this)
PLUTOPEER=10.0.0.2
# my private network
PLUTOCLIENT=10.0.2.0/24
# other Pluto's private network
PLUTOPEERCLIENT=10.0.1.0/24
# Type of tunnel; current useful values are "encrypt" and "authenticate".
PLUTOTUNNELTYPE=encrypt
I don't recommend changing KLIPSDEBUG - if you need to set it, use the
klipsdebug command. You probably don't want the amount of debugging
information it can produce in your syslog all the time.
Likewise, we have no need to change KLIPSVIRTUAL - in fact, changing it will
break Pluto for now.
KLIPSPHYSICAL should be set to the interface name of the public network
interface on your vpn machine. For the network configuration shown above, it
is correct as is for both firewl1 & 2.
KLIPSPUBADDR - this is the address your public interface is configured with.
On firewl1, it would be 192.168.2.1.
KLIPSPUBCAST - this is the netmask associated with the public address. Most
likely, it is the same as the address with the last number set to 255. If you
need to set it differently, you probably already know that. firewl1 uses
192.168.2.255.
KLIPSPUBMASK is most likely just fine. Like the previous variable, you should
already know if and why you need to change it. firewl1 uses it just like it
is.
PLUTOTYPE can be active or passive. One of the machines needs it to be
active, and the other passive. We'll have firewl1 set this to active, and
firewl2 set it to passive. firewl1 will therefore try to initiate the
connection when it starts up, while firewl2 would just wait.
PLUTODEBUG - This is most useful set to all or none. I recommend setting it
to none, and using whack to change it if you actually need the output. YMMV.
PLUTODELAY is the number of seconds to give Pluto to start up before
attempting to set up the tunnel. The default works fine for me on several
machines. YMMV
PLUTOPEER is the public interface of the other vpn machine. On firewl1, it
would be 192.168.2.254 - firewl2's address, and on firewl2 it is 192.168.2.1.
PLUTOCLIENT is the address of the private network that you are tunneling. On
firewl1 it is 172.28.0.0/24 and on firewl2 it is 172.29.0.0/24. It will
always match the PLUTOPEERCLIENT variable on the other end of the line.
A quick note about address specification, for those of you who have not seen
x.x.x.x/y notation before. x.x.x.x is the address of the network you are
using, and the /y tells which bits are part of the network address and which
are part of the host address. A class C address uses only 8 bits for the
network and 24 for the host, so you get 10.0.0.0/8 to identify a class C
address in network 10, 172.28.0.0/16 to identify the class B network we are
using, or 192.168.2.0/24 to identify a class C network. If you are still a
bit hazy, there is an excellent discussion of masks and this notation in
O'Reilly's TCP/IP Network Administration book.
PLUTOPEERCLIENT is addressed in the above note on PLUTOCLIENT
PLUTOTUNNELTYPE can be either encrypt or authenticate. Encrypt is most likely
what you want.
Now that you have configured the system, you just need to re-run the ipsec
initialization script and you should be set.
/etc/rc.d/init.d/ipsec restart
on both machines should do the trick.
I really need to add a debugging section here, but haven't gotten to it quite
yet.
Good luck! Have fun with your new vpn.
Randy Dees
rrd@amherst.com
199809021730
Received on Wed Sep 2 18:26:09 1998
This archive was generated by hypermail 2.1.8
: Wed Aug 23 2006 - 12:59:26 EDT
|
