Site is unavailable at this timeLinux FreeS/WAN Compatibility Guide
Most of this document is quoted directly from the Linux FreeS/WAN
Thanks very much to the community of testers, patchers and
commenters there, especially the ones quoted below but also
various contributors we haven't quoted.
implements this using the
Methods of autenticating gateways for IKE
shared secrets
stored in /etc/ipsec.secrets
RSA signatures
This was new code in
1.3. For details, see pluto(8).
looking up RSA authentication keys from .
This was new code in 1.4, and is not yet heavily tested. Note that this
technique cannot be fully secure until
is widely deployed.
encryption transforms
null encryption (to use ESP as an authentication-only service)
We implement this since the RFCs require. Since it is obviously insecure,
we disable it by default. It can be enabled with a kernel configuration
DES is in the source code since it is needed to implement 3DES, but
single DES is not made available to users because
implemented,
and used as the default encryption in Linux FreeS/WAN.
Note that, at a March 1999 meeting, the
agreed to require Triple DES and
deprecate single DES as insecure.
authentication transforms
implemented, may be used in IKE or by by AH or ESP transforms.
implemented, may be used in IKE or by AH or ESP transforms.
All combinations of implemented transforms are supported.
Note that some form of authentication is recommended whenever
encryption is used.
authenticate key negotiations via
unauthenticated key management, using
key agreement protocol without authentication. Arguably, this would be worth doing
since it is secure against all passive attacks. On the other hand, it is vulnerable
to an active .
opportunistic IPSEC tunnel creation, in which any two IPSEC aware machines can
automatically try to negotiate encryption for any communication, subject of course
to their local policies. This is a long-term goal of the Linux FreeS/WAN project, but
it requires at least one of:
a nearly universal PKI
widespread use of secure DNS
a decision to take the risks of unauthenticated keying
None of these are in place yet.
We expect eventually to do it using DNS. The newer versions of
provide much of what we need but they are not yet widespread and our code
to communicate with them is not ready.
encryption transforms
is the only
encryption method Pluto will negotiate.
No additional encryption transforms are yet implemented, though the RFCs allow them
and some other IPSEC implementations support various of them. We are not eager to
add more, since they complicate both our work and that of the gateway administrator
without any obvious security improvement.
We would certainly not want to incorporate any cryptographic method that had inadequate
key length or had not been sujected to intensive review over some time.
The winning algorithm from the
competition to choose
a successor to the DES standard will be an excellent candidate for inclusion in FreeS/WAN.
This might be a good project for a volunteer.
authentication transforms
No optional additional authentication transforms are currently
implemented and we do not forsee a need to add any soon.
Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
11 Dec 1999
Darron Froese &&
I'm summarizing here for the record - because it's taken me many hours to do
this (multiple times) and because I want to see IPSEC on more linuxes than
Also, I can't remember if I actually did summarize it before... ;-) I'm
working too many late hours.
That said - here goes.
1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
&http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2&
2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
&ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz&
3. Get the gmp src rpm from here:
&//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm&
4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
You will see a lot of text fly by and when you start to see the rpm
recompiling like this:
Executing: %build
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd gmp-2.0.2
+ libtoolize --copy --force
Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
You should add the contents of `/usr/share/aclocal/libtool.m4' to
`aclocal.m4'.
+ CFLAGS=-O2 -fsigned-char
+ ./configure --prefix=/usr
Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
cd /usr/src/redhat/BUILD/
cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
cd /usr/src/freeswan-1.1/
rm -rf gmp
mv gmp-2.0.2 gmp
5. Open the freeswan Makefile and change the line that says:
KERNEL=$(b)zimage (or something like that) to
KERNEL=vmlinux
6. cd ../linux/
7. make menuconfig
Select an option or two and then exit - saving your changes.
8. cd ../freeswan-1.1/ ; make menugo
That will start the whole process going - once that's finished compiling,
you have to install your new kernel and reboot.
That should build FreeS/WAN on ydl (I tried it on 1.1).
And a later message on the same topic:
Subject: Re: FreeS/WAN, PGPnet and E-mail
Date: Sat, 22 Jan 2000
From: Darron Froese &&
on 1/22/00 6:47 PM, Philip Trauring at
& I have a PowerMac G3 ...
The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
FreeS/WAN 1.2patch1 with a couple minor modifications:
1. In the Makefile it specifies a bzimage for the kernel compile - you have
to change that to vmlinux for the PPC.
2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
compile. I have gotten around this by getting the gmp src rpm from here:
//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
If you rip the source out of there - and place it where the gmp source
resides it will compile just fine.
(who host our freeswan.org web
site) manufacture an IPSEC box based on an embedded MIPS running
Linux with FreeS/WAN. We have no details.
IPSEC is a required feature, rather than optional as it is for
the current version four.
There is a Linux implementation of IPv6 in Linux kernels 2.2 and above.
For details, see the
It does not yet support IPSEC.
FreeS/WAN is being built for the current standard, IPv4, but we are
interested in seeing it work with IPv6. Project technical lead
Henry Spencer summarized the situation, as of mid-April 2000, thus:
We are interested in IPv6 support, but so far it has been a low priority:
we've been too busy with IPv4.
(We have one volunteer contributor who's
made a start on it, ...)
and the volunteer in question writes:
Date: Mon, 17 Apr 2000
From: Gerhard Gessler &gessler@iabg.de&
I have the library of FreeSWAN 1.3 ported to support IPv6 and I'm
testing my code for IPv6 support in Pluto. I have posted some patches to
Henry (for the lib) and I'm still waiting for response.
For information more recent than that, check the .
Internet .
covers FreeS/WAN, Open BSD, KAME, Linux pipsecd, Checkpoint, Red Creek Ravlin, and Cisco IOS
Hans-Jorg Hoxer's
interoperation between FreeS/WAN, Open BSD IPSEC and Windows 98 with PGPnet
Jean-Francois Nadeau's
document covers
FreeS/WAN interoperation with Windows 2000 IPSEC, NAI PGPnet, and IRE Safenet SoftPK.
Users have tested against a number of other implementations.
kernel code
would still be used.
we have to
IPSEC for FreeBSD says their code was ported from OpenBSD. It should
therefore interoperate with us, but we have no test results on this.
on Cisco's site gave this list (early Jan 2000, before new US export regulations went into effect):
| Triple DES Encryption for IPSec
| This feature is supported only on the following platforms:
2600 Series
3600 Series
4000 Series
4500 Series
AS5300 Series
7200 Series
7500 Series
for connecting FreeS/WAN and this product can be downloaded from the vendor's site or browsed
at a VPN mailing list .
Jean-Francois Nadeau's configuration document has a
on PGPnet and FreeS/WAN.
The topic has also come up on the mailing list:
Subject: linux-ipsec: PGPnet interoperable with FreeSWAN
Date: Mon, 05 Apr :13 -0700
From: Will Price &&
linux-ipsec@clinet.fi
Network Associates announced PGP 6.5 today.
It includes a new product
PGPnet which is a full IKE/IPSec client implementation.
This product
is for Windows and Macintosh.
I just wanted to send a brief note to
this list that the product was compatibility tested with FreeSWAN
prior to its release, and the tests were successful!
Freeware versions of PGPnet for non-commercial use should be available
by the end of the quarter.
Only the commercial Windows NT version is
available today.
95/98/Mac will be available by the end of the
PGPnet is the first IKE product to support authentication with OpenPGP
It also supports X.509 certs from VeriSign, NetTools, and
The FreeSWAN interop test was obviously done using Shared
Full source code will of course be made available after we finish all
the builds.
If you'd like more information, we had a lot of press
releases today, and our website has some information although it is
still partially being updated.
Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.
Various users have reported various successes and problems talking
to PGPnet with FreeS/WAN. There has also been a fairly complex discussion
of some fine points of RFC interpretation between the implementers of the
two systems. Check an archive of our
for details.
A post summarising some of this, from our Pluto programmer:
Subject: PGPnet 6.5 and freeswan
Date: Sun, 16 Jan 2000
From: "D. Hugh Redelmeier" &&
| From: Yan Seiner
| OK, I'm stumped.
I am trying to configure IPSEC to support road
| warriors using PGPnet 6.5.
| I've set up everything as per the man pages on the ipsec side.
| I've set up everything on the PGPnet side per the docs for that package.
| Pluto fails with this:
| Jan 16 08:14:11 aphrodite Pluto[26401]: "homeusers" #8: no acceptable
| Oakley Transform
| and then it terminates the connection.
As far as I can tell/remember, there are three common ways that PGPnet
and FreeS/WAN don't get along.
1. PGPnet proposes a longer lifetime for an SA than Pluto is willing
to accept.
2. After rekeying (i.e. after building a new SA bundle because the old
one is about to expire), FreeS/WAN immediately switches to the new
one while PGPnet continues using the old
3. FreeS/WAN defaults to expecting Perfect Forward Secrecy and PGPnet
Perhaps you are bumping into the first.
In any case, look back
in the log to see why Pluto rejected each transform
Some advice from the mailing list:
Subject: Re: Secure Gate Fails- PGPNet & FreeSwan
Date: Wed, 28 Jun 2000
From: Andreas Haumer &andreas@xss.co.at&
I have a PGPnet setup running with FreeS/WAN working as secure
gateway. It works quite fine, except for a re-negotiation problem
I'm currently investigating, and in fact I have it running on some
test equipment here right now!
As I tried _several_ different non-working configuration settings
I think I know the exact _one_ which works... :-)
Here's my short "HOWTO":
FreeS/WAN version: snap1000jun25b
PGPnet: PGP Personal Privacy, Version 6.5.3
Linux: 2.2.16 with some patches
Network setup:
=============
internal subnet [192.168.x.0/24]
[192.168.x.1]
secure gateway with FreeS/WAN
router to internet
[dynamically assigned IP address]
road-warrior with PGPnet
Configuration of FreeS/WAN:
==========================
a) /etc/ipsec.conf
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
conn %default
keyingtries=1
authby=secret
left=a.b.c.x
leftnexthop=a.b.c.y
conn gw-rw
right=0.0.0.0
conn subnet-rw
leftsubnet=192.168.x.0/24
right=0.0.0.0
b) /etc/ipsec.secrets
a.b.c.x 0.0.0.0: "my very secret secret"
Note: If you are running ipchains on your secure gateway,
you have to open the firewall for all the IPsec packets
and also for traffic from your ipsec interface!
Don't masquerade the IPsec traffic!
Check your logfiles if the firewall is blocking some
important packets!
Configuration of PGPnet:
=======================
(note that there is an excellent description, including
screenshots of PGPnet, on &/&)
In short, do the following:
Launch the PGPnet configuration tool and set defaults options
=============================================================
Start - Program - PGP - PGPnet
View - Options
General Panel :
Expert Mode
Allow communications with unconfigured hosts
Require valid authentication key
Cache passphrases between logins
IKE Duration : 6h
IPsec : 6h
Advanced panel :
Selected options :
Ciphers : Tripple DES
Hashes : MD5
Diffie-Hellman : 1024 and 1536
Compression : LZS and Deflate
Make the IKE proposal :
Shared-Key - MD5 - 3DES -1024 bits on top of the list (move up)
Make the IPSec proposal :
NONE - MD5-TrippleDES -NONE on top of the list (move up)
Select Perfect Forward Secrecy = 1024 bits
Create the connection's definition.
==================================
In the Hosts panel, ADD
Name : Enter a name for the right gateway
IPaddress : Enter its IP address visible to the internet (a.b.c.x)
Select Secure Gateway
Set shared Paraphrase : enter you preshared key
Identity type : select IP address
Identity : enter 0.0.0.0
Remote Authentication : select Any valid key
Select the newly created entry for the right gateway and click ADD,
Name : Enter a name for the central subnet
IP address : Enter its network IP address (192.168.x.0)
Select Insecure Subnet
Subnet Mask : enter its subnetmask (255.255.255.0)
Press OK, YES, YES
This should be it. Note that with this configuration there is
still this re-keying problem: after 6 hours, the SA is expired
and the connection fails. You have to re-connect your connection
with PGPnet.
and a note from the team's tech support person:
Date: Thu, 29 Jun 2000
From: Claudia Schmeing
There is a known issue with PGPNet which I don't see mentioned in the docs.
It's likely related to this one, that you note on the site:
&2. After rekeying (i.e. after building a new SA bundle because the old
one is about to expire), FreeS/WAN immediately switches to the new
one while PGPnet continues using the old
The issue is: When taking down and subsequently recreating a connection,
it can appear to come up, but it is unusable because PGPNet continues
to use an old SA, which Linux FreeS/WAN no longer recognizes. The solution is
to take down the old connection using PGPNet, so that it will then
use the most recently generated SA.
on IRE-to-FreeS/WAN links.
There have also been messages on the mailing list:
Subject: Re: Identification through other than IP number
Fri, 23 Apr 1999
Tim Miller &cerebus+counterpane@haybaler.sackheads.org&
Randy Dees writes:
& Anyone know of a low-cost MS-Win client that interoperates and does not
& require purchasing a server license to get it?
SafeNet/Soft-PK from IRE () is a low-cost
client (though I don't have the exact cost available at the moment).
I've got it running on an NT4 workstation and it interoperates nicely
(in transport mode, will try tunnel later) with FreeS/WAN.
ICSA IPsec certified.
Cerebus &cerebus@sackheads.org&
A later report from a different user:
Subject: Interop.. testing. WIN32 client : Success Story
Date: Thu, 11 Nov 1999
From: Jean-Francois Nadeau &jna@microflex.ca&
You can add IRE's products in the supported, well working (and cheap)
WIN32 client. I tested it (SafeNet SoftPK 3DES) against Freeswan 1.0
and 1.1 in both tunnel and transport mode in a RoadWarrior configuration.
The software is light, non-intrusive and transparent for the user.....defenitly,
thats a good one.
The tunnel is establish on demand.
Using shared keys....but hope to use certificates with it soon (well,
Shiva compatibility information.
Windows 2000 ships with an IPSEC implementation built in. It also uses
a number of other security mechanisms which have Linux equivalents. To
integrate well with Windows 2000, you may need to look at several open
source projects other than FreeS/WAN:
Windows 2000 builds L2TP tunnels over (some of?) its IPSEC connections.
There is a Linux .
Kerberos authentication is used in Windows 2000.
is a Linux implementation of the Windows SMB
protocol, allowing disk sharing and other network services
As for IPSEC, here is one user's report from the mailing list. For additional info,
From: "Jean-Francois Nadeau" &jna@microflex.ca&
Subject: Win2000 IPsec
interop. in tunnel mode
Date: Tue, 29 Feb 2000
This was a pain.... but it worked. ;)
Win2000 Server against Freeswan 1.1 in tunnel mode is a success.
Freeswan :
Kernel 2.2.12 running Freeswan 1.1
Using 3DES-MD5 and PreShared Keys.
M$ Win2000 Advanced server patched for 3DES
Here's the setup for the Win2000 Server.
Open an MMC with the IPsec Security policy editor snap-in.
Create a new IP Security Policy.
Create 2 IP SECURITY RULES. One for inbound traffic and one for outbound trafic (see below)
Create 2 IP FILTERS. One for inbound traffic and one for outbound trafic (see below)
Assign the inbound IP SECURITY RULE to the inbound IP FILTERS, same for outbound.
Select both IP SECURITY RULES.
Select your IP Security Policy, right click and ASSIGN.
We need an example to clarify that !@#!&? logic :
In freeswan :
Conn Interop_Testing
Left=1.2.3.4
Leftsubnet=10.0.0.0/8
Right=9.8.7.6
Rightsubnet=192.168.0.0/24
In Win2000
IP Security Policy : Interop_Testing
**********
1st IP Security rule : Left_to_Right
List : Left_to_Right
Source Address = 1.2.3.4
Destination Address = A specific Subnet = 192.168.0.0 255.255.255.0
Filter Action : Request Security
Connections type : All connections
Tunnel Settings : Endpoint = 9.8.7.6
Authentication Method = PreSharedKey=yourkey
***********
**********
2nd IP Security rule : Right_to_Left
List : Right_to_Left
Source Address = 9.8.7.6
Destination Address = A specific Subnet = 10.0.0.0 255.0.0.0
Filter Action : Request Security
Connections type : All connections
Tunnel Settings : Endpoint = 1.2.3.4
Authentication Method = PreSharedKey=yourkey
***********
Do not use mirroring in your IP filters.
Move your main proposal to the top (in my case 3DES-MD5)
Enable PFS.
It worked... but a RoadWarrior configuration doesnt seems to be
possible here (must specify both Endpoints and 0.0.0.0 is not acceptable).
Jean-Francois Nadeau
Microlfex.
Click below to go to:
Beginning of