This section gives an overview of:
This section is intended to cover only the essentials, things you should know before trying to use FreeS/WAN.
For more detailed background information, see the history and politics and IPsec protocols sections.
FreeS/WAN is a Linux implementation of the IPsec (IP security) protocols. IPsec provides encryption and authentication services at the IP (Internet Protocol) level of the network protocol stack.
Working at this level, IPsec can protect any traffic carried over IP, unlike other encryption which generally protects only a particular higher-level protocol -- PGP for mail, SSH for remote login, SSL for web work, and so on. This approach has both considerable advantages and some limitations. For discussion, see our IPsec section
IPsec can be used on any machine which does IP networking. Dedicated IPsec gateway machines can be installed wherever required to protect traffic. IPsec can also run on routers, on firewall machines, on various application servers, and on end-user desktop or laptop machines.
Three protocols are used
Our implementation has three main parts:
IPsec is optional for the current (version 4) Internet Protocol. FreeS/WAN adds IPsec to the Linux IPv4 network stack. Implementations of IP version 6 are required to include IPsec. Work toward integrating FreeS/WAN into the Linux IPv6 stack has started.
For more information on IPsec, see our IPsec protocols section, our collection of IPsec links or the RFCs which are the official definitions of these protocols.
IPsec is designed to let different implementations work together. We provide:
The VPN Consortium fosters cooperation among implementers and interoperability among implementations. Their web site has much more information.
Because IPsec operates at the network layer, it is remarkably flexible and can be used to secure nearly any type of Internet traffic. Two applications, however, are extremely widespread:
There is enough opportunity in these applications that vendors are flocking to them. IPsec is being built into routers, into firewall products, and into major operating systems, primarily to support these applications. See our list of implementations for details.
We support both of those applications, and various less common IPsec applications as well, but we also add one of our own:
This is an extension we are adding to the protocols. FreeS/WAN is the first prototype implementation, though we hope other IPsec implementations will adopt the technique once we demonstrate it. See project goals below for why we think this is important.
A somewhat more detailed description of each of these applications is below. Our quickstart section will show you how to build each of them.
A VPN, or Virtual Private N etwork lets two networks communicate securely when the only connection between them is over a third network which they do not trust.
The method is to put a security gateway machine between each of the communicating networks and the untrusted network. The gateway machines encrypt packets entering the untrusted net and decrypt packets leaving it, creating a secure tunnel through it.
If the cryptography is strong, the implementation is careful, and the administration of the gateways is competent, then one can reasonably trust the security of the tunnel. The two networks then behave like a single large private network, some of whose links are encrypted tunnels through untrusted nets.
Actual VPNs are often more complex. One organisation may have fifty branch offices, plus some suppliers and clients, with whom it needs to communicate securely. Another might have 5,000 stores, or 50,000 point-of-sale devices. The untrusted network need not be the Internet. All the same issues arise on a corporate or institutional network whenever two departments want to communicate privately with each other.
Administratively, the nice thing about many VPN setups is that large parts of them are static. You know the IP addresses of most of the machines involved. More important, you know they will not change on you. This simplifies some of the admin work. For cases where the addresses do change, see the next section.
The prototypical "Road Warrior" is a traveller connecting to home base from a laptop machine. Administratively, most of the same problems arise for a telecommuter connecting from home to the office, especially if the telecommuter does not have a static IP address.
For purposes of this document:
These require somewhat different setup than VPN gateways with static addresses and with client systems behind them, but are basically not problematic.
There are some difficulties which appear for some road warrior connections:
In most situations, however, FreeS/WAN supports road warrior connections just fine.
One of the reasons we are working on FreeS/WAN is that it gives us the opportunity to add what we call opportuntistic encryption. This means that any two FreeS/WAN gateways will be able to encrypt their traffic, even if the two gateway administrators have had no prior contact and neither system has any preset information about the other.
Both systems pick up the authentication information they need from the DNS (domain name service), the service they already use to look up IP addresses. Of course the administrators must put that information in the DNS, and must set up their gateways with opportunistic encryption enabled. Once that is done, everything is automatic. The gateways look for opportunities to encrypt, and encrypt whatever they can. Whether they also accept unencrypted communication is a policy decision the administrator can make.
This technique can give two large payoffs:
Opportunistic encryption is not (yet?) a standard part of the IPsec protocols, but an extension we are proposing and demonstrating. For details of our design, see links below.
Only one current product we know of implements a form of opportunistic encryption. Secure sendmail will automatically encrypt server-to-server mail transfers whenever possible.
A complication, which applies to any type of connection -- VPN, Road Warrior or opportunistic -- is that a secure connection cannot be created magically. There must be some mechanism which enables the gateways to reliably identify each other. Without this, they cannot sensibly trust each other and cannot create a genuinely secure link.
Any link they do create without some form of authentication will be vulnerable to a man-in-the-middle attack. If Alice and Bob are the people creating the connection, a villian who can re-route or intercept the packets can pose as Alice while talking to Bob and pose as Bob while talking to Alice. Alice and Bob then both talk to the man in the middle, thinking they are talking to each other, and the villain gets everything sent on the bogus "secure" connection.
There are two ways to build links securely, both of which exclude the man-in-the middle:
Automatic keying is much more secure, since if an enemy gets one key only messages between the previous re-keying and the next are exposed. It is therefore the usual mode of operation for most IPsec deployment, and the mode we use in our setup examples. FreeS/WAN does support manual keying for special circumstanes. See this section.
For automatic keying, the two systems must authenticate each other during the negotiations. There is a choice of methods for this:
Public key techniques are much preferable, for reasons discussed later, and will be used in all our setup examples. FreeS/WAN does also support auto-keying with shared secret authentication. See this section.
For complete information on the project, see our web site, freeswan.org.
In summary, we are implementing the IPsec protocols for Linux and extending them to do opportunistic encryption.
Our overall goal in FreeS/WAN is to make the Internet more secure and more private.
Our IPsec implementation supports VPNs and Road Warriors of course. Those are important applications. Many users will want FreeS/WAN to build corporate VPNs or to provide secure remote access.
However, our goals in building it go beyond that. We are trying to help build security into the fabric of the Internet so that anyone who choses to communicate securely can do so, as easily as they can do anything else on the net.
More detailed objectives are:
If we can get opportunistic encryption implemented and widely deployed, then it becomes impossible for even huge well-funded agencies to monitor the net.
See also our section on history and politics of cryptography, which includes our project leader's rationale for starting the project.
Two of the team are from the US and can therefore contribute no code:
The rest of the team are Canadians, working in Canada. ( Why Canada?)
The project is funded by civil libertarians who consider our goals worthwhile. Most of the team are paid for this work.
People outside this core team have made substantial contributions. See
Additional contributions are welcome. See the FAQ for details.
Unfortunately the export laws of some countries restrict the distribution of strong cryptography. FreeS/WAN is therefore not in the standard Linux kernel and not in all CD or web distributions.
FreeS/WAN is, however, quite widely used. Products we know of that use it are listed below. We would appreciate hearing, via the mailing lists, of any we don't know of.
FreeS/WAN is included in various general-purpose Linux distributions, mostly from countries (shown in brackets) with more sensible laws:
For distributions which do not include FreeS/WAN and are not Redhat (which we develop and test on), there is additional information in our compatibility section.
The server edition of Corel Linux (Canada) also had FreeS/WAN, but Corel have dropped that product line.
FreeS/WAN is also included in several distributions aimed at the market for turnkey business servers:
Several distributions intended for firewall and router applications include FreeS/WAN:
There are also several sets of scripts available for managing a firewall which is also acting as a FreeS/WAN IPsec gateway. See this list.
Several vendors use FreeS/WAN as the IPsec component of a turnkey firewall or VPN product.
Software-only products:
Products that include the hardware:
Rebel.com, makers of the Netwinder Linux machines (ARM or Crusoe based), had a product that used FreeS/WAN. The company is in receivership so the future of the Netwinder is at best unclear. PKIX patches for FreeS/WAN developed at Rebel are listed in our web links document.
For some distributions which do not include FreeS/WAN, it may be possible to install using RPM (Redhat Package Manager), rather than going through our more complex procedure.
Some caution is required on this. The RPMs are specific to a Linux distribution and an attempt to use them on another distribution is likely to cause problems.
RPMs for FreeS/WAN 1.91 and Red Hat 7.1 or 7.2 are available for download from Steamballoon. Check there for later versions.
As of version 1.93, the FreeS/WAN distribution incorporates some of the Steamballoon work, providing a facility for building your own RPMs. Details are in our installation document.
FreeS/WAN documentation up to version 1.5 was available only in HTML. Now we ship two formats:
and provide a Makefile to generate other formats if required:
The Makefile assumes the htmldoc tool is available. You can download it from Easy Software.
All formats should be available at the following websites:
The distribution tarball has only the two HTML formats.
Note: If you need the latest doc version, for example to see if anyone has managed to set up interoperation between FreeS/WAN and whatever, then you should download the current snapshot. What is on the web is documentation as of the last release. Snapshots have all changes I've checked in to date.
As with most things on any Unix-like system, most parts of Linux FreeS/WAN are documented in online manual pages. We provide a list of FreeS/WAN man pages, with links to HTML versions of them.
The man pages describing configuration files are:
Man pages for common commands include:
You can read these either in HTML using the links above or with the man(1) command.
In the event of disagreement between this HTML documentation and the man pages, the man pages are more likely correct since they are written by the implementers. Please report any such inconsistency on the mailing list.
Text files in the main distribution directory are README, INSTALL, CREDITS, CHANGES, BUGS and COPYING.
The Libdes encryption library we use has its own documentation. You can find it in the library directory..
Throughout this documentation, I write as if the reader had at least a general familiarity with Linux, with Internet Protocol networking, and with the basic ideas of system and network security. Of course that will certainly not be true for all readers, and quite likely not even for a majority.
However, I must limit amount of detail on these topics in the main text. For one thing, I don't understand all the details of those topics myself. Even if I did, trying to explain everything here would produce extremely long and almost completely unreadable documentation.
If one or more of those areas is unknown territory for you, there are plenty of other resources you could look at:
Also, I do make an effort to provide some background material in these documents. All the basic ideas behind IPsec and FreeS/WAN are explained here. Explanations that do not fit in the main text, or that not everyone will need, are often in the glossary , which is the largest single file in this document set. There is also a background file containing various explanations too long to fit in glossary definitions. All files are heavily sprinkled with links to each other and to the glossary. If some passage makes no sense to you, try the links.
For other reference material, see the bibliography and our collection of web links.
Of course, no doubt I get this (and other things) wrong sometimes. Feedback via the mailing lists is welcome.
Until quite recently, there was only one FreeS/WAN mailing list, and archives of it were:
The two archives use completely different search engines. You might want to try both.More recently we have expanded to five lists, each with its own archive.
More information on mailing lists.
Various user-written HowTo documents are available. The ones covering FreeS/WAN-to-FreeS/WAN connections are:
User-wriiten HowTo material may be especially helpful if you need to interoperate with another IPsec implementation. We have neither the equipment nor the manpower to test such configurations. Users seem to be doing an admirable job of filling the gaps.
Check what version of FreeS/WAN user-written documents cover. The software is under active development and the current version may be significantly different from what an older document describes.
Two design documents show team thinking on new developments:
Both documents are works in progress and are frequently revised. For the latest version, see the design mailing list. Comments should go to that list.
There is now an Internet Draft on Opportunistic Encryption by Michael Richardson, Hugh Redelmeier and Henry Spencer. This is a first step toward getting the protocol standardised so there can be multiple implementations of it. Discussion of it takes place on the IETF IPsec Working Group mailing list.
A number of papers giving further background on FreeS/WAN, or exploring its future or its applications, are also available:
Several of these provoked interesting discussions on the mailing lists, worth searching for in the archives.
There are also several papers in languages other than English, see our web links.
All code and documentation written for this project is distributed under either the GNU General Public License (GPL) or the GNU Library General Public License. For details see the COPYING file in the distribution.
Not all code in the distribution is ours, however. See the CREDITS file for details. In particular, note that the Libdes library and the version of MD5 that we use each have their own license.
FreeS/WAN is available from a number of sites.
Our primary site, is at xs4all (Thanks, folks!) in Holland:
There are also mirror sites all over the world:
Thanks to those folks as well.
There is also an archive of Linux crypto software called "munitions", with its own mirrors in a number of countries. It includes FreeS/WAN, though not always the latest version. Some of its sites are:
Any of those will have a list of other "munitions" mirrors. There is also a CD available.
For more detailed background information, see:
To begin working with FreeS/WAN, go to our quickstart guide.
This page will get you started using Linux FreeS/WAN with opportunistic encryption (OE). OE enables you to set up IPsec tunnels to a site without co-ordinating with the site administrator, and without hand configuring each tunnel. If enough sites support OE, a "FAX effect" occurs, and many of us can communicate without eavesdroppers.
Opportunistic encryption is new technology and we are still working out some fine points. Please see this list of known issues.
To set up opportunistic encryption, you will need:
Note: Only Linux FreeS/WAN supports opportunistic encryption.
Our instructions are for a recent Red Hat with a stock Red Hat kernel. For other ways to install, see our install document.
Check your kernel version with
uname -a
From our FTP site, get the kernel module which matches your kernel. For example:
freeswan-module-1.99_2.4.18_3-0.i386.rpm
Note: Our kernel modules will only work on the Red Hat kernel they were built for, since they are very sensitive to small changes in the kernel.
Get FreeS/WAN utilities to match. For example:
freeswan-1.99_2.4.18_3-0.i386.rpm
While you're at our ftp site, grab the RPM signing key
freeswan-rpmsign.asc
If you're running RedHat 8.x, import this key into the RPM database:
rpm --import freeswan-rpmsign.asc
For RedHat 7.x systems, you'll need to add it to your PGP keyring:
pgp -ka freeswan-rpmsign.asc
Check the signatures on both RPMs using:
rpm --checksig freeswan-module-1.99_2.4.18_3-0.i386.rpm
rpm --checksig freeswan-1.99_2.4.18_3-0.i386.rpm
You should see:
freeswan-module-1.99_2.4.18_3-0.i386.rpm: pgp md5 OK
freeswan-1.99_2.4.18_3-0.i386.rpm: pgp md5 OK
Become root:
su
Install your RPMs with:
rpm -ivh freeswan-module-1.99_2.4.18_3-0.i386.rpm
rpm -ivh freeswan-1.99_2.4.18_3-0.i386.rpm
Then, start FreeS/WAN:
service ipsec start
To check that you have a successful install, run:
ipsec verify
You should see at least:
Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
If any of these first four checks fails, see our troubleshooting guide.
Determine the fullest form of opportunism your system can support.
When you set yourself up as an opportunistic initiator:
Find a DNS forward domain where you can publish your key. You'll need access to the DNS zone files for that domain. For the following examples, we'll use "example.com".
Dynamic IP users take note: the domain where you place your key need not be associated with the IP address for your system, or even with your system's usual hostname.
Choose a name within that domain which you will use to identify your machine. Normally, but not always, your ID is the same as your machine name. Our machine is called xy, and we'll choose the corresponding FQDN xy.example.com.
Generate a DNS KEY record containing your system's public key with the command:
ipsec showhostkey
This command takes the contents of /etc/ipsec.secrets and reformats it into something usable by ISC's BIND. The result should look like this (with the key data trimmed down for clarity):
; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000
xy.example.com. IN KEY 0x4200 4 1 AQOF8tZ2...+buFuFn/
Change xy.example.com to your FQDN.
Insert the record into DNS, or have a system adminstrator do it for you. It may take up to 48 hours for the record to propagate, but it's usually much quicker.
Check your DNS work
ipsec verify
You ought to see something like:
Looking for forward key for xy.example.com [OK]
For this type of opportunism, only the forward key test is relevant.
If your FreeS/WAN is older than 1.98b, simply query your nameserver (here, 1.2.3.254):
dig @1.2.3.254 xy.example.com KEY
You should see (with the key again shortened):
;; ANSWER SECTION:
xy.example.com. 6835 IN KEY 16896 4 1 AQO6DJc6LIwGq82ehvIGLKn4S...
In /etc/ipsec.conf find conn me-to-anyone
Make it look like:
conn me-to-anyone
left=%defaultroute
leftrsasigkey=%dnsondemand
right=%opportunistic
rightrsasigkey=%dnsondemand
keylife=1h
rekey=no
leftid=@xy.example.com # put your ID here
auto=route # be sure this is enabled
Put your FQDN ID, preceded by an @sign, in place of @xy.example.com. Be sure auto=route is enabled.
Restart FreeS/WAN so that the new configuration takes effect:
service ipsec restart
That's it! Test your connection.
This allows you to initiate and receive opportunistic connections from one machine.
Generate a KEY record:
ipsec showhostkey
This command takes the contents of /etc/ipsec.secrets and reformats it into something usable by ISC's BIND. It will yield (with key data trimmed for clarity):
; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000 xy.example.com IN KEY 0x4200 4 1 AQOF8tZ2...+buFuFn/
Edit it to insert the IP address in reverse map format. In our example, 1.2.3.4 becomes 4.3.2.1.in-addr.arpa. The result:
; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000 4.3.2.1.in-addr.arpa. IN KEY 0x4200 4 1 AQOF8tZ2...+buFuFn/
This lets others know that this machine can receive opportunistic connections. It also lets them know that the machine is authorized to encrypt on its own behalf.
Use the command:
ipsec showhostkey --txt 1.2.3.4
where you replace 1.2.3.4 with your public IP.
The record (with key shortened) looks like:
; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
Send these records to your ISP, to be published in your IP's reverse map. It may take up to 48 hours for these to propagate, but usually takes much less time.
Test that your KEY has been published by querying your nameserver (here, 1.2.3.254):
dig @1.2.3.254 4.3.2.1.in-addr.arpa. KEY
You should see (with the key shortened for clarity):
;; ANSWER SECTION:
xy.example.com. 6835 IN KEY 16896 4 1 AQO6DJc6LIwGq82ehvIGLKn4S...
Next, test that your TXT record is visible:
dig @1.2.3.254 4.3.2.1.in-addr.arpa. TXT
You should see (with the key shortened for clarity):
;; ANSWER SECTION:
xy.example.com. 6835 IN KEY 16896 4 1 AQO6DJc6LIwGq82ehvIGLKn4S...
Find conn me-to-anyone in /etc/ipsec.conf:
Adjust it to look like:
conn me-to-anyone
left=%defaultroute
leftrsasigkey=%dnsondemand
right=%opportunistic
rightrsasigkey=%dnsondemand
keylife=1h
rekey=no
auto=route # be sure this is enabled
# Note there is NO leftid=
If you've previously configured for initiator-only opportunism, remove leftid=
#leftid=xy.example.com
Restart FreeS/WAN so that it reads the new settings:
service ipsec restart
If you are running a default install of RedHat 8.0, take note: you will need to alter your iptables rule setup to allow IPSec traffic through your firewall. See our firewall document for sample rules you can add to /etc/sysconfig/iptables to permit this.
More information.That's it. Now, test your connection.
You need these so that your Opportunistic peers can:
On the gateway, generate a TXT record with:
ipsec showhostkey --txt 1.2.3.4
Use your gateway address in place of 1.2.3.4
You should see (keys are trimmed for clarity throughout our example):
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
This MUST BE the same key as in your gateway's KEY record, or nothing will work.
In a text file, make one copy of this TXT record for each subnet node:
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
Above each entry, insert a line like this:
1.42.42.42.in-addr.arpa. IN PTR arthur.example.com
It must include:
The result will be a file full of TXT records, like this:
1.42.42.42.in-addr.arpa. IN PTR arthur.example.com
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
2.42.42.42.in-addr.arpa. IN PTR ford.example.com
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
3.42.42.42.in-addr.arpa. IN PTR trillian.example.com
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
Ask your ISP to publish these records in your reverse map.
Check a couple of records with commands like this one:
dig @1.2.3.254 1.42.42.42.in-addr.arpa. TXT
Replace 1.2.3.254 with your nameserver's IP, and 1.42.42.42.in-addr.arpa. with the reverse-format IP of one of your subnet nodes.
You should see:
ANSWER SECTION: 1.42.42.42.in-addr.arpa. 180 IN TXT "X-IPsec-Server(10)=1.2.3.4 " AQOF8tZ2...+buFuFn/"
In /etc/ipsec.conf place this before me-to-anyone :
conn subnet-to-anyone
also=me-to-anyone
leftsubnet=42.42.42.0/24
More detail.
Once again, restart FreeS/WAN to complete the configuration changes:
service ipsec restart
Proceed to the next section and test away.
The quick method is:
links oetest.freeswan.org
A thought for the paranoid -- the feds are probably watching that site. You should see:
You seem to be connecting from: 1.2.3.4 which DNS says is:
xy.example.com
_________________________________________________________________
Status E-route
OE enabled 16 192.139.46.73/32 -> 1.2.3.4/32 =>
tun0x2097@1.2.3.5
OE enabled 176 192.139.46.77/32 -> 1.2.3.4/32 =>
tun0x208a@1.2.3.5
If you do not see this, see this section of the FAQ.
Congratulations! Your machine will now encrypt whenever it can.
If you haven't already, read up on our known issues, below. Or, proceed to make some vpn connections.
This firewalling information supplements our quickstart guide.
It includes tips for firewalling:
and a list of helpful resources.
Firewall rules on a standalone system doing IPsec can be very simple.
The first step is to allow IPsec packets (IKE on UDP port 500 plus ESP, protocol 50) in and out of your gateway. A script to set up iptables(8) rules for this is:
# edit this line to match the interface you use as default route # ppp0 is correct for many modem, DSL or cable connections # but perhaps not for you world=ppp0 # # allow IPsec # # IKE negotiations iptables -A INPUT -p udp -i $world --sport 500 --dport 500 -j ACCEPT iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT # ESP encryption and authentication iptables -A INPUT -p 50 -i $world -j ACCEPT iptables -A OUTPUT -p 50 -o $world -j ACCEPT
Optionally, you could restrict this, allowing these packets only to and from a list of known gateways.
A second firewalling step -- access controls built into the IPsec protocols -- is automatically applied:
These errors are logged. See our troubleshooting document for details.
As an optional third step, you may wish to filter packets emerging from your opportunistic tunnels. These packets arrive on an interface such as ipsec0, rather than eth0, ppp0 or whatever. For example, in an iptables(8) rule set, you would use:
In this way, you can apply whatever additional filtering you like to these packets.
The packets emerging on ipsec0 are likely to be things that a client application on your machine requested: web pages, e-mail, file transfers and so on. However, any time you initiate an opportunistic connection, you open a two-way connection to another machine (or network). It is conceivable that a Bad Guy there could take advantage of your link.
For more information, read the next section.
The basic firewalling for IPsec does not change when you support incoming connections as well as connections you initiate. You must still allow IKE (UDP port 500) and ESP (protocol 50) packets to and from your machine, as in the rules given above.
However, there is an additional security concern when you allow incoming opportunistic connections. Incoming opportunistic packets enter your machine via an IPSec tunnel. That is, they all appear as ESP (protocol 50) packets, concealing whatever port and protocol characteristics the packet within the tunnel has. Contained in the tunnel as they pass through ppp0 or eth0, these packets can bypass your usual firewall rules on these interfaces.
Consequently, you will want to firewall your ipsec interfaces the way you would any publicly accessible interface.
A simple way to do this is to create one iptables(8) table with all your filtering rules for incoming packets, and apply the entire table to all public interfaces, including ipsec interfaces.
On a gateway, the IPsec-related firewall rules applied for input and output on the Internet side are exactly as shown above. A gateway exchanges exactly the same things -- UDP 500 packets and IPsec packets -- with other gateways that a standalone system does, so it can use exactly the same firewall rules as a standalone system would.
However, on a gateway there are additional things to do:
You need additional rules to handle these things. For example, adding some rules to the set shown above we get:
# edit this line to match the interface you use as default route # ppp0 is correct for many modem, DSL or cable connections # but perhaps not for you world=ppp0 # # edit these lines to describe your internal subnet and interface localnet=42.42.42.0/24 internal=eth1 # # allow IPsec # # IKE negotiations iptables -A INPUT -p udp -i $world --sport 500 --dport 500 -j ACCEPT iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT # ESP encryption and authentication iptables -A INPUT -p 50 -i $world -j ACCEPT iptables -A OUTPUT -p 50 -o $world -j ACCEPT # # packet forwarding for an IPsec gateway # simplest possible rules $ forward everything, with no attempt to filter # # handle packets emerging from IPsec # ipsec+ means any of ipsec0, ipsec1, ... iptables -A FORWARD -d $localnet -i ipsec+ -j ACCEPT # simple rule for outbound packets # let local net send anything # IPsec will encrypt some of it iptables -A FORWARD -s $localnet -i $internal -j ACCEPT
On a production gateway, you would no doubt need tighter rules than the above.
For more information, see these handy resources:
These are sample ipsec.conf(5) configuration files for opportunistic encryption, with comments. Much of this configuration will be unnecessary with the new defaults proposed for FreeS/WAN 2.x.
Full instructions for this setup are in our quickstart guide.
The ipsec.conf file for an initiate-only opportunistic setup is:
# general IPsec setup
config setup
# Use the default interface
interfaces=%defaultroute
# Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
# defaults for subsequent connection descriptions
conn %default
# How to authenticate gateways
authby=rsasig
# default is
# load connection description into Pluto's database
# so it can respond if another gatway initiates
# individual connection descriptions may override this
auto=add
# description for opportunistic connections
conn me-to-anyone
left=%defaultroute # all connections should use default route
right=%opportunistic # anyone we can authenticate
rightrsasigkey=%dns # look up their key in DNS
auto=route # set up for opportunistic
rekey=no # let unused connections die
leftid=@xy.example.com # our identity for IPSec negotiations
# must match DNS and ipsec.secrets
Normally, the last line above is the only one that you need to edit. However, some people may need to customize the interfaces= line in the "config setup" section. All other sections are identical for any standalone machine doing opportunistic encryption.
The @ sign in the leftid= makes the ID go "over the wire" as a Fully Qualified Domain Name (FQDN). Without it, an IP address would be used and this won't work.
The conn is not used to supply either public key. Your private key is in ipsec.secrets(5) and, for opportunistic encryption, the public keys for remote gateways are all looked up in DNS.
FreeS/WAN authenticates opportunistic encryption by RSA signature only, so "public key" and "private key" refer to these keys.
While the left and right designations here are arbitrary, we follow a convention of using left for local and right for remote.
Continue configuring initiate-only opportunism.
# description for opportunistic connections
conn me-to-anyone
left=%defaultroute # all connections should use default route
right=%opportunistic # anyone we can authenticate
rightrsasigkey=%dns # look up their key in DNS
auto=route # set up for opportunistic
rekey=no # let unused connections die
Note that leftid= has been removed.
Continue configuring full opportunism.
Here is our new connection, with comments:
conn us-to-office
#
# information obtained from office system admin
# goes to the right of the = signs in these lines
# values shown here are just for example
#
left=1.2.3.4 # gateway IP address
leftsubnet=42.42.42.0/24 # the office network
leftid=@gateway.example.com
# real keys are much longer than shown here
leftrsasigkey=0s1LgR7/oUM...
#
# our stuff
#
# all connections should use our default route
# also controls the source address on IPsec packets
right=%defaultroute
# our identity for IPsec negotiations
rightid=@xy.example.com
Everything else remains as it was when we had only opportunistic connections.
Return to our quickstart document.
Once you have more than one connection, you may want to design your ipsec.conf in a modular fashion. This will help you avoid retyping information. Use also= to include one full or partial connection description within another.
Here is a sample modular ipsec.conf file for our situation. Since the right... information is common to both our connections, we place it in the partial connection our_stuff, which looks like:
conn our_stuff
# all connections should use our default route
# also controls the source address on IPsec packets
right=%defaultroute
# our identity for IPsec negotiations
# must match what is in DNS and ipsec.secrets(5)
rightid=@xy.example.com
We then include this information in other conns with the line:
also=our_stuff
For this to work, conn our_stuff must come last.
The resulting modular ipsec.conf looks like:
# general IPsec setup
config setup
# Use the default interface
interfaces=%defaultroute
# Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
# description for opportunistic connections
conn me-to-anyone
also=our_stuff # our system details, stored below
left=%opportunistic # anyone we can authenticate
leftrsasigkey=%dns # look up their key in DNS
auto=route # set up for opportunistic
rekey=no # let unused connections die
# pre-configured link to office network
# added for this example
conn us-to-office
also=our_stuff # our system details, stored below
#
# information obtained from office system admin
# goes to the right of the = signs in these lines
# values shown here are just for example
#
left=1.2.3.4 # gateway IP address
leftsubnet=42.42.42.0/24 # the office network
leftid=@gateway.example.com
# real keys are much longer than shown here
leftrsasigkey=0s1LgR7/oUM...
# description of our system
# included in other connection descriptions via also= lines
# must come after the lines that use it
conn our_stuff
# all connections should use our default route
# also controls the source address on IPsec packets
right=%defaultroute
# our identity for IPsec negotiations
# must match what is in DNS and ipsec.secrets(5)
rightid=@xy.example.com
Note that you cannot put an auto=start line into an included connection like our_stuff.
Of course, if need be, you can mix modular and nonmodular elements in any ipsec.conf.
Go back to configuring a road warrior.
This is a collection of questions and answers, mostly taken from the FreeS/WAN mailing list. See the project web site for more information. All the FreeS/WAN documentation is online there.
Contributions to the FAQ are welcome. Please send them to the project mailing list.
FreeS/WAN is a Linux implementation of the IPsec protocols, providing security services at the IP (Internet Protocol) level of the network.
For more detail, see our introduction document or the FreeS/WAN project web site.
To start setting it up, go to our quickstart guide.
Our web links document has information on IPsec for other systems.
See our troubleshooting document. It may guide you to a solution. If not, see its problem reporting section.
Basically, what it says is give us the output from ipsec barf from both gateways. Without full information, we cannot diagnose a problem. However, ipsec barf produces a lot of output. If at all possible, please make barfs accessible via the web or FTP rather than sending enormous mail messages.
Use the users mailing list for problem reports, rather than mailing developers directly.
For problems involving interoperation with another IPsec implementation, try our interoperation document . If that does not help, try the mailing list. In this area, the users often know more than the developers.
Support beyond what the mailing list can provide is also available. See the next several questions.
See also these essays on How To Ask Questions The Smart Way and How to Report Bugs Effectively.
There are a number of Linux distributions or firewall products which include FreeS/WAN. See this list. Using one of these, chosen to match your requirements and budget, may save you considerable time and effort.
If you don't know your requirements, start by reading Schneier's Secrets and Lies. That gives the best overview of security issues I have seen. Then consider hiring a consultant (see next question) to help define your requirements.
If you want the help of a contractor, or to hire staff with FreeS/WAN expertise, you could:
For companies offerring support, see the next question.
Many of the distributions or firewall products which include FreeS/WAN (see this list) come with commercial support or have it available as an option.
Various companies specialize in commercial support of open source software. Our project leader was a founder of the first such company, Cygnus Support. It has since been bought by Redhat. Another such firm is Linuxcare.
The current release is the highest-numbered tarball on our distribution site. Almost always, any of the mirrors will have the same file, though perhaps not for a day or so after a release.
Unfortunately, the web site is not always updated as quickly as it should be. At time of writing, for example, 1.96 has been on the FTP site for about two weeks, but the web site still lists 1.95 as current, and the 1.96 documentation is not yet on the web site.
We are working on fixing this, but it is complicated with our team in North America, the site in Europe and everyone involved having other tasks as well.
We try to do a release in the first week of every month except January and August. We might adjust this a week either way because people are away at conferences or whatever.
If pre-release tests fail and the fix appears complex, or more generally if the code does not appear stable when a release is scheduled, we will just skip that release. This appears a better strategy than rushing complex work to produce a late release.
For serious bugs, we may bring out an extra bug-fix release. These get numbers in the normal release series. For example, there was a bug found in FreeS/WAN 1.6, so we did another release less than two weeks later. The bug-fix release was called 1.7, not something like 1.6a or 1.6.1.
Any problems we are aware of at the time of a release are documented in the BUGS file for that release. You should also look at the CHANGES file.
Bugs discovered after a release are discussed on the mailing lists. The easiest way to check for any problems in the current code would be to peruse Claudia's weekly summaries on the briefs list, archived here.
You are free to modify FreeS/WAN in any way. See the discussion of licensing in our introduction document.
Before investing much energy in any such project, we suggest that you
This may prevent duplicated effort, or lead to interesting collaborations.
Users have also contributed heavily to documentation, both by creating their own HowTos and by posting things on the mailing lists which I have quoted in these HTML docs.
There are, however, some caveats.
FreeS/WAN is being implemented in Canada, by Canadians, largely to ensure that is it is entirely free of export restrictions. See this discussion. We cannot accept code contributions from US residents or citizens, not even one-line bugs fixes. The reasons for this were recently discussed extensively on the mailing list, in a thread starting here.
Not all contributions are of interest to us. The project has a set of fairly ambitious and quite specific goals, described in our introduction. Contributions that lead toward these goals are likely to be welcomed enthusiastically. Other contributions may be seen as lower priority, or even as a distraction.
Discussion of possible contributions takes place on the design mailing list.
The only formal design documents are a few papers in the last category above. All the other categories, however, have things to say about design as well.
The IPsec protocols are designed to support interoperation. In theory, any two IPsec implementations should be able to talk to each other. In practice, it is considerably more complex. We have a whole interoperation document devoted to this problem.
An important part of that document is links to the many user-written HowTos on interoperation between FreeS/WAN and various other implementations. Often the users know more than the developers about these issues (and almost always more than me :-), so these documents may be your best resource.
Linux FreeS/WAN can interoperate with many IPsec implementations, including earlier versions of Linux FreeS/WAN itself.
In a few cases, there are some complications. See our interoperation document for details.
There is no hard limit, but see below.
There is no hard limit, but see next question.
A quick summary:
Beyond about 50 tunnels it needs careful management.
See our FreeS/WAN performance document for details.
We build and test on Redhat distributions, but FreeS/WAN runs just fine on several other distributions, sometimes with minor fiddles to adapt to the local environment. Details are in our compatibility document. Also, some distributions or products come with FreeS/WAN included.
FreeS/WAN is intended to run on all CPUs Linux supports . We know of it being used in production on x86, ARM, Alpha and MIPS. It has also had successful tests on PPC and SPARC, though we don't know of actual use there. Details are in our compatibility document.
FreeS/WAN is designed to work on any SMP architecture Linux supports, and has been tested successfully on at least dual processor Intel architecture machines. Details are in our compatibility document.
It might, but we strongly recommend using a recent 2.2 or 2.4 series kernel. Sometimes the newer versions include security fixes which can be quite important on a gateway.
Also, we use recent kernels for development and testing, so those are better tested and, if you do encounter a problem, more easily supported. If something breaks applying recent FreeS/WAN patches to an older kernel, then "update your kernel" is almost certain to be the first thing we suggest. It may be the only suggestion we have.
The precise kernel versions supported by a particular FreeS/WAN release are given in the README file of that release.
See the following question for more on kernels.
Sometimes yes, but quite often, no.
Kernel versions supported are given in the README file of each FreeS/WAN release. Typically, they are whatever production kernels were current at the time of our release (or shortly before; we might release for kernel n just as Linus releases n+1 ). Often FreeS/WAN will work on slightly later kernels as well, but of course this cannot be guaranteed.
For example, FreeS/WAN 1.91 was released for kernels 2.2.19 or 2.4.5, the current kernels at the time. It also worked on 2.4.6, 2.4.7 and 2.4.8, but 2.4.9 had changes that caused compilation errors if it was patched with FreeS/WAN 1.91.
When such changes appear, we put a fix in the FreeS/WAN snapshots, and distribute it with our next release. However, this is not a high priority for us, and it may take anything from a few days to several weeks for such a problem to find its way to the top of our kernel programmer's To-Do list. In the meanwhile, you have two choices:
We don't even try to