Our Setup document covers installation and setting up a simple VPN using IPSEC. If you have not yet read that, you should probably go there first.
The Setup document should get you to the point where
you have a working FreeS/WAN installation.
Of course, a working installation is not all you need for a production
system. You still have to configure it for your requirements and
circumstances. That is covered here.
RTFM
You will of course need to refer to the online manual pages for various
things. We provide an HTML list of man pages.
For configuration, the critical pages are ipsec(8) and ipsec.conf(5).
Details can be found in the ipsec.conf(5) man page. We also provide a file
of example comfigurations, doc/examples.
The most likely options are something like:
Note that Pluto does not currently
pay attention to this variable. The variable controls setup messages only.
"yes" is strongly recommended for production use
so that the keying daemon (Pluto) will
automatically re-key the connections regularly.
The ipsec-auto parameters ikelifetime, ipseclifetime and reykeywindow
give you control over frequency of rekeying.
If plutoadd is "%search", Pluto will load any connections whose
description includes "auto=add" or "auto=start".
If plutostart is "%search", Pluto will start any connections whose
description includes "auto=start".
The example assumes you are at the Reno office and will use IPSEC to
Vancouver, New York City and Amsterdam.
However, it is possible to use manual keying in production if that is
what you want to do. This might be necessary, for example, in order to
interoperate with some device that either does not provide automatic
keying or provides it in some version we cannot talk to.
Note that with manual keying all security rests with the keys.
If an adversary acquires your keys, you've had it. He or she can read
everything ever sent with those keys, including old messages he or she
may have archived. You need to be really paranoid about keys
if you're going to rely on manual keying for anything important.
See the last example in our examples file. In the /etc/ipsec.conf
"conn samplesep" section, it has the line:
Of course, any files containing keys must have 600 permissions
and be owned by root.
If you connect in this way to multiple sites, we recommend that you keep keys for
each site in a separate file and adopt some naming convention that lets you pick
them all up with a single "include" line. This minimizes the risk of losing several
keys to one error or attack and of accidentally giving another site admin keys
which he or she has no business knowing.
It is incomplete. If you must deal with some situation not
covered here, please post to the
mailing list.
If your buddy has some
unused IP addresses, in his subnet far off at the other side of the
Internet, he can loan them to you... provided that the connection between
you and him is fast enough to carry all the traffic between your machines
and the rest of the Internet. In effect, he "extrudes" a part of his
address space over the network to you, with your Internet traffic
appearing to originate from behind his Internet gateway.
The extruded addresses have to be a complete subnet. Your friend's
security gateway needs to be also his Internet gateway, so that all
traffic from the Internet to his addresses passes through the SG.
First, configure your subnet using the extruded addresses. Your security
gateway's interface to your subnet needs to have an extruded address
(possibly using a Linux virtual interface,
if it also has to have a different address). Your gateway needs to have a
route to the extruded subnet, pointing to that interface. The other
machines at your site need to have addresses in that subnet, and default
routes pointing to your gateway.
If any of your friend's machines need to talk to the extruded subnet,
they need to have a route for the extruded subnet, pointing at
his gateway.
Then set up an IPSEC subnet-to-subnet tunnel between your gateway and his,
with your subnet specified as the extruded subnet, and his subnet specified
as "0.0.0.0/0". Do it with manual keying first for testing, and then with
automatic keying for production use.
If either side was doing firewalling for the extruded subnet before
the IPSEC connection is set up, ipsec_manual and ipsec_auto
need to know about that
(via the {left|right}firewall parameters) so that it can
be overridden for the duration of the connection.
And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that is,
the whole Internet -- through the tunnel to his SG, which then sends it
onward as if it came from his subnet. When traffic for the extruded
subnet arrives at his SG, it gets sent through the tunnel to your SG,
which passes it to the right machine.
Remember that when ipsec_manual or ipsec_auto takes a connection
down, it does not undo the route it made for that connection.
This lets you take a connection down and bring up a new one, or a modified
version of the old one, without having to rebuild the route it uses and
without any risk of packets which should use IPSEC accidentally going out
in the clear. Because the route always points into KLIPS, the packets will
always go there. Because KLIPS temporarily has no idea what to do with
them (no eroute for them), they will be discarded.
If you do want to take the route down, this is what the "unroute"
operation in manual and auto is for. Just do an unroute after doing
the down.
Note that the route for a connection may have replaced an existing
non-IPSEC route. Nothing in Linux FreeS/WAN will put that pre-IPSEC
route back. If you need it back, you have to create it with the route
command.
Our current solution is a temporary expedient, likely to be
replaced by something better in the long run.
One connection may be defined for the IP address 0.0.0.0.
On getting a connection request from an address it does not
recognise, the server tries to authenticate it using the
secret for 0.0.0.0. If this succeeds, a connection is created
to the unrecognised address. For details, see ipsec_pluto(8).
This implies that all Road Warriors connecting to a server
must share the same connection description and the same
secret. On the client side, the Road Warrior must set up
the /etc/ipsec.conf file with the current IP address before
connecting.
Right now, the way to do it
is to fix the /etc/ipsec.conf file appropriately, so interfaces
reflects the new situation, and then restart the IPSEC subsystem. This does break any
existing IPSEC connections.
If IPSEC wasn't brought up at boot time, do
If some of the hardware is to be taken out, before doing that, amend the
configuration file so interfaces no longer includes it, and do
One
situation in which this comes up is when otherwise some data would
be encrypted twice. Alice wants a secure tunnel from her machine to
Bob's. Since she's behind one security gateway and he's behind
another, part of the tunnel that they build passes through the tunnel
that their site admins have built between the gateways. All of Alice
and Bob's messages are encrypted twice.
There are several ways to handle this.
Setting up connections at boot time
You can tell the system to set up connections automatically at boot time
by putting suitable stuff in /etc/ipsec.conf on both systems. The relevant
section of the file is labelled by a line reading config setup.
Use "all" for maximum information.
See ipsec_klipsdebug(8) and ipsec_pluto(8) man page for other options.
Beware that if you set /etc/ipsec.conf to enable
debug output, your system's log files may get large quickly.
This parameter is optional and defaults to "yes" if not present.
Using manual keying in production
Generally, automatic keying is preferred
over manual keying for production
use because it is more secure. Automatic keying can provide
perfect forward secrecy.
Linux FreeS/WAN provides some facilities to help with this. In particular, it is
good policy to keep keys in separate files so you can edit
configuration information in /etc/ipsec.conf without exposing keys to "shoulder
surfers" or network snoops. We support this with the "also=" and "include"
syntax in ipseconf(5).
also=samplesep-keys
which tells the "ipsec manual" script to insert the configuration description labelled
"samplesec-keys" if it can find it. The /etc/ipsec.conf file must also have a line
such as:
include ipsec.*.conf
which tells it to read other files. One of those other files then contains the
required additional data:
conn samplesep-keys
espenckey=[192 bits]
espauthkey=[128 bits]
The first line matches the label in the "also=" line, so the two indented lines are
inserted. The net effect is exactly as if the two lines providing keys had occurred
in the original file in place of the "also=" line.
Variations on IPSEC
This section of the document covers Linux FreeS/WAN configuration for
situations other than the straightforward subnet-to-subnet VPN
described in our Setup document.
Using FreeS/WAN in different waysExtruded Subnets
What we call extruded subnets are a
special case of
VPNs. For basic VPN setup information,
see the Setup document. You should
almost certainly read that and try the techniques in it before attempting
an extruded subnet.
Road Warrior support
"Road Warrior" is our term for the laptop user who needs to call
home base and wants a secure connection. The problem is that Linux
FreeS/WAN configuration files define connections by the IP
addresses involved and a Road Warrior's IP address is not known
in advance.
Dynamic Network Interfaces
Sometimes you have to cope with a situation where the network interface(s)
aren't all there at boot. The common example is notebooks with PCMCIA.
Basics
The key issue here is that the config setup section of the
/etc/ipsec.conf configuration file lists the connection between
ipsecN and hardware interfaces, in the interfaces= variable.
At any time when ipsec setup start or ipsec setup restart
is run this variable must correspond to the current real
situation. More precisely, it must not mention any hardware
interfaces which don't currently exist. The difficulty is that an
ipsec setup start
command is normally run at boot time so interfaces that are not up then are
mis-handled.
Boot Time
Normally, an ipsec setup start is run at boot time. However, if the
hardware situation at boot time is uncertain, one of two things
must be done.
chkconfig --level 2345 ipsec off
That's for modern Red Hats or other Linuxes with chkconfig. Systems which
lack this will require fiddling with symlinks in /etc/rc.d/rc?.d or the
equivalent.
interfaces=
in the configuration file. KLIPS and Pluto will be started, but won't do anything.
Change Time
When the hardware *is* in place, IPSEC has to be made aware of it.
Someday there may be a nice way to do this.
ipsec setup start
while if it was, do
ipsec setup restart
which won't be as quick.
ipsec setup restart
Again, this breaks any existing connections.
Unencrypted tunnels
Sometimes you will want to create a tunnel without encryption. The IPSEC
protocols provide two ways to do this, either using
AH without ESP
or using ESP with null encryption. With Linux FreeS/WAN, these are
currently supported for manually keyed connections, but not with
automatic keying, so we'll look at other solutions here.
Click below to go to: