We expect eventually to do it using DNS. The newer versions of
BIND
provide much of what we need but they are not yet widespread and our code
to communicate with them is not ready.
Currently Triple DES 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 AES 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.
No optional additional authentication transforms are currently
implemented and we do not forsee a need to add any soon.
Various versions of the code have run at various times on most 2.0.xx
kernels, but the current version is tested only on 2.0.38 and is
unlikely to compile on older kernels. Some of our patches for older
kernels are shipped in 2.0.37 and later, so they are no longer
provided in FreeS/WAN.
Here are some notes for an earlier SuSE version.
In Linux FreeS/WAN
Things we do, as of version 1.5:
All combinations of implemented transforms are supported.
Note that some form of authentication is recommended whenever
encryption is used.
null encryption (to use ESP as an authentication-only service)
Note that, at a March 1999 meeting, the
IETF agreed to require Triple DES and
deprecate single DES as insecure.
Not (yet) in Linux FreeS/WAN
Things we don't yet do, as of version 1.5:
None of these are in place yet.
Kernels other than 2.0.38 and 2.2.14
We develop and test on:
This is what we recommend.
Other 2.0.x Intel Kernels
We strongly recommend 2.0.38.
2.2 and 2.3 Kernels
run on some 2.3 kernels, but those are development kernels and change often.
Intel Linux distributions other than Redhat
We develop and test on Redhat 5.2 for 2.0 kernels, and on
Redhat 6.1 for 2.2, so minor changes
may be required for other distributions.
SuSE Linux
SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN included.
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.
Slackware
Subject: Re: linux-ipsec: Slackware distribution
Date: Thu, 15 Apr 1999 12:07:01 -0700
From: Evan Brewer <dmessiah@silcon.com>
> Very shortly, I will be needing to install ipsec on at least gateways that
> are running Slackware. . . .
The only trick to getting it up is that on the slackware dist there is no
init.d directory in /etc/rc.d .. so create one. Then, what I do is take the
ipsec startup script which normally gets put into the init.d directory, and
put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
in init.d. The only file in the dist you need to really edit is the
utils/Makefile, setup4:
Everything else should be just fine.
Debian
Subject: FreeS/WAN 1.0 on Debian 2.1
Date: Tue, 20 Apr 1999
From: Tim Miller <cerebus+counterpane@haybaler.sackheads.org>
Compiled and installed without error on a Debian 2.1 system
with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
/etc/init.d.
/var/lock/subsys/ doesn't exist on Debian boxen, needs to be
created; not a fatal error.
Finally, ipsec scripts appear to be dependant on GNU awk
(gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
operation appears flawless.
The scripts in question have been modified since this was posted. Awk versions
should no longer be a problem.
Debugging on Debian
There is one known glitch, described in this January 2000 message from
Pluto developer Hugh Redelmeier:
1. barf looks for pluto output in /var/log/secure (authpriv.*). Your
system (debian) puts pluto's output in /var/log/auth.log. So I
cannot see it. The simplest fix is for you to create a symlink
named /var/log/secure that points at /var/log/auth.log.
I don't know if there are other log files which require similar
trickery.
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.
Yellow Dog Linux on Power PC
Subject: Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
Date: 11 Dec 1999
From: Darron Froese <darron@fudgehead.com>
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
just x86.
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:
<ftp://ftp.yellowdoglinux.com//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
ydl.
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 <darron@fudgehead.com>
on 1/22/00 6:47 PM, Philip Trauring at philip@trauring.com wrote:
> 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:
ftp://ftp.yellowdoglinux.com//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.
Mklinux
One user reports success on the Mach-based
microkernel Linux.
Subject: Smiles on sparc and ppc
Date: Fri, 10 Mar 2000
From: Jake Hill <jah@alien.bt.co.uk>
You may or may not be interested to know that I have successfully built
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
works, mostly, with few changes.
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.
In general (there have been some glitches), FreeS/WAN has been running on Alphas
since then.
Sun SPARC processors
Several users have reported success with FreeS/WAN on SPARC Linux. Here is one
mailing list message:
Subject: Smiles on sparc and ppc
Date: Fri, 10 Mar 2000
From: Jake Hill <jah@alien.bt.co.uk>
You may or may not be interested to know that I have successfully built
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
works, mostly, with few changes.
I have a question, before I make up some patches. I need to hack
gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
trivial, but could I also use a different version of gmp? Is it vanilla
here?
I guess my only real headache is from ipchains, which appears to stop
running when IPSec has been started for a while. This is with 2.2.14 on
sparc.
This message, from a different mailing list, may be relevant for anyone
working with FreeS/WAN on Suns:
Subject: UltraSPARC DES assembler
Date: Thu, 13 Apr 2000
From: svolaf@inet.uni2.dk (Svend Olaf Mikkelsen)
To: coderpunks@toad.com
An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
file is available at http://inet.uni2.dk/~svolaf/des.htm.
This brings DES on UltraSPARC from slower than Pentium at the same
clock speed to significantly faster.
MIPS processors
We know FreeS/WAN runs on at least some MIPS processors because
Lasat (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.
IP version 6 (IPng)
In version six of the IP protocol suite, often called
IP: the next generation,
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 FAQ. 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 mailing list.
KLIPS, running on an Intel CPU, is tested against OpenBSD'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 other implementations.
A
page
on Cisco's site gave this list (early Jan 2000, before new US export regulations went into effect):
Jean-Francois Nadeau's configuration document has a
section
on PGPnet and FreeS/WAN.
The topic has also come up on the mailing list:
A post summarising some of this, from our Pluto programmer:
Some advice from the mailing list:
Jean-Francois Nadeau's configuration document has a
section on IRE-to-FreeS/WAN links.
There have also been messages on the mailing list:
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:
Published test results and HowTo documents
There are some published interoperability results:
OpenBSD
This report is from one of the OpenBSD IPSEC developers, a
regular participant on our mailing list:
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.
He has also talked of porting NetBSD's isakmpd(8) to Linux, but has (as
of late April '99) made no announcement of availability. This would
provide an alternative to our pluto(8) daemon with a somewhat different
feature set. Our KLIPS kernel code
would still be used.
FreeBSD
The only reference 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.
Cisco Routers
Subject: cisco <-> pluto IKE interop is here........
Date: Thu, 28 Jan 1999
From: Ian Calderbank
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 :-)
A later message from Ian:
This configuration is provided as-is and with no assistance or guarantee
that it works whatsover. In particular your attention is drawn to the versions
of operating systems and IPSEC that were used in the test. Configurations
for later versions of freeswan and cisco IOS may well be different.
Cisco router: 3640 (R4700 processor), ios 12.0(2a)T1), 3DES IPSEC feature set
( you do need the 3des version).
Linux box: P150, freeswan 29/jan/99 snapshot, Redhat 5.2, kernel 2.0.36.
Interconnect: 10 Base T.
Algorithm: ESP 3des/md5
CPU loadings:
Cisco 3640 : 98%
Freeswan P150 : load average: 0.08, 0.06, 0.01
Throughput: 1.1 Mbit/sec at the application layer, approx 1.2Mbit/sec, 100 packet/sec on
the external network. There were no chokes present, so the limit would
appear to be the 3640, given it was running near flat out.
--------------------------
Freeswan config:
/etc/ipsec-auto
auto ipsec-router-test
type=tunnel
left=x.x.x.x
# x.x.x.x = linux box public ip address
right=y.y.y.y
# y.y.y.y = router public ip address
rightsubnet=192.168.2.0/24
# private network behind the router - host to which throughput testing was done is here.
keyexchange=ike
encrypt=yes
authenticate=no
pfs=no
lifetime=8h
----------------------------
Cisco Router config:
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
crypto isakmp key SECRET-VALUE address x.x.x.x
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
crypto map TEST 1 ipsec-isakmp
set peer x.x.x.x
set transform-set 3DES-MD5
match address 101
access-list 101 permit ip 192.168.2.0 0.0.0.255 host x.x.x.x
interface
| Triple DES Encryption for IPSec
|
| ...
|
| This feature is supported only on the following platforms:
|
| 1720
| 2600 Series
| 3600 Series
| 4000 Series
| 4500 Series
| AS5300 Series
| 7200 Series
| 7500 Series
Nortel (Bay Networks) Contivity 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.
A later report:
Subject: Contivity Extranet Switch
Date: Fri, 11 Jun 1999
From: Matthias David Siebler <msiebler@nortelnetworks.com>
Reply-To: msiebler@alum.mit.edu
Organization: Nortel Networks
More interoperability results:
I successfully established a tunnel with a Nortel (formerly Bay (formerly New Oak)) Contivity
Extranet Switch running the latest release versions.
The CES is running V2.50 of the software and the Linux server is running V1.0.0 of the Free/SWAN
code on a RedHat 5.2 unit with the kernel upgraded to 2.0.36-3
I am using IKE with 3DES-HMAC-MD5
Note however, that tunnels cannot yet be configured as client tunnels since Free/SWAN does not yet
support aggressive mode. Hopefully, that will arrive soon, which would allow remote users to
connect to a CES using the Free/SWAN code as clients.
and apparently Nortel want their product to work with FreeS/WAN:
Subject: Is FreeSwan 3.1 a legitamate ipsec implementation when compared to its commercial competitors?
Date: Tue, 02 May 2000
From: Bill Stewart <bill.stewart@pobox.com>
Nortel's Contivity IPSEC server has a formal policy of interoperability
with FreeS/WAN. I was quite pleased to hear it when they last talked to us,
and it makes sense in their business environment, since they let you use
their WinXX client software free, so this gives them support for Linux
clients.
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.
Checkpoint Firewall-1
A PDF HowTo
for connecting FreeS/WAN and this product can be downloaded from the vendor's site or browsed
at a VPN mailing list site.
F-Secure VPN for Windows
Subject: linux-ipsec: Identification through other than IP number
Date: Tue, 13 Apr 1999
From: Thomas Bellman <bellman@signum.se>
... Currently we are trying to interop FreeS/WAN
with F-Secure VPN+ Client 4.0 (for MS Windows), and as long as
the Windows machine has a fix IP address, and are initiating the
IKE negotiations, things are working well. However, when the IP
address is changing, it doesn't work. ...
(I'll try to write something up about the problems we are having
when Pluto is initiatior in another message.)
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, PGPnet
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.
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 mailing list
for details.
Subject: PGPnet 6.5 and freeswan
Date: Sun, 16 Jan 2000
From: "D. Hugh Redelmeier" <hugh@mimosa.com>
| 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
does not.
Perhaps you are bumping into the first. In any case, look back
in the log to see why Pluto rejected each transform
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
| [a.b.c.x]
|
| [a.b.c.y]
router to internet
|
| 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
auto=add
conn subnet-rw
leftsubnet=192.168.x.0/24
right=0.0.0.0
auto=add
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 <http://jixen.tripod.com/>)
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
Press OK
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
Press Ok
Select the newly created entry for the right gateway and click ADD,
YES
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
IRE Safenet/SoftPK
IRE have an extensive line of IPSEC products, including firewall software
with IPSEC and hardware encryption devices for LAN or modem links.
Their Soft-PK is a Win 98 and NT client. We have reports only of testing
on NT.
Subject: Re: Identification through other than IP number
Date: Fri, 23 Apr 1999
From: 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 (http://www.ire.com) 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. It's also
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. No bug.
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,
when Freeswan will ;)).
Borderware
Freegate
Subject: ipsec interoperability FYI
Date: Sun, 02 May 1999
From: Sean Rooney <sean@coldstream.ca>
we've been doing some basic interoperability testing of the following;
PGP NT VPN 6.5 and freeswan both seem to work reasonably well with
Borderware 6.0 and freegate 1.3 beta. [as well as eachother]
more details coming soon.
Timestep
Subject: TimeStep Permit/Gate interop works!
Date: Thu, 10 Jun 1999
From: Derick Cassidy <dcthebrain@geek.com>
Just a quick note of success. TimeStep Permit/Gate (2520) and
Free/Swan (June 4th snapshot) interoperate!
I have them working in AUTO mode, with IKE. IPSec SA's are negotiated
with 3DES and MD5.
Here are the configs and a diagram for both configs.
left subnet---| Timestep | --- internet --- | Linux box |
The left subnet is defined as the red side of the timestep box.
This network definition MUST exist in the Secure Map.
On the Linux box:
ipsec.conf
conn timestep
type=tunnel
left=209.yyy.xxx.6
leftnexthop=209.yyy.xxx.1
leftsubnet=209.yyy.xxx.128/25
right=24.aaa.bbb.203
rightnexthop=24.aaa.bbb.1
rightsubnet=24.aaa.bbb.203/32
keyexchange=ike
keylife=8h
keyingtries=0
In the TimeStep permit/gate Secure Map
begin static-map
target "209.yyy.xxx.128/255.255.255.128"
mode "ISAKMP-Shared"
tunnel "209.yyy.xxx.6"
end
In the TimeStep Security Descriptor file
begin security-descriptor
Name "High"
IPSec "ESP 3DES MINUTES 300 or ESP 3DES HMAC MD5 MINUTES 300"
ISAKMP "IDENTITY PFS 3DES MD5 MINUTES 1440
or DES MD5 MINUTES 1440"
end
The timestep has a shared secret for 24.aaa.bbb.203/255.255.255.255
set in the Shared Secret Authentication tab of Permit/Config.
Shiva/Intel LANrover
A web page with
Shiva compatibility information.
Sun Solaris
Subject: Re: FreeS/WAN and Solaris
Date: Tue, 11 Jan 2000
From: Peter Onion <Peter.Onion@btinternet.com>
Slowaris 8 has a native (in kernel) IPSEC implementation.
I've not done much interop testing yet, but I seem to rememeber we got a manual
keyed connection between it and FreeSwan a few months ago.
Windows 2000
As for IPSEC, here is one user's report from the mailing list. For additional info,
see his website.
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.
My Setup
Freeswan :
Kernel 2.2.12 running Freeswan 1.1
Using 3DES-MD5 and PreShared Keys.
Win2000
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
IP Filter 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
IP Filter 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
***********
HINTS :
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: