The IPSEC protocols are designed to allow interoperation between different implementations. Other sections of this documentation have more detail on:
FreeS/WAN does interoperate successfully with many other implementations. The ones we know about are listed below.
Of course "the devil is in the details" and the IPSEC protocols have a lot of details. At least one critique has argued that the protocols should be simplified. Various of those details can and do cause difficulties for interoperation. Should you encounter such problems, please let us know via the mailing list. We will likely be able to help you, and your report may be useful both to other users and to the implementation teams.
Note: This file is updated often, whenever I notice an interesting interop report on the mailing list. If you are reading the version that ships with a FreeS/WAN release or is posted on the web, and what you need isn't here, consider downloading the latest snapshot to get the latest version of the doc. Perhaps I've added what you need since the last release.
There is additional information on interoperability testing in our web links section.
For example, unmodified FreeS/WAN cannot use RSA keys generated by PGP or keys stored in X.509 certificates, but patches or utilities are available for both those formats. See this list of patches and add-ons.
The IPSEC RFCs are complex and include a number of optional features. There is considerable opportunity for even two correct, standard-conforming, implementations to disagree on details in a way that blocks interoperation. Of course, misinterpretations of the standards and implementation or configuration errors on either end can also foul things up.
That said, FreeS/WAN interoperates successfully with many other implementations. There is a list below.
Known areas where problems may appear are:
In principle this should not be a problem since main mode support is required in all implementations and aggressive mode is optional. In practice, it is sometimes a problem. Some implementations default to aggressive mode unless you configure them for main mode.
You can turn PFS off in FreeS/WAN with the pfs=no setting in ipsec.conf(5), but if possible we suggest you enable it on the other end instead. That is more secure.
The general rule is that to interoperate with FreeS/WAN, the other implementation should be configured for:
This is possible for most implementations.
Linux FreeS/WAN does not support single DES transforms. Neither Pluto's IKE connections nor KLIPS' IPSEC connections can use DES. Since DES is insecure we do not, and will not at any future time, provide it.
DES is, unfortunately, a mandatory part of the IPSEC standard. Despite that, we will not implement DES. We believe it is more important to provide security than to comply with a standard which has been subverted into allowing weak algorithms. See our history and politics section for discussion.
Some implementations may offer DES as the default. In such cases we urge you to change them to Triple DES. If this is not possible, for example because export laws prevent your vendor from offerring you adequate crytography, we urge you to complain vigorously to one or more of:
Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES now.
FreeS/WAN does have DES code in it as a sort of historical accident, since we need it to implement our default (currently, our only) block cipher, Triple DES. However, since DES is insecure, we do not provide any interface to that code.
As a matter of project policy, we will not help anyone subvert FreeS/WAN to provide insecure DES encryption.
The FreeS/WAN team does not have the resources to test with anything like the full range of other IPSEC implementations out there. Fortunately, some of our users are doing a fine job of filling the gap by providing HowTo information:
See also our list of available patches and add-ons.
Most of the information in this section is gleaned from the mailing list. For additional information, search one of the list archives.
A large thank you is in order to all the list contributors. This document would not exist without you.
Anyone who has tested with an implementation not listed here, please report results to the mailing list. I generally include the sender's email address when I quote list messages here; "credit where credit is due". If you would prefer that I not do that with yours, please mention that.
However, if you do encounter a problem involving an older version, we are likely to suggest you upgrade. We do not have the resources to support multiple versions.
The FAQ also discusses this.
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.
The OpenBSD FAQ includes information on their IPSEC implementation.
The only reference we have to IPSEC for FreeBSD says their code was ported from OpenBSD.
Here is a mailing list message on FreeBSD interoperation:
Subject: Re: Interop with [Free|Open|Net]BSD Date: Fri, 29 Dec 2000 From: Ghislaine Labouret <Ghislaine.Labouret@hsc.fr> On Thu, 28 Dec 2000 13:53:01 -0500, Sandy Harris wrote: > FreeBSD: > > For FreeBSD, I find list discussion of 3DES key formats, presumably for manual > keying. We have 192-bit, 3 64-bit keys including parity bits, while FreeBSD 4.0 > used 168-bit, 3 56-bit keys without the parity bits. Has FreeBSD changed this? I still don't understand what made Spike Gronim say that KAME wants a 168 bits key; I have always been using 192 bits keys with KAME and had no interoperability problem between KAME and FreeS/WAN using manual keying. > For auto keying, I find reports of sucessful use of pre-shared secrets, but > nothing on RSA authentication. I had KAME (20001023 snapshot) and FreeS/WAN 1.6 successfully interoperate using both PSK and RSA-sig authentication. The config files, certificates and test keys used are available online: http://www.hsc.fr/ipsec/ipsec2000/kame/ http://www.hsc.fr/ipsec/ipsec2000/freeswan/ Not much details though, as this is just a report and not a how-to. Will improve it if I can find spare time. > Does FreeBSD support that? KAME can use RSA-sig and can either exchange certificates online or get them from a file. I tested the latter. No test with the X.509 patch for FreeS/WAN yet, though that's in my short term plans too. > Are the key formats compatible, or has anyone written translation code? KAME wants the keys inside certificates, in PEM format. To extract the keys for FreeS/WAN I used the fswcert utility, but it can be done "by hand" using openssl.
Here is a mailing list message with subject "FreeS/WAN and Cisco 3030 VPN Concentrator" and an attached MS-Word document on the setup.
A sample FreeS/WAN configuration, used in testing with Cisco at an interop conference, is in another list message. Unfortunately, it does not give the matching Cisco configuration.
Here is our first interop success report:
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 SeriesA message from another user about using RSA keys with Cisco:
From: jrussi@uol.com.br Subject: Re:Re: Re:Re: [Users] RSA public key and Cisco (3640) Date: Sat, 2 Jun 2001 We use Cisco IOS 12.1.5(T) and freeswan 1.8 Here an example on how I copied the key from cisco: Key Data: 117C311E 16192D86 8886C71D 11111115 11138B11 31881241 11C7E23B D6DB22 18DEC1BD.... Will become 0x117C311E16192D868886C71D1111111511138B113188124111C7E23BD6DB2218DEC1BD... We used at least 1024 bits long keys. But it doesn´t matter. The problem is that cisco doesn´t agree with the RSA schema from freeswan, I think. In Cisco, rsasig is to use with a CA, and rsaencript did not work as well. My case is worse than it. My first intention was to use freeswan in a road warrior config. I really need to use CA, as Cisco needs a fix address to use rsa public key. The public key to cisco is always associated to an IP address ou FQDN. I quit. Will try the X509 patch and the Open CA software. Deyvi >>(off list) > >Yes, I was just going to mention that the Cisco's key should be in >ipsec.conf (just received your correction). > >I think that I have the Cisco side configured correctly ( I can't be sure >because I can't test against the Freeswan). > >Starting from having the IPsec tunnel working with pre-share, I did the >following on the Cisco side: > >#config t >(config)# crypto key pubkey-chain rsa >(config-pubkey-chain)# addressed-key >(config-pubkey-key)# key-string >(config-pubkey-key)# >(config-pubkey-key)#quit >(config-pubkey-chain)#exit > ># config t >(config)# crypto isakmp policy 1 >(config-isakmp)# no authentication pre-share >(config-isakmp)# authentication rsa-sig >(config-isakmp)# exit > >How long is your RSA key that was generated on the Cisco? I tried copying >the key out of the 3640 and pasting it into ipsec.conf, removing the spaces >and adding a '0x' in the front. I get the 'key too small' error still. What >version of freeswan are you using? > >I'm using Freeswan 1.9 w/ IOS 12.1(6). > > >----- Original Message ----- >From: >To: "James Rowe" ; >Cc: >Sent: Thursday, May 31, 2001 5:15 PM >Subject: Re:Re: [Users] RSA public key and Cisco (3640) > > >> We had no problems with the key. Just be sure to remove the blank spaces >from the key (general key) that cisco generates. >> >> Just remove the blank, put all together as a long line (all the lines to a >single line) and add a "0x" at the key that Cisco give to you, and paste to >ipsec.secrets. >> >> The public key from FreeSwan, you just remove the "0x" and paste to the >command line at cisco. They will not complain about the keys. >> >> But my problem is with the proposal configured at Cisco. What to you think >to use? I tried "authentication rsasig" and "rsaencrip" with no results. >Cisco always sends me an "No proposal choosen" error message. >> >> I road an old message from someone called Brian here at this list, where >he says that FreeSwan will not accept authentication rsaencript from Cisco. >But rsasig is to use with a CA certification. So my question is: is it >possible to use Cisco with public RSA keying, without a CA? The thread ended >without an answer to it. >> >> Deyvi >> >>Hello, >> > >> >I am working on the same issue. I have pre-shared working, but would like >to >> >use RSA public keys. It seems that the Cisco key is too short. When >starting >> >IPsec in init.d, it says that the Cisco key is not secure because it is >less >> >than 512 bits, even tough the key is really over 768 bits. Claudia thinks >> >this is a parsing problem and suggested to take a look at the source >code. >> > >> >Some pointers that I have found while working on this: >> > >> >You must add a '0x' to the front of the Cisco key when entering it into >> >Freeswan, and remove the '0x' when entering the freeswan key into the >Cisco >> >3640. >> > >> >The case of the hexadecimal letters in the key does not matter. Thinking >> >that freeswan stopped reading the key when it encountered the first >> >uppercase letter in the Cisco key (freeswan keys are lowercase, Cisco's >are >> >uppercase), I changed everything to lowercase. Didn't help. >> > >> >I'll let you know if I make any progess on this. I'd appreciate if you >would >> >let me know if you get this working. Thanks. >> > >> >-- Jim Rowe >> > >> >----- Original Message ----- >> >From: >> >To: >> >Sent: Thursday, May 31, 2001 2:52 PM >> >Subject: [Users] RSA public key and Cisco (3640) >> > >> > >> >> Does anyone have a sucessful Cisco config file to use in a >freswan-cisco >> >conection using RSA public key? >> >> >> >> We were able to setup a pre-shared conection, but would like to try >public >> >keying.
Some messages from the mailing list:
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.
A more recent mailing list report is:
Subject: Nortel Contivity and Free-S/WAN
Date: Wed, 7 Mar 2001
From: "JJ Streicher-Bremer" <jj@digisle.net>
OK, here is a very brief nuts and bolts breakdown on how to get this
combo working. I want to thank everyone at Free-S/WAN and everyone on
the list for your help in getting this to work.
Connecting FreeS/WAN to the Nortel Networks Contivity Extranet Switch:
What you need:
FreeS/WAN v1.5 and Contivity ver 2.5 - 3.5 (might work with earlier
versions, but I have not tested it with this config)
or
FreeS/WAN v1.8 and COntivity ver 3.5 (the 3.5 version supports Diffe
Hilman group 2 key exchange)
What to do:
1 - Configure the Contivity:
Set up a branch office tunnel group with the following settings:
Connectivity:
Nailed Up: Disabled
Access Hours: Anytime
Call Admission Priority: Highest Priority
Forwarding Priority: Low Priority
Idle Timeout: 00:00:00
Forced Logoff: 00:00:00
RSVP: Disabled
RSVP: Token Bucket Depth: 3000 Bytes
RSVP: Token Bucket Rate: 28 Kbps
Branch Office Bandwidth Policy:
- Committed Rate: 56 Kbps
- Excess Rate: 128 Kbps
- Excess Action: Mark
Encryption:
- ESP - Triple DES with SHA1 Integrity: Enabled
- ESP - Triple DES with MD5 Integrity: Enabled
- ESP - 56-bit DES with SHA1 Integrity: Disabled
- ESP - 56-bit DES with MD5 Integrity: Disabled
*IKE Encryption and Diffie-Hellman Group: Triple DES with Group
2 (1024-bit prime)
Vendor ID: Disabled
Perfect Forward Secrecy: Enabled
Compression: Disabled
Rekey Timeout: 08:00:00
Rekey Data Count: (None)
*ISAKMP Retransmission Interval: 16
*ISAKMP Retransmission Max Attempts: 4
Set up a branch office tunnel inside this new group with the
following settings:
Endpoint Addresses
Local - Public address of your COntivity
Remote - Your Free-S/WAN interface Address
Tunnel Type - IPSEC
IPSEC Authentication - Text Pre-Shared Key
One note here, I have had some trouble trying to use HEX
or Non alphanumeric chars in this key.
Under IP:
Static Routing
Local - networks you want to be able to access through the
tunnel
Remote - networks that will be allowed through the tunnel
NAT - None
Get routing setup on your office network:
You will need to get a routing entry that will point all traffic
bound for your home network (the one that will be acciessible through
the tunnel) to the internal interface of the contivity system.
Configure Free-S/WAN:
Install, compile, and test Free-S/WAN
Edit ipsec.conf for your new tunnel:
--------------------------------------------------------
ipsec.conf --
config setup
interfaces="ipsec0=eth1"
forwardcontrol=no
klipsdebug=none
plutodebug=none
manualstart=
plutoload=%search
plutostart=%search
plutowait=no
conn net1
type=tunnel
auto=start
auth=esp
authby=secret
keyexchange=ike
keylife=1h
keyingtries=1
pfs=yes
left=10.0.0.2
leftnexthop=10.0.0.1
leftsubnet=10.0.1.0/24
right=172.16.0.2
rightsubnet=172.16.1.0/24
conn net2
type=tunnel
auto=start
auth=esp
authby=secret
keyexchange=ike
keylife=1h
keyingtries=1
pfs=yes
left=10.0.0.2
leftnexthop=10.0.0.1
leftsubnet=10.0.1.0/24
right=172.16.0.2
rightsubnet=172.16.2.0/24
ipsec.secrets --
10.0.0.2 172.16.0.2 "Your big secret"
---------------------------------------------
The above config is for this imaginary network:
+------+
10.0.1.1 | |10.0.0.2 10.0.0.1++ Internet
---------| |-------------------++===========
+------+ Home Router
Free-S/WAN host
Internet ++ 172.16.0.2#### 172.16.1.0/24 These
=========++--------------####---------172.16.2.0/24 are here somewhere
Office Router Contivity
This has worked for me. I am still having trouble with the tunnels
dying after about 30-40 minutes of non-use. Don't know what that is
about, but I'll keep you posted.
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.
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.
> 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.
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.
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.
The mailing list reports success with this combination, but also some problems. Search the archives for the full story.
Here is one message, about what seems to be the biggest problem:
Subject: Re: Pb establishing connection from FW1/3DES/SP2 with freeswan 1.5 - ACTE 2 Date: Tue, 6 Feb 2001 From: Claudia Schmeing <claudia@freeswan.org> > Thanx to Michael and Claudia, but this doesn't work from VPN1 to linux (as > linux to VPN1 is OK). ... > I think that VPN1 doesn't send "192.168.1.0/24" but "192.168.1.20/32" and, > as Claudia said, IPSEC SA need to match Exactly. I don't know about the rules on the VPN-1. You'll have to rely on people with applicable experience there... > Is it possible that freeswan doesn't do the inclusion process (ie if he > receive 192.168.1.20/32, i doesn't match that this is include in > 192.168.1.0/24) ? Yes, that's correct. It needs to match exactly, and inclusion is not part of this process. > Btw why VPN/1 send 192.168.1.20/32 and not 192.168.1.20/24 (the value that > Freeswan is waiting for)? A bug? I think Michael may be able to help you with this. > Have i a way to force Freeswan to do the "inclusion" (ie accept > 192.168.1.20/32 as a part of 192.160.1.20/24, even if the 2 IPSEC Sa > doesn't match exactly) ? No, but... Another strategy is to accept the fact that the Checkpoint proposes separate connections for each machine. If you define and add each of these connections on the Linux FreeS/WAN side, then Linux FreeS/WAN ought to accept the Checkpoint's proposals. The only possible difficulty with this strategy is that I don't know how Linux FreeS/WAN handles the concept of overlapping tunnels. I believe, though, that these tunnels can coexist, and if for any packet there are two options, a more general and a less general, the packet will be handled by the more specific tunnel. You would need to do a little testing to ensure you understand the behaviour and that this does actually solve your problem. I think it would be simplest to try to get the Checkpoint to propose the more general tunnel. Since I don't recall having seen this problem before, I suspect the simpler solution is doable.
The vendor seems serious about interop with us. Here is a message one of their staff posted on our list:
From: Jussi Torhonen <jt@ssh.com> Organization: SSH Communications Security Corp - http://www.ssh.com Subject: [Users] SSH Sentinel VPN client public beta #3 now available Date: Thu, 31 May 2001 Hello, FreeS/WAN community ! SSH Communications Security Corp has released a new public beta #3 version of SSH Sentinel VPN client for Windows. We've got a lot of reports also from FreeS/WAN community and with that feedback we've improved interoperability and stability. For example PFS (Perfect Forward Secrecy in IKE rekey) can now be used between SSH Sentinel and FreeSWAN, and if using that user contributed X.509 patch and exporting the certificate from SSH Sentinel, now those -----[BEGIN|END] CERTIFICATE----- headers/footers are properly included in the exported PEM formatted certificate, so it can be imported to FreeSWAN with fswcert utility and OpenSSL tools. Thank you a lot for your feedback, colleagues ! You can get that new public beta #3 and PDF formatted User Manual from ftp://ftp.ssh.com/pub/sentinel/ or via website http://www.ipsec.com/products/sentinel/beta/register.html For more information about the product, please check our website http://www.ipsec.com We eagerly want to make SSH Sentinel as the best VPN client on the market. If you want to contact our support, please send e-mail to sentinel-support@ssh.com or fill up our feedback form at http://www.ipsec.com/support/sentinel/beta_report.html Best regards, Jussi Torhonen, SSH Sentinel Team Kuopio, Finland
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 make a Linux-based firewall product. Ipchains author Rusty Russell thanks them for support and recommends them in one of his HowTos . On the other hand, some comments on our mailing list about the Watchguard product have been quite unfavourable. See, for example, this archive message.
Watchguard do not use FreeS/WAN in their product. They have their own IPSEC implementation.
We have had mailing list reports of successful interoperation between FreeS/WAN and the Watchguard firewall, using manually keyed connections. The user could not get automatically keyed connections to work; the message below explains this.
Here is some mail from a Watchguard employee about interoperation:
Subject: FreeS/WAN and WatchGuard Firebox interop Date: Mon, 18 Dec 2000 From: Max Enders <menders@watchguard.com> I was recently given the task of testing IPSec interoperability with our product, the Firebox. I just wanted to let you know that I had success with a manual keyed tunnel. Here's what I used for my test: RedHat Linux 6.2 Linux 2.2.18 i686 unknown Linux FreeS/WAN 1.8 "Trusted" interface: 192.168.0.1/24 "External" interface: 192.168.1.1/24 Firebox II FastVPN WatchGuard Live Security System v4.5 Trusted interface: 192.168.2.1/24 External interface: 192.168.1.2/24 Because FreeS/WAN does not implement single DES, a dynamic keyed tunnel will not work. Our product strictly uses DES for main mode. We hope to address this in a future release. Here are instructions for configuring the Firebox: Open the Policy Manager and create a new IPSec gateway. Set the Key Negotiation Type to manual and enter the FreeS/WAN box's external IP address for the Remote Gateway IP. Configure a new tunnel with a unique SPI. Select 3DES-CBC for Encryption and MD5-HMAC for Authentication. Make an Encryption Key and Authentication Key. Copy the values and save them for configuration of the FreeS/WAN box. Configure a routing policy and any necessary services as you normally would. Here's how I configured FreeS/WAN: Modifications to /etc/ipsec.conf: Under the "config setup" section, add: manualstart=firebox At the end of the file, add the following connection: conn firebox left=192.168.1.1 leftsubnet=192.168.0.0/24 right=192.168.1.2 rightsubnet=192.168.2.0/24 spi=0x101 esp=3des-md5-96 espenckey=0x515b0875793e3708517c3d4554012f7c0273375e51572a31 espauthkey=0x072649041c2c0d452f7c15407576522f The spi used here should match the Firebox's. Note that the Policy Manager expects an SPI in decimal, not hexadecimal. The espenckey value should be 0x and the Encryption Key you're using on the Firebox. Likewise for espauthkey and the Authentication Key on the Firebox.A user comments:
Subject: RE: Freeswan Date: Wed, 7 Feb 2001 From: "Patrick Poncet" <pponcet@vaxxine.com> It's working!!! Voila... I wish to thank all the FreeS/WAN for putting out such a great product out! And also Philippe PAULEAU who pioneered interoperability between FreeS/WAN and Watchguard Firebox II and therefore showed me that my efforts would not be wasted!... Yes indeed FreeS/WAN to WatchGuard Firebox only works in manual keying mode and the best way to generate keys is to have the firebox generate the keys, then copy and paste into the ipsec.conf file on the FreeS/WAN side (don't forget to prefix the keys with '0x' in your ipsec.conf file. Also keep in mind that the SPI is in decimal on the Firebox side and HEX on the FreeS/WAN side!!! We spent 4 hours on fixing this HEX-DEC issue only :)
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
Since version 6.5, the PGP products from PGP Inc. have included an IPSEC client program.
Here is the first message about it to our mailing list, from a senior PGP employee:
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.
One version is downloadable at no cost for non-commercial use. See our links. That version does not support subnets.
Several of the user-written HowTos mentioned above cover interoperation between PGPnet and FreeS/WAN.
A more recent post from the same PGP Inc staff member pointed out:
Make sure you're using PGP 7.0 or later as the key parser was improved in that release. (PGP 7.0.1 was just released)
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 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.
Quite a few people seem to be using this with FreeS/WAN and, judging by mailing list reports, to be getting good results. Several documents are available:
Some messages from 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.
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 ;)).A recent report with some setup details:
Subject: RE: linux-ipsec: PGPnet and Freeswan one more time... Date: Sat, 16 Dec 2000 From: "Tim Wilson" <timwilson@mediaone.net> Here are some details about using the IRE SafeNet Soft/PK client with a FreeSwan gateway. I applied the x509 patch to Pluto according to the instructions. I use the "leftcert" and "rightcert" keywords in the ipsec.conf file. This causes FreeSwan to read the public keys and identities from the cert files. The identities wanted and used by FreeSwan will then be the DNs in the certs. I used OpenSSL to generate keys and certs and to sign certs. When generating the gateway cert, you should *not* enter an e-mail address because it turns out that confuses Soft/PK. Also, Andreas Steffan tells me that you want to keep the cert short to avoid fragmentation, so use a 1024-bit RSA key and succinct names. The FreeSwan gateway cert goes in /etc/ipsec.d/, the gateway private key is extracted from the key file using fswcert (part of the x509 patch) and pasted into /etc/ipsec.secrets, and a DER version of the gateway cert goes in /etc/x509cert.der. This is all according to the instructions that accompany the x509 patch. The Windows client is of course running Soft/PK in this case. I generated a private key and cert for the client on the Linux machine using OpenSSL. I created a pkcs12 file containing the client's private key and cert, which I put on a floppy and imported into Soft/PK. I also imported the gateway cert into Soft/PK (you can either import a self-signed cert for the gateway or the self-signed cert for the CA that signed the gateway cert--either works). Soft/PK allows you to configure practically everything for the connection. Here are the main points to watch for: On the first panel you have to set the peer identities. The gateway will identify itself using the DN in the gateway cert. So of course you have to configure Soft/PK to look for the correct DN. There's no problem with this as long as you didn't enter an e-mail address in the gateway cert. Just check "Connect using Secure Gateway tunnel", set ID type to "Distinguished Name", and enter the correct info in the dialog box. In "My identity" just select the client cert that you imported in pcks12 format. Soft/PK apparently identifies itself with the DN from the cert, which is exactly what FreeSwan is looking for. In "Security Policy", you want Main mode and make the PFS setting agree with whatever FreeSwan is doing (FreeSwan uses PFS by default). If you use PFS I believe you must use DH group 2 as FreeSwan doesn't like group 1. Phase 1 Authentication must be "RSA signatures" and 3DES plus either MD5 or SHA-1 (I used MD5 but I believe FreeSwan accepts either). I left the lifetime unspecified. Also you must select DH group 2 because I believe that FreeSwan will not accept group 1. Phase 2 also must use 3DES and MD5 or SHA-1. I used no compression and only ESP and no AH, haven't tried other choices. Hope this helps.
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.
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.
A web page with Shiva compatibility information.
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.
Subject: Re: FreeS/WAN and SonicWall
Date: Mon, 5 Feb 2001
From: "Dilan Arumainathan" <dilan_a@impark.com>
***************************************************
I know I HAVE TO write the mini-howto - but here is the beginning
***************************************************
Here is my Sonicwall configuration for my working connection:
conn testauto
left=x.x.x.x
leftnexthop=x.x.x.x
right=y.y.y.y
rightnexthop=y.y.y.y
rightsubnet=10.1.20.0/24
#You need to set the Unique Firewall Identifier to the parameter that you
#use as the rightid.
It certainly has been possible to interop between Radguard VPN gateways and past Linux FreeS/WAN versions, as is evidenced by http://www.opus1.com/vpn/atl99display.html, as well as my own interop results from San Diego this year. There have been no major changes since SD that I would foresee affecting this. The Radguard team said that their VPN gateway will not respond to a peer request with PFS (Perfect Forward Secrecy) on, but it *will* successfully establish such a connection with Linux FreeS/WAN when Radguard is the initiator. Since PFS is a desirable feature in terms of cryptographic security, this asymmetry may frustrate efforts to provide a connection that is both as reliable as secure as possible. While it's not clear that rekeying will present a problem, I suspect that some fine tuning of the key life parameters may be needed. Unfortunately I was unable to do additional tests on this topic. Due to the PFS issue, when trying to maintain a connection with PFS, you may need to set the rekeying times shorter on the radguard side, in order to ensure that it is always the initiator.
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. The SSH Sentinel client, released since the above message, is another possibility. Both of those have members of the vendor's staff active on our mailing list, an excellent sign for both interoperability and support.
We also know of some Windows IPSEC clients not mentioned above:
No doubt there are others we don't know of.
Robert Cotran asked:
> I have a VPN setup between two subnets (192.168.1.x and 192.168.2.x). I > would like to be able to join the NT domain on 192.168.1.x from the > 192.168.2.x subnet. Is this possible? Do I have to forward specific ports > to do this? I've already set up WINS entries for all the machines, so > accessing computers by their NetBIOS names works perfectly. Please let me > know about this domain thing. Thanks!Dilan Arumainathan answered:
All you need to do is to:
1. Enable NetBIOS over TCP.
2. Create a "lmhosts" file and enter the address of a BDC or a PDC like
192.168.1.[x] [Your PDC/BDC servername] #PRE #DOM:[Your Domain Name]
eg. 192.168.1.1 MYOWNPDC #PRE #DOM:DENSI-NT
3. Reboot if necessary.
and Sebastien Pfieffer provided a slightly different answer:
For a trust relationship to work between NT domains in different (sub)nets all domain controllers of the 1st domain have to know about all controllers of the other domain. Either you use the described LMHOSTS entry for every domain controller of both domains or consider setting up WINS service(s).We suspect that in some cases it may be more complex than that. See the discussion of Linux services and Windows 2000 below and the Interop HowTo documents listed above.
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.
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:
The Windows 2000 Kerberos implementation includes proprietary modifications. This is a security worry since it is by no means clear that the modified version remains secure. It also creates interoperation problems. Microsoft have released documentation on their modifications, but only under a license that hampers attempts either to audit their code for security flaws or to build other implementations that interoperate with it.
You write, > I want some information about IPsec with L2TP. > I'm going to build the IPsec tunnel on the L2TP tunnel. > Is it strange? > Is there any case like this already implemented? It's used, but rarely. In many cases, IPSec alone is sufficient. In this thread, Timo Teras reports that he configured the L2TP/IPSec hybrid with Win2k. He gives some pointers. http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00545.html See also John P. Eisenmenger's report on his own experiences at: http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00195.html
As for IPSEC interoperation between Windows 2000 and FreeS/WAN, there are several web sites listed under Interop HowTo documents above.
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.
The RoadWarrior problem has since been solved. RSA authentication has been added to FreeS/WAN since the above message was posted.