Linux FreeS/WAN compatibility Guide

Sections:
Most of this document is quoted directly from the Linux FreeS/WAN mailing list at:
	linux-ipsec@clinet.fi
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.

Implemented parts of the IPSEC Specification

In general, do not expect Linux FreeS/WAN to do everything yet. This is a work-in-progress and some parts of the IPSEC specification are not yet implemented.

In Linux FreeS/WAN

Things we should do, as of version 1.0:

Not (yet) in Linux FreeS/WAN

Things we don't yet do, as of version 1.0:

Intel Linux other than Redhat 5.2 with 2.0.36 kernel

We develop and test on Redhat 5.2 with a 2.0.36 kernel. This is what we recommend.

Other 2.0.x Intel Kernels

Recent versions of the code are running on 2.0.34 and 2.0.35 machines and it can be expected to run on most 2.0.xx kernels, perhaps with minor tweaks.

2.1 and 2.2 Kernels

This code does not run on 2.1.xx or 2.2.xx kernels yet. Kernel changes since 2.0 have been large enough that fitting FreeS/WAN into the new kernel structures is not expected to be a simple task.

We do not plan to make it run on 2.1 kernels.

Conversion to 2.2 kernels is something we expect to do, likely in 1999. However, the conversion itself is not a simple job and we expect to do a major redesign of our code in the process. Do not expect this soon.

Linux distributions other than Redhat

We develop and test on Redhat 5.2 with a 2.0.36 kernel so minor changes may be required for other distributions.

SuSE Linux 5.3

Date: Mon, 30 Nov 1998
From: Peter Onion <ponion@srd.bt.co.uk>

... I got Saturdays snapshot working between my two SUSE5.3 machines at home.

The mods to the install process are quite simple.  From memory and looking at
the files on the SUSE53 machine here at work....

And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
which SUSE use to shut a service down.

A few mods in /etc/init.d/ipsec  to cope with the different places that SUSE
put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
/etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.

insert ". /etc/rc.config" to pick up the SUSE config info and use 

  if test -n "$NETCONFIG" -a "$NETCONFIG" != "YAST_ASK" ; then

to replace 

  [ ${NETWORKING} = "no" ] && exit 0

Create /etc/sysconfig  as SUSE doesn't have one.

I think that was all (but I prob forgot something)....
You may also need to fiddle initialisation scripts to ensure that /var/run/pluto.pid is removed when rebooting. If this file is present, Pluto does not come up correctly.

CPUs other than Intel

Corel Netwinder (StrongARM CPU)

Subject: linux-ipsec: Netwinder diffs
Date: Wed, 06 Jan 1999
From: rhatfield@plaintree.com

I had a mistake in my ipsec-auto, so I got things working this morning.

Following are the diffs for my changes.  Probably not the best and cleanest way 
of doing it, but it works. . . . 

These diffs are in the 0.92 distribution and any snapshot after Feb 20 1999, so these should work out-of-the-box on Netwinder.

Alpha 64-bit processors

Subject: IT WORKS (again) between intel & alpha :-)))))
   Date: Fri, 29 Jan 1999
   From: Peter Onion <ponion@srd.bt.co.uk>

Well I'm happy to report that I've got an IPSEC connection between by intel &
alpha machines again :-))

If you look back on this list to 7th of December I wrote...

-On 07-Dec-98 Peter Onion wrote:
-> 
-> I've about had enuf of wandering around inside the kernel trying to find out
-> just what is corrupting outgoing packets...
-
-Its 7:30 in the evening .....
-
-I FIXED IT  :-))))))))))))))))))))))))))))))))
-
-It was my own fault :-((((((((((((((((((
-
-If you ask me very nicly I'll tell you where I was a little too over keen to
-change unsigned long int __u32 :-)  OPSE ...
-
-So tomorrow it will full steam ahead to produce a set of diffs/patches against
-0.91 
-
-Peter Onion.

-------------------------------------------------------------------
Subject: Diifs to use a newer version on the des library.
Date: Fri, 29 Jan 1999
From: Peter Onion <ponion@srd.bt.co.uk>

Inorder to get the alpha version to work you need to use a newer version of the
des library in klips.
. . .
The newer version of the library is in the 0.92 distribution and all snapshots after Feb 20 1999.

Alpha with 2.2.x kernel version

Subject: RE: linux-ipsec: V 2.2.1
   Date: Sun, 31 Jan 1999 10:19:41 +0000 (GMT)
  From: Peter Onion <Peter.Onion@btinternet.com>

On 31-Jan-99 savages@hemp.org wrote:
 
> I am trying to port freeswan to 2.2.1. I can get the patches working, what
> now?  I also have a DEC ALPHA with ver 2.2.1 kernel

Ah !!!!  

Well unless you get the update des library I mentioned the other day, yo can
look forward to corrupt free lists and kernel crashes (In my experience anyway 
!)
This should no longer be a problem since the library has been updated in the distrubution. There will, however, likely still be problems. See below:
Subject: RE: linux-ipsec: V 2.2.1
Date: Sun, 31 Jan 1999 20:53:20 -0500 (EST)
From: Henry Spencer <henry@spsystems.net>

> > I am trying to port freeswan to 2.2.1. I can get the patches working, what
> > now?  I also have a DEC ALPHA with ver 2.2.1 kernel
>
> Well unless you get the update des library I mentioned the other day, yo can
> look forward to corrupt free lists and kernel crashes...

Unfortunately, if that "2.2.1" means what I think it does, the DES library
is the least of his problems.  Porting FreeS/WAN to the Linux 2.2 kernels
is almost certain to be a major job, involving some redesign, not just a
matter of finding and fixing minor glitches.

Interoperation with other IPSEC implementations

Developers routinely test against some other implementations.

KLIPS, running on an Intel CPU, is tested against OpenBSD 2.3's IPSEC implementation, running on a Sun SPARC machine. Since this is a different implementation on a machine with opposite byte order, this is a good initial test of interoperability.

Pluto is tested against SSH Communications Security's Internet test page.

Users have tested against a number of others.

OpenBSD

Subject: spi.c bug
   Date: Tue, 23 Feb 1999
   From: Niklas Hallqvist <niklas@appli.se>

PS.  I don't know if you have an interop list anywhere, but you should
know FreeS/WAN interops with OpenBSD both at the IPSec level and at
the IKE level.

Cisco Routers

Subject: cisco <-> pluto IKE interop is here........
   Date: Thu, 28 Jan 1999
   From: Ian Calderbank <ianc@uk.uu.net>

Ok, tried todays pluto (28 jan) snapshot against a (wait for it) 3des
cisco box, one with some more serious grunt for benchmarking when the time
comes. 

And the good news is that pluto and cisco's IKE seem to interoperate. At
the end of things both devices seem to be happy that they have IKE and
IPSEC SA's. I can't send any traffic over it cos klips seems to be broken
(peter seems to be on the case), but fundamentally, pluto seems to be
interoperable with cisco for SA negotiation.

I've attached some ipsec barf output - pluto still complains a few times,
but it gets there :-)

Bay Networks switch

Subject: Re: Interop (was spi.c bug)
   Date: Wed, 24 Feb 1999
   From: Ian Calderbank <ianc@uk.uu.net>

I've also tested against a Bay (Newoak) Contivity Extranet switch,
running v2.02.

Attempts to connect as a single user client fail completely - to be
expected, they use Aggressive mode and username/password (xauth draft I
suspect, but I can't get confirmation) for that mode, which freeswan
doesn't support yet.

Attemps to connect as a "remote network" - for which bay which uses main
mode, authenticating on IP address and password (certs are also
available), which freeswan ought to have a better chance of working at ,
also fails, however I think that could be down to the fact that my Bay
is a 1DES only box. I don't have time to get the detail of the error
messages together, but the general impressions is that the
authentication is ok and they disagree about policy.

I might be able to get strong crypto for the bay-newoak box, but it will
take me many months, and (I admit to being slightly confused by this)
I've heard it said that their 3des is only 128bit, so perhaps may not
interop with 168 bit?

I don't want to kick off the 1des/3des debate again but it should be
noted that I only got freeswan<->cisco ike/ipsec working when I got hold
of 168bit 3des code for the cisco, and left freeswan unmodified. I never
got the "downgrade to 1des" untested freeswan code mods that Hugh R
suggested on 23/12/98 to work - I gave up on them when I got hold of
3des cisco code. I obviously tried these same mods against the 1des
bay-newoak, but I have no proof that the mods were valid in the first
place, so it could have been an invalid test. Without proven 1des
freeswan code it is difficult for me to test again.

Raptor Firewall on Windows NT

Subject: Interoperability with Raptor 5 (Success!)
   Date: Wed, 06 Jan 1999 16:19:27 -0500
   From: Chuck Bushong <chuckb@chandler-group.com>

I don't know if this is useful information for anyone, but I have
successfully established a VPN between RedHat 5.1 (kernel 2.0.34) running
FreeS/WAN 0.91 and NT4 running Raptor 5.  However, Pluto does not appear
compatible with the Raptor IKE implementation.  Unfortunately, I am not in
control of the Raptor end of the tunnel to be able to continue testing
Pluto.

With full debugging turned on, I'm getting the following messages, but it
isn't preventing anything from working. . . .

Subject: RE: linux-ipsec: Interoperability with Raptor 5 (Success!)
Date: Thu, 28 Jan 1999 17:22:55 -0500
From: Chuck Bushong <chuckb@chandler-group.com>

Sorry.  I don't administer the Raptor box.
The company at the other end would have to incur expense to test it
(They use a consultant).  However, while we are on the subject,
this VPN (at least the klips end) has been up under minimal
utilization for three weeks plus without interruption.  The
machine seems very stable.  Pat yourself on the back, gentlemen.
Your beta release is more stable than certain companies' shipping
product.

Keep up the good work. 

Xedia Access Point/QVPN

Subject: linux-ipsec: Interoperability result
   Date: Mon, 15 Mar 1999 18:08:12 -0500
  From: Paul Koning <pkoning@xedia.com>

Here's another datapoint for the "FreeS/WAN interoperability
database".

I tested 0.92 against the Xedia Access Point/QVPN product, using
dynamic keying (i.e., Pluto at work).

Results: it works fine so long as you ask for 3DES.  DES and no-crypto 
modes don't work when Pluto is involved.

I did limited data testing, which seemed to be fine.  No performance
numbers yet, could do that if people are interested.

Any questions, please ask.

        paul

PGP 6.5 Mac and Windows IPSEC Client

Subject: linux-ipsec: PGPnet interoperable with FreeSWAN
   Date: Mon, 05 Apr 1999 18:06:13 -0700
   From: Will Price <wprice@cyphers.net>
    To:  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
quarter.

PGPnet is the first IKE product to support authentication with OpenPGP
keys.  It also supports X.509 certs from VeriSign, NetTools, and
Entrust.  The FreeSWAN interop test was obviously done using Shared
Secret.

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.


Click below to go to: