Contents Previous Next

Interoperation with other IPSEC implementations

Developers routinely test against some other implementations.

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.

Published test results and HowTo documents

There are some published interoperability results:

and HowTo information:

Some of these require user-contributed patches or add-ons on the FreeS/WAN end.

Interoperation with specific products

Most of the information in this section is gleaned from the mailing list. For additional information, search one of the list archives.

OpenBSD

Hans-Jorg Hoxer's HowTo covers interoperation between FreeS/WAN and Open BSD IPSEC.

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 
crypto map TEST

A page 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:
|
|     1720
|     2600 Series
|     3600 Series
|     4000 Series
|     4500 Series
|     AS5300 Series
|     7200 Series
|     7500 Series

Nortel (Bay Networks) Contivity switch

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

Raptor 5 on NT (old info)

   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. . . .

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> 

... 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.

Raptor 6 on Solaris

Subject: Re: successful interop. with Raptor 6.02 
   From: "Charles G. Griebel" <cggrieb@biw.com> 
   Date: Tue, 25 Jul 2000

On Thu, Jul 20, 2000 at 12:04:40PM -0700, Kevin Traas wrote:
> Great!  I'm just about to start looking into this as well, so any
> docs/info you can provide would be *greatly* appreciated.  Immortalize
> yourself!  Get something written and added to the compatibility.html
> file.  Many will thank you.

Can't be that hard.  I'm just a freeswan newbie who hasn't even done a FS

FS
tunnel yet :)

Anyway, I hope you find this helpful.

Chock

-------------------------------------------------------------------------------

Automatically keyed 3DES VPN between Raptor 6.02 on Solaris 2.6 (left) and
   FreeS/WAN 1.5 on 2.2.16 Intel (right)

FreeS/WAN (right) information:
-----------------------------

ipsec.conf
----------
config setup
        interfaces="ipsec0=ppp0"    # change to suite
        klipsdebug=
        plutodebug=
        plutoload=sample
        plutostart=sample

conn sample
        left=10.0.0.1
        leftnexthop=10.0.0.2
        leftsubnet=192.168.0.0/24
        right=10.1.1.1
        rightnexthop=10.1.1.1
        rightsubnet=172.16.1.0/24
        auto=add
        keyexchange=ike
        pfs=no
        lifetime=8h
        esp=3des-md5-96

ipsec.secrets
-------------
# note I haven't verified that underscores will actually work
10.0.0.1 10.1.1.1: PSK "some_long_secret_with_plenty_of_chars"

Raptor 6.02 (left) information:
------------------------------
Key Profiles:
    Name: left-external-kp-dynamic
    Type: Dynamic
    Profile Describing: local entity
    Gateway: 10.1.1.1
    Identification Type: Address
    Identification: 10.1.1.1
    ISAKMP Hash Method: MD5
    ISAKMP Authentication: Shared_Key
    Shared Secret: some_long_secret_with_plenty_of_chars
    Time Expiration: 1080

    Name: right-external-kp-dynamic
    Type: Dynamic
    Profile Describing: remote entity
    Gateway: 10.0.0.1
    Identification Type: Address
    Identification: 10.0.0.1

Secure Subnets:
    Name: left-ss-dynamic
    Address: 192.168.0.0
    Netmask: 255.255.255.0
    Key Profile: left-ss-dynamic

    Name: right-ss-dynamic
    Address: 172.16.1.0
    Netmask: 255.255.255.0
    Key Profile: right-ss-dynamic

Secure Tunnel:
    Name: left-to-right-tunnel
    Entity A: right-ss-dynamic
    Entity B: left-ss-dynamic
    Encapsulation: ISAKMP
    Filter: [none]
    Pass traffic through proxies: [unchecked]
    Use Authentication Header: [unchecked]
    Use Encryption Header: [checked]
    Data Integrity Algorithm: MD5
    Data Privacy Algorithm: 3DES

    [Advanced settings]
    Data volume timeout: 2100000
    Lifetime timeout: 480
    Inactivity timeout: 0
    Transport mode: [unchecked]
    Perfect forward secrecy: [unchecked]
    Proxy: [checked]

----
Notes: 
I made the addresses fictitious RFC1918 addresses.
I haven't tried PFS.
I had problems getting an SA with manual keying -- I think it may be with the
 SPI's.

Raptor manual keying

A mailing list suggestion from FreeS/WAN technical lead Henry Spencer:
> In the Raptor settings, there are 2 sets of data (1 for each end). Each set
> contains an SPI, 3 DES Keys and 1 MD5 hash. I only know how to include one
> set, how do I include the other set? Is the other set needed?

They may be using different keys for each direction, which is a bit
unusual for manual keying, but not impossible.  The simplest thing is
probably to just give it two identical sets of data -- that should work.
FreeS/WAN has provisions for asymmetric keys etc. in manual keying, but
that stuff is lightly documented and lightly tested.

Gauntlet firewall GVPN

Subject:  Successful interop: FreeS/WAN 1.7 

 Gauntlet Firewall GVPN 5.5
   Date: Tue, 21 Nov 2000

Sending the following to the list, at Hugh's request.

-----Original Message-----
From: Reiner, Richard 
Sent: Tuesday, November 21, 2000 11:34 AM
To: 'hugh@mimosa.com'

Hugh,

> Good.  But we don't think that you should be using our IPCOMP just
> yet.  It is flaky :-(

I've seen no anomalies, although "allow ipcomp" is on at the Gauntlet 
end.  Looking at my ipsec.conf I actually find no refereence to ipcomp. 
 I presume it is disabled by default.  In addition, reviewing my logs 
both on the Gauntlet end and the Linux end, I see nothing I can 
interpret as an indication that ipcomp was enabled during negotiation.  
So I have to correct my previous posting - I believe the link is *not* 
using ipcomp.

> This is interesting and we'd love a more complete writeup.  It should
> get incorporated into our interop documentation.

Here are the relevant bits from ipsec.conf:

config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        uniqueids=yes

conn freeswan17-gauntlet55
        auto=start
        type=tunnel
        left=1.1.1.1
        leftnexthop=1.1.1.2
        leftsubnet=10.0.1.0/24
        right=3.3.3.3
        rightnexthop=3.3.3.4
        rightsubnet=10.0.2.0/24
        authby=secret
        keyexchange=ike
        ikelifetime=480m
        auth=esp
        esp=3des-md5-96
        keylife=480m
        keyingtries=8
        pfs=no
        rekeymargin=9m
        rekeyfuzz=25%

All settings on the Gauntlet side are the same (not shown here, as GUI 
screenshots are hard to show in ASCII... and the textual format that is 
generated by the Gauntlet GUI is ugly in the extreme).

Note that ikelifetime is 1440m by default on the Gauntlet end, but 
freeswan does not support this value (max appears to be 480m), thus the 
Gauntlet end is also set to 480m to match freeswan's value.

Also worth noting: I am using the excellent Seawall scripts to manage 
ipchains configuration on the freeswan end.  It automatically generates 
a correct set of firewall rules for the link (along with doing many 
other convenient things).
For more information on Seawall (the Seattle Firewall), see that project's home page on Sourceforge.

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.)

Watchguard

We have had mailing list reports of successful interoperation between FreeS/WAN and the Watchguard firewall, using manually keyed connections.

As of mid-November 2000, the user had not got automatically keyed connections to work. Check the mailing list for more recent information.

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

Jean-Francois Nadeau's configuration document has a section 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 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!
[snip]
- -- 
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.

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" <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

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
|        [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 

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.

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.

Jean-Francois Nadeau's configuration document has a

section on IRE-to-FreeS/WAN links.

There have also been messages on the mailing list:

  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 clients

Quite a number of client programs for IPSEC on Windows are available. Many of them are listed in this piece of list mail:

 Subject: Re: Searching Windows95/98 and NT4.0 Clients for FreeS/WAN 
    From: Claudia Schmeing >claudia@coldstream.ca< 
    Date: Wed, 12 Jul 2000

F-Secure VPN+
-------------
for Win 95, 98 and NT 4.0
http://www.datafellows.com/products/vpnplus


Checkpoint SecureRemote VPN-1 4.1
---------------------------------
for Win 95, 98 and NT
http://www.checkpoint.com/techsupport/freedownloads.html


Raptor Firewall, Raptor MobileNT 5.0
-------------------------------------
Mobile NT is a "Client"* for Win 95, 98 (except SE), First Edition Windows NT 
up to Service Pack 4. It ships with DES; triple DES may be available as an 
add-on depending on your location.

Firewall is for Win NT 4.0 or Win 2000.
http://www.axent.com


IRE SafeNet SoftPK
------------------
a "Client" for Win 95, 98 and NT 4.0 *
http://www.ire.com


Xedia's AccessPoint QVPN "Client" or "Builder"
----------------------------------------------
"Builder" is for NT
"Client" is for Win 98 *
http://www.xedia.com

* "Client" in this context indicates software that does not support a subnet
behind its end of the connection.

That mail omits the PGPnet client because the user asking the question already knew of it.

Windows 2000

Windows 2000 ships with an IPSEC implementation built in. There may be restrictions. We have had mailing list reports that only the server version will act as a gateway, working with a subnet behind it, and other versions offer only "client" functionality, with no subnet. We are unclear on details.

Some versions of Windows 2000 ship with only weak encryption. You need to upgrade them with the strong encryption pack, available either via the Windows 2000 update service or from Microsoft's web site.

Windows 2000 IPSEC sometimes exhibits remarkably odd behaviour. It will allow you to configure it for 3DES only, then ignore your settings and fall back to single DES in some circumstances. Microsoft have said they will fix this. See this Wired article.

We know of one bug report for the strong encryption upgrade. It is fixed in service pack one. You should of course check for later reports or ones we missed.

Other Linux services related to Win 2000

Windows 2000 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:

FreeS/WAN-to-Win2000 interop

As for IPSEC, there are some web sites:

Here is a discussion from the mailing list:

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.

Contents Previous Next