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 with links to HTML versions of the pages themselves. The pages are of course also available via the man command.
For configuration, the critical pages are ipsec(8) and ipsec.conf(5).
Consider a pair of subnets, each with a security gateway, connected via the Internet:
192.168.100.0/24 subnet | 192.168.100.1 North Gateway 101.101.101.101 | [Internet] | 202.202.202.202 South gateway 192.168.200.1 | 192.168.200.0/24 subnetA tunnel specification such as:
conn northnet-southnet left=101.101.101.101 leftsubnet=192.168.100.0/24 leftfirewall=yes right=202.202.202.202 rightsubnet=192.168.200.0/24 rightfirewall=yeswill allow machines on the two subnets to talk to each other. You might test this by pinging from polarbear (192.168.100.7) to penguin (192.168.200.5).
However, this does not cover other traffic you might want to secure. To handle all the possibilities, you might also want these connection descriptions:
conn northgate-southnet left=101.101.101.101 right=202.202.202.202 rightsubnet=192.168.200.0/24 rightfirewall=yes conn northnet-southgate left=101.101.101.101 leftsubnet=192.168.100.0/24 leftfirewall=yes right=202.202.202.202Without these, neither gateway can do IPSEC to the remote subnet. There is no IPSEC tunnel or eroute set up for the traffic.
In our example, with the non-routable 192.168.* addresses used, packets would simply be discarded. In a different configuration, with routable addresses for the remote subnet, they would be sent unencrypted since there would be no IPSEC eroute and there would be a normal IP route.
You might also want:
conn northgate-southgate left=101.101.101.101 right=202.202.202.202This is required if you want the two gateways to speak IPSEC to each other.
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.
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.
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.
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:
also=samplesep-keyswhich 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.*.confwhich 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.
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.
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 ways
It is incomplete. If you must deal with some situation not
covered here, please post to the
mailing list.
Extruded 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.
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.
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.
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.
conn whatever left=101.101.101.101 leftnexthop=101.101.101.1 leftsubnet=192.168.73.0/24 leftfirewall=yes right=0.0.0.0You do not set rightnexthop here: the server (left) neither knows nor needs to know that.
Nor do you set rightsubnet. When 0.0.0.0 is used as "right", and an incoming connection request matches this connection, then the actual values used for both gateway and subnet on that end are set up from the IP address on the incoming packets.
You also need to create a secret for those warriors. For example, /etc/ipsec.secrtets might have the line:
101.101.101.101 0.0.0.0 "ffhffkfyuurdsdfdsrehj98753207865v"
conn whatever left=101.101.101.101 leftnexthop=101.101.101.1 leftsubnet=192.168.73.0/24 leftfirewall=yes right=202.202.202.202 rightsubnet=202.202.202.202 rightnexthop=202.202.202.1
Note that these right* values must be changed whenever your connection changes.
On this end, the secret appears as:
101.101.101.101 202.202.202.202 "ffhffkfyuurdsdfdsrehj98753207865v"Again, the IP address in the file must be changed whenever the connection changes.
Here is a mailing list message about another way to configure for road warrior support:
Subject: Re: linux-ipsec: understanding the vpn Date: Thu, 28 Oct 1999 10:43:22 -0400 From: Irving Reid <irving@nevex.com> > local-------linux------internet------mobile > LAN box user > ... > now when the mobile user connects to the linux box > it is given a virtual IP address, i have configured it to > be in the 10.x.x.x range. mobile user and linux box > have a tunnel between them with these IP addreses. > Uptil this all is fine. If it is possible to configure your mobile client software *not* to use a virtual IP address, that will make your life easier. It is easier to configure FreeS/WAN to use the actual address the mobile user gets from its ISP. Unfortunately, some Windows clients don't let you choose. > what i would like to know is that how does the mobile > user communciate with other computers on the local > LAN , ofcourse with the vpn ? > what IP address should the local LAN > computers have ? I guess their default gateway > should be the linux box ? and does the linux box need > to be a 2 NIC card box or one is fine. As someone else stated, yes, the Linux box would usually be the default IP gateway for the local lan. However... If you mobile user has software that *must* use a virtual IP address, the whole picture changes. Nobody has put much effort into getting FreeS/WAN to play well in this environment, but here's a sketch of one approach: Local Lan 1.0.0.0/24 | +- Linux FreeS/WAN 1.0.0.2 | | 1.0.0.1 Router | 2.0.0.1 | Internet | | 3.0.0.1 Mobile User Virtual Address: 1.0.0.3 Note that the Local Lan network (1.0.0.x) can be registered, routable addresses. Now, the Mobile User sets up an IPSec security association with the Linux box (1.0.0.2); it should ESP encapsulate all traffic to the network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key negotiation, which needs to work outside of the IPSec tunnel. On the Linux side, there's a bunch of stuff you need to do by hand (for now). FreeS/WAN should correctly handle setting up the IPSec SA and routes, but I haven't tested it so this may not work... The FreeS/WAN conn should look like: conn mobile right=1.0.0.2 rightsubnet=1.0.0.0/24 rightnexthop=1.0.0.1 left=0.0.0.0 # The infamous "road warrior" leftsubnet=1.0.0.3/32 Note that the left subnet contains *only* the remote host's virtual address. Hopefully the routing table on the FreeS/WAN box ends up looking like this: % netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 1.0.0.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo 0.0.0.0 1.0.0.1 0.0.0.0 UG 1500 0 0 eth0 1.0.0.3 1.0.0.1 255.255.255.255 UG 1433 0 0 ipsec0 So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should get bundled up and sent through the tunnel. To get the packets for 1.0.0.3 to the Linux box in the first place, you need to use "proxy ARP". How this works is: when a host or router on the local Ethernet segment wants to send a packet to 1.0.0.3, it sends out an Ethernet level broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would reply, saying "send IP packets for 1.0.0.3 to my Ethernet address". Instead, you need to set up the Linux box so that _it_ answers ARP requests for 1.0.0.3, even though that isn't its IP address. That convinces everyone else on the lan to send 1.0.0.3 packets to the Linux box, where the usual FreeS/WAN processing and routing take over. % arp -i eth0 -s 1.0.0.3 -D eth0 pub This says, if you see an ARP request on interface eth0 asking for 1.0.0.3, respond with the Ethernet address of interface eth0. Now, as I said at the very beginning, if it is *at all* possible to configure your client *not* to use the virtual IP address, you can avoid this whole mess.
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.
chkconfig --level 2345 ipsec offThat'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.
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
ipsec setup startwhile if it was, do
ipsec setup restartwhich won't be as quick.
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
ipsec setup restartAgain, this breaks any existing connections.
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.