3 <meta http-equiv="Content-Type" content="text/html">
4 <title>FreeS/WAN interoperation</title>
6 content="Linux, IPsec, VPN, security, FreeSWAN, interoperation">
9 Written by Sandy Harris for the Linux FreeS/WAN project
10 Freely distributable under the GNU General Public License
12 More information at www.freeswan.org
13 Feedback to users@lists.freeswan.org
16 RCS ID: $Id: interop.html,v 1.77 2002/03/24 18:47:35 sandy Exp $
17 Last changed: $Date: 2002/03/24 18:47:35 $
18 Revision number: $Revision: 1.77 $
20 CVS revision numbers do not correspond to FreeS/WAN release numbers.
25 <h1 name="interop">Interoperation with other IPsec implementations</h1>
27 <p>The IPsec protocols are designed to allow interoperation between different
28 implementations. Other sections of this documentation have more detail on:</p>
30 <li>the IPsec <a href="ipsec.html">protocol specifications</a></li>
31 <li>parts of the protocols <a href="compat.html#spec">implemented or
32 omitted</a> in FreeS/WAN</li>
33 <li><a href="web.html#implement">other implementations</a></li>
36 <p>FreeS/WAN does interoperate successfully with many other implementations.
37 The ones we know about are listed <a href="#mail.interop">below</a>.</p>
39 <p>Of course "the devil is in the details" and the IPsec protocols have a lot
40 of details. At least one <a
41 href="http://www.counterpane.com/ipsec.pdf">critique</a> has argued that the
42 protocols should be simplified. Various of those details can and do cause
43 difficulties for interoperation. Should you encounter such problems, please
44 let us know via the <a href="mail.html">mailing list</a>. We will likely be
45 able to help you, and your report may be useful both to other users and to
46 the implementation teams.</p>
48 <p><strong>Note:</strong> This file is updated often, whenever I notice an
49 interesting interop report on the mailing list. If you are reading the
50 version that ships with a FreeS/WAN release or is posted on the web, and what
51 you need isn't here, consider downloading the latest snapshot to get the
52 latest version of the doc. Perhaps I've added what you need since the last
55 <p>There is additional information on interoperability testing in our <a
56 href="web.html#interop.web">web links</a> section.</p>
58 <h2><a name="interop.problem">Interoperability problems</a></h2>
60 <p>The IPsec RFCs are complex and include a number of optional features.
61 There is considerable opportunity for even two correct, standard-conforming,
62 implementations to disagree on details in a way that blocks interoperation.
63 Errors in either implementation -- either misinterpretations of the standards
64 or just bugs -- can also foul things up.</p>
66 <p>The commonest cause of problems, however, seems to be configuration
67 errors. Any IPsec implementation is somewhat complex. It has to be; neither
68 the networks it runs on nor the protocols it implements are simple. When you
69 have two of them to deal with, the problem you face is not trivial.</p>
71 <p>That said, FreeS/WAN interoperates successfully with many other
72 implementations. There is a <a href="#mail.interop">list</a> below, with
73 configuration details provided by various users who have already solved these
76 <h3><a name="req.features">Possible problem areas</a></h3>
78 <p>Known areas where problems may appear are:</p>
80 <li><strong>FreeS/WAN does not implement single DES</strong> because <a
81 href="politics.html#desnotsecure">DES is insecure</a>. Suggestions on
82 what to do if the device you want to talk to has only DES are <a
83 href="#noDES">below</a>.</li>
84 <li><strong>FreeS/WAN does not implement Diffie-Hellman group 1
85 (768-bit)</strong> because it is not clear that this is secure.</li>
86 <li>The RFCs define two modes for IKE negotiations -- main mode and
87 aggressive mode. Aggressive mode is slightly faster, but reveals more
88 information to an eavesdropper. Specifically, it lets an eavesdropper
89 know what identities are in use. <strong>FreeS/WAN does not implement
90 aggressive mode</strong>, so any negotiation another implementation tries
92 <p>In principle this should not be a problem since main mode support is
93 required in all implementations and aggressive mode is optional. In
94 practice, it is sometimes a problem. Some implementations default to
95 aggressive mode unless you configure them for main mode.</p>
97 <li>For automatic keying, <strong>the FreeS/WAN default is to provide <a
98 href="glossary.html#PFS">perfect forward secrecy</a></strong>. We see no
99 reason not to; this is more secure and costs little. Some other
100 implementations, however, turn PFS off by default.
101 <p><strong>The PFS settings on the two ends must match</strong>. There is
102 no provision in the protocol for negotiating whether to use PFS; you need
103 to either set both ends to use it or set them both not to. For
104 communication between FreeS/WAN and an implementation that has PFS off by
105 default, you will have to change the setting on one end.</p>
106 <p>You can turn PFS off in FreeS/WAN with the <var>pfs=no</var> setting
107 in <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>, but if
108 possible we suggest you enable PFS on the other end instead. That is more
111 <li>The IKE protocol allows several types of optional message. Two things
112 happen which are allowed by the RFCs:
114 <li>Some implementations send various optional messages.</li>
115 <li>FreeS/WAN ignores them.</li>
117 However, problems may arise if the other end relies on some expected
118 effect of these messages. There are two FAQ questions dealing with this,
119 one on the <a href="faq.html#ignore">log message</a> FreeS/WAN gives when
120 ignoring optional payloads and one on the <a
121 href="faq.html#deadtunnel">delete SA</a> payload.</li>
122 <li>IKE also allows an optional "commit bit" to be set on some messages.
123 Some uses of this, especially by Windows 2000, have caused interoperation
124 problems with FreeS/WAN. As of version 1.92, we have changed our handling
125 of this -- we now ignore the bit instead of dropping the packet -- which
126 should reduce such problems.</li>
129 <p>The general rule is that to interoperate with FreeS/WAN, the other
130 implementation should be configured for:</p>
133 <li>triple DES encryption</li>
134 <li>Diffie-Hellman Group 2 (1024-bit) or Group 5 (1536-bit)</li>
135 <li>Perfect Forward Secrecy</li>
138 <p>This is possible for most implementations.</p>
140 <p>For a more detailed discussion of which parts of the IPsec specification
141 FreeS/WAN implements, and reasons for that, see our <a
142 href="compat.html#spec">compatibility document</a>.</p>
144 <h3>Documentation and terminology problems</h3>
146 <p>Documentation can also pose problems for interoperation. The two
147 implementations may use different terms for the same thing, or one may have
148 features that the other does not support and therefore does not document.
149 This can be quite confusing for the poor user who has to deal with both.</p>
151 <p>Known examples are:</p>
153 <li>What I call a "shared secret" (e.g. in <a
154 href="adv_config.html#prodsecrets">this section</a>), the documentation
155 for another implementation might call a "passphrase" or "pre-shared
157 <li>Some implementations specify a subnet as a range of IP addresses, for
158 example 192.168.1.0-192.168.1.255 where we would use a subnet mask, e.g.
159 192.168.1.0/24 or 192.168.1.0/255.255.255.0. See our <a
160 href="adv_config.html#subnet.size">discussion of subnets</a>.</li>
163 <p>If you encounter such problems, please report them to the <a
164 href="mail.html">users mailing list</a> and I'll try to add some clarifying
165 text on the FreeS/WAN side.</p>
167 <h3><a name="one-way">If it only works in one direction</a></h3>
169 <p>A few users have encountered situations in which interoperation is fine
170 when one end initiates, but fails if the other end starts the negotiation.</p>
172 <p>In such cases, you can set <var>rekey=no</var> in the FreeS/WAN connection
173 description. This prevents FreeS/WAN from initiating re-keying of that
174 connection, but it will still respond if the partner initiates.</p>
176 <p>Even if that trick solves your problem, please report the difficulty to
177 the <a href="mail.html">users mailing list</a>. It is definitely supposed to
178 work no matter who initiates.</p>
180 <h3><a name="client.server">"Clients" and "servers"</a></h3>
181 IPsec is not a client/server protocol. In a client/server protocol, the two
182 ends have quite different roles. For example, consider the web. The client
183 runs a browser and mostly does display. The server runs completely different
184 software and does no display at all. Similarly, in a database application,
185 the client and server play quite different roles and often run completely
188 <p>IPsec is a peer-to-peer protocol. The gateways on the two ends of an IPsec
189 connection are peers, both doing the same thing. They could use identical
192 <p>Despite this, various vendors produce products they call "clients" and
193 others they call "servers". Typically, the "clients" do not support a subnet
194 behind them. They are designed only to let a single remote machine connect.
195 To get full IPsec with subnet support, you pay more for the "server
198 <p>For example, the free version of <a href="#pgpnet">PGPnet</a> is only a
199 "client"; for subnet support you need to purchase the product. Also, Windows
200 2000 Professional has only "client" IPsec. For subnet support you need to
201 purchase the server version, or put Linux and FreeS/WAN on your gateways.</p>
203 <p>This difference does not cause interoperation problems as such. FreeS/WAN
204 will happily interoperate with either a "client" or a "server" product, and
205 will happily play either role itself, depending on how it is configured. In
206 their marketing terms, FreeS/WAN acts as a "server" if you define a subnet
207 behind the gateway, and as a "client" if you do not.</p>
209 <p>It does, however, often complicate things when users discover that the
210 product they have will not do what they need because it is "only a client".
211 Usually the only solutions are to upgrade to the "sever version" or to switch
212 to a different product.</p>
214 <h3><a name="noDES">Systems that want to use single DES</a></h3>
216 <p>Linux FreeS/WAN does not support single DES transforms. Neither Pluto's
217 IKE connections nor KLIPS' IPsec connections can use DES. Since <a
218 href="politics.html#desnotsecure">DES is insecure</a> we do not, and will not
219 at any future time, provide it.</p>
221 <p>DES is, unfortunately, a mandatory part of the <a
222 href="glossary.html#IPsec">IPsec</a> standard. Despite that, we will not
223 implement DES. We believe it is more important to provide security than to
224 comply with a standard which has been <a
225 href="politics.html#weak">subverted</a> into allowing weak algorithms. See
226 our <a href="politics.html">history and politics</a> section for
229 <p>Some implementations may offer DES as the default. In such cases we urge
230 you to change them to <a href="glossary.html#3DES">Triple DES</a>. If this is
231 not possible, for example because <a href="politics.html#exlaw">export
232 laws</a> prevent your vendor from offerring you adequate crytography, we urge
233 you to complain vigorously to one or more of:</p>
235 <li>your government, especially any department concerned with protecting
236 citizens' privacy or your nation's communication infrastructure</li>
238 <li>the embassy of the nation whose laws are problematic for you</li>
241 <p>Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES
244 <p>FreeS/WAN does have <a href="glossary.html#DES">DES</a> code in it as a
245 sort of historical accident, since we need it to implement our default
246 (currently, our only) block cipher, <a href="glossary.html#3DES">Triple
247 DES</a>. However, since <a href="politics.html#desnotsecure">DES is
248 insecure</a>, we do not provide any interface to that code.</p>
250 <p>As a matter of project policy, we will not help anyone subvert FreeS/WAN
251 to provide <a href="politics.html#desnotsecure">insecure DES
254 <h2><a name="patch.interop">Patches to extend interoperability</a></h2>
256 <p>Sometimes interoperation requires user-contributed patches or add-ons on
257 the FreeS/WAN end. See this <a href="web.html#patch">list of available
260 <p>In many cases, no patches to the actual IPsec code are required. The
261 problem is to make FreeS/WAN recognise RSA keys stored in formats other than
262 ours. Each such format needs either a patch to make FreeS/WAN understand that
263 format or a utility to translate it to the FreeS/WAN format. For example,
264 unmodified FreeS/WAN cannot use RSA keys generated by <a
265 href="glossary.html#PGP">PGP</a> or keys stored in <a
266 href="glossary.html#X.509">X.509</a> certificates, but patches or utilities
267 are available for both those formats.</p>
269 <p>Other patches do change the IPsec code, for example to add the <a
270 href="glossary.html">AES</a> cipher. Likely this patch will be incorporated
271 into FreeS/WAN long before AES becomes important as an interoperaibility
274 <p>Note that with some patches, you might be giving up some security in
275 exchange for interoperability. There are a number of "features" of IPsec
276 which we do not implement (<a href="compat.html#dropped">details</a>) either
277 because they directly reduce security or because they unnecessarily
278 complicate things, thereby adding to security risks. Adding these "features"
279 is not recommended..</p>
281 <h2><a name="otherpub">Interop HowTo documents</a></h2>
283 <p>The FreeS/WAN team does not have the resources to test with anything like
284 the full range of <a href="web.html#implement">other IPsec
285 implementations</a> out there. Fortunately, some of our users are doing a
286 fine job of filling the gap by providing HowTo information:</p>
288 <li>Hans-Jorg Hoxer's <a
289 href="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html">HowTo</a>
290 covering interoperation between any two of:
293 <li>Open BSD IPsec</li>
294 <li>Windows 98 with PGPnet</li>
297 <li>Jean-Francois Nadeau's <a href="http://jixen.tripod.com/">practical
298 configurations</a> document covers FreeS/WAN interoperation with
300 <li>Windows 2000 IPsec</li>
302 <li>IRE Safenet SoftPK.</li>
305 <li>Oscar Delgado's <a
306 href="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">page</a>
307 has a PDF document covering interop using X.509 certificates between
310 <li>Windows 2000</li>
315 href="http://suigres.bei.t-online.de/Freeswan-Clients_1.0/Freeswan-Clients_1.0.tar">HowTo
316 in German</a> covering interoperation with:
318 <li>Windows 2000</li>
320 <li>SSH Sentinel</li>
323 <li>Terrandon Communications provide a <a
324 href="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">PDF
325 HowTO</a> on using FreeS/WAN with IRE SafeNet</li>
326 <li>Telenor provide a HowTo on <a
327 href="http://security.nta.no/freeswan-w2k.html">FreeS/WAN and Windows
329 <li>ForSite Solutions have a document in their <a
330 href="http://www.forsitesolutions.com/Techstuff/freeswan/freeswan.html">GRIP</a>
331 (Guide for reasonably intelligent people) series covering FreeS/WAN, IRE
332 on 98, and Windows 2000 IPsec. When I looked at it (July 2001), it was
333 seriously incomplete, but had some good stuff.</li>
334 <li>Ryan's <a href="http://www-ec.njit.edu/~rxt1077/Howto.txt">HowTo</a>
335 for getting PGPnet to connect with FreeS/WAN using x509 certs through a
336 Linksys router, with IPSec passthru enabled</li>
337 <li>Nate Carlson has a HowTo document for <a
338 href="http://www.natecarlson.com/include/showpage.php?cat=linux&page=ipsec-x509">FreeS/WAN
339 with X.509 patch and Windows 2000</a></li>
342 <p>See also our lists of:</p>
344 <li>available <a href="web.html#patch">patches and add-ons</a>.</li>
345 <li>user-writtten <a href="intro.html#howto">FreeS/WAN-to-FreeS/WAN
346 HowTo</a> documents</li>
349 <h3><a name="ipsec.2001"></a>Interop info from the IPsec 2001 conference</h3>
351 <p>From a mailing list report:</p>
352 <pre> Subject: IPsec 2001 interop demo data available
353 Date: Tue, 13 Nov 2001
354 From: Ghislaine Labouret <Ghislaine.Labouret@hsc.fr>
355 Organization: HSC (Herve Schauer Consultants)
357 During the IPsec 2001 conference held in Paris last month, an
358 interoperability demonstration including FreeS/WAN was set up.
360 FreeS/WAN 1.91 + X.509 patch 0.9.3 was tested with the following
361 devices: 6WINDGate, Cisco IOS, Cisco PIX, Cisco VPN 3000, Netasq F100,
362 Netcelo VPN gateway, NetScreen NS100, Nortel Contivity, OpenBSD 3.0.
364 The results and configuration files are now available online:
365 http://www.hsc.fr/ipsec/ipsec2001/</pre>
367 <h2><a name="mail.interop">Interoperation with specific products</a></h2>
369 <p>Most of the information in this section is gleaned from the mailing list.
370 For additional information, search one of the list <a
371 href="mail.html#archives">archives</a>.</p>
373 <p>A large thank you is in order to all the list contributors. This document
374 would not exist without you.</p>
376 <p><strong>Anyone who has tested with an implementation not listed here,
377 please report results</strong> to the <a href="mail.html">mailing list</a>. I
378 generally include the sender's email address when I quote list messages here;
379 "credit where credit is due". If you would prefer that I not do that with
380 yours, please mention that.</p>
382 <h3><a name="oldswan">Older versions of FreeS/WAN</a></h3>
383 Any two versions of FreeS/WAN should interoperate, and many combinations have
384 been tested doing so successfully. In particular, every release is tested
385 against its predecessor before it goes out.
387 <p>However, if you do encounter a problem involving an older version, we are
388 likely to suggest you upgrade. We do not have the resources to support
389 multiple versions.</p>
391 <h4><a name="config.old">Using your old config files</a></h4>
393 <p>In general, new versions will use existing configuration files, at least
394 until the next major version number change. For example, 1.8 can use files
395 created for 1.7, 1.6, even back to 1.0, but not from 0.92. This behaviour
396 will continue until we release 2.0.</p>
398 <p>As of 1.8, however, conf file checking has become stricter, so that an
399 error that may have slipped past the checks in an earlier version may be
400 caught in a later one. From 1.8's doc/CHANGES:</p>
401 <pre> The internal configuration-file reader is progressively getting
402 fussier about what it will accept, which may cause problems for
403 illegal ipsec.conf files whose sins previously passed unnoticed.
404 IN PARTICULAR, the "auto" parameter's values are now checked for
405 legality everywhere.</pre>
407 <h3><a name="OpenBSD">OpenBSD</a></h3>
409 <p>Two user-written HowTos we know of cover interoperation between FreeS/WAN
410 and Open BSD IPsec:</p>
412 <li>Hans-Jorg Hoxer's <a
413 href="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html">HowTo</a></li>
414 <li>Skyper's <a href="http://www.segfault.net/ipsec/">guide</a></li>
417 <p>The <a href="http://www.openbsd.org/faq/faq13.html">OpenBSD FAQ</a>
418 includes information on their IPsec implementation.</p>
420 <p>This report is from one of the OpenBSD IPsec developers, a regular
421 participant on our mailing list:</p>
422 <pre>Subject: spi.c bug
423 Date: Tue, 23 Feb 1999
424 From: Niklas Hallqvist <niklas@appli.se>
426 PS. I don't know if you have an interop list anywhere, but you should
427 know FreeS/WAN interops with OpenBSD both at the IPSec level and at
430 <p>There is one known problem with FreeS/WAN-OpenBSD IKE interoperation. Here
431 is a mailing message from our Pluto implementer, discussing that with the
432 user who discovered it:</p>
433 <pre>Subject: Re: [Bugs] Interoperability with OpenBSD
434 Date: Sun, 30 Sep 2001
436 | Yes, the problem was the pre-shared key. It seems that it cannot be
437 | more than 64 characters long. I was using a longer key.
439 | Is this documented behaviour for either FreeS/WAN or isakmpd? (Anyway
440 | a reasonable error message would not hurt.)
442 The limit is not in FreeS/WAN, so we don't document it :-)
444 I guess we could mention this on our interop pages. Claudia?
446 The error message from isakmpd was not very helpful (I realize that
447 I'm in a glass house when I throw this stone).
449 - isamkpd documentation should state the limit
451 - isakmpd should diagnose that the PSK was too long
453 - isakmpd should suggest that this type of problem (undigestable
454 message) might be caused by mis-matched PSK
456 I hope that you would have gotten a better message from Pluto. So if
457 you had initiated from the isakmpd side, the resulting diagnostic from
458 Pluto might have lead you to the problem more quickly.
460 When Pluto cannot parse the first encrypted IKE message, it prints a
461 diagnosis of the parse failure (just like isakmpd did), but it prefixes it
463 probable authentication (preshared secret) failure:
465 I just noticed that it will print this even if authentication is via
466 RSA Sig -- I will fix that. I'll reword the prefix too:
467 probable authentication failure (mismatch of preshared secrets?):</pre>
469 <h3><a name="FreeBSD">FreeBSD</a></h3>
471 <p><a href="http://www.freebsd.org">FreeBSD</a> uses the <a
472 href="http://www.kame.net">KAME</a> IPsec and IPv6 code.</p>
474 <p>Here is a mailing list message on FreeBSD interoperation:</p>
475 <pre>Subject: Re: Interop with [Free|Open|Net]BSD
476 Date: Fri, 29 Dec 2000
477 From: Ghislaine Labouret <Ghislaine.Labouret@hsc.fr>
479 On Thu, 28 Dec 2000 13:53:01 -0500, Sandy Harris wrote:
483 > For FreeBSD, I find list discussion of 3DES key formats, presumably for manual
484 > keying. We have 192-bit, 3 64-bit keys including parity bits, while FreeBSD 4.0
485 > used 168-bit, 3 56-bit keys without the parity bits. Has FreeBSD changed this?
487 I still don't understand what made Spike Gronim say that KAME wants a
488 168 bits key; I have always been using 192 bits keys with KAME and had
489 no interoperability problem between KAME and FreeS/WAN using manual
492 > For auto keying, I find reports of sucessful use of pre-shared secrets, but
493 > nothing on RSA authentication.
495 I had KAME (20001023 snapshot) and FreeS/WAN 1.6 successfully
496 interoperate using both PSK and RSA-sig authentication. The config
497 files, certificates and test keys used are available online:
498 http://www.hsc.fr/ipsec/ipsec2000/kame/
499 http://www.hsc.fr/ipsec/ipsec2000/freeswan/
500 Not much details though, as this is just a report and not a how-to. Will
501 improve it if I can find spare time.
503 > Does FreeBSD support that?
505 KAME can use RSA-sig and can either exchange certificates online or get
506 them from a file. I tested the latter. No test with the X.509 patch for
507 FreeS/WAN yet, though that's in my short term plans too.
509 > Are the key formats compatible, or has anyone written translation code?
511 KAME wants the keys inside certificates, in PEM format. To extract the
512 keys for FreeS/WAN I used the fswcert utility, but it can be done "by
513 hand" using openssl.</pre>
515 <h3><a name="NetBSD">NetBSD</a></h3>
517 <p>NetBSD has an IPsec implementation based on <a
518 href="http://www.kame.net">KAME</a>. It is described in this <a
519 href="http://www.netbsd.org/Documentation/network/ipsec/">FAQ</a>.</p>
521 <h3><a name="Cisco">Cisco Routers</a></h3>
523 <h4><a name="cisco.info">Information from Cisco</a></h4>
525 <p>Useful pages on Cisco sites include:</p>
528 href="http://www.cisco.com/warp/public/471/top_issues/vpn/vpn_index.shtml">VPN
531 href="http://www.ieng.com/warp/public/707/index.shtml#ipsec">IPsec</a></li>
534 <p>To work with FreeS/WAN, a Cisco router must have 3DES software. A <a
535 href="http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t2/3desips.htm">page</a>
536 on Cisco's site gives this list:</p>
537 <pre>| Triple DES Encryption for IPSec
541 | This feature is supported only on the following platforms:
552 <h4><a name="cisco.list">From our mailing list</a></h4>
554 <p>Our first Cisco interop success reports were from Ian Calderbank in 1999.
555 They included configuration information for his Cisco 3640. These messages
556 can be found in the mailing list <a href="mail.html#archive">archives</a> or
557 in older versions of this document, still available <a
558 href="http://www.freeswan.org/doc.html">on the web</a>. We no longer include
561 <p>Several other pages have possibly useful information:</p>
563 <li><a href="http://www.diverdown.cc/vpn/">configuration files</a> for
564 FreeS/WAN 1.91, Cisco PIX and Cisco 2611 router</li>
566 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00578.html">message</a>
567 with subject "FreeS/WAN and Cisco 3030 VPN Concentrator" with an attached
568 MS-Word document on the setup.</li>
569 <li>A sample FreeS/WAN configuration, used in testing with Cisco at an
570 interop conference, is in another list <a
571 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00095.html">message</a>.
572 Unfortunately, it does not give the matching Cisco configuration.</li>
574 href="http://www.worldbank.ro/IPSEC/cisco-linux.txt">HowTo</a> for
575 interop between a Cisco 3360 and FreeS/WAN, using shared secrets</li>
578 <h4><a name="cisco.psk">Shared secrets work</a></h4>
580 <p>Several users report successful interoperation using shared secrets. Here
581 is one such message:</p>
582 <pre>Subject: [Users] cisco - freeswan summary
583 Date: Fri, 31 Aug 2001
584 From: mcferren@colltech.com
586 I finally got a vpn linked up between a 3000 series cisco router and a
587 redhat linux box using shared secrets. The linux box is running 2.2.19 with
588 freeswan 1.9. The shared secret has no spaces in it, as I read somewhere
589 that it might break the connection.
591 Several people have asked me the configuration that I have used to
592 make this happen, so I thought I should publish it here.
594 Here is the network...
598 ------------------- 172.11.251.0/24
602 ------------------- 172.11.252.0/24
620 ------------------- 10.25.5.0
625 My ipsec.conf looks like this...
628 # THIS SETTING MUST BE CORRECT or almost nothing will work;
629 # %defaultroute is okay for most simple cases.
630 interfaces="ipsec0=eth0"
631 # Debug-logging controls: "none" for (almost) none, "all" for lots.
636 # Close down old connection when new one using same ID shows up.
639 # defaults for subsequent connection descriptions
641 # How persistent to be in (re)keying negotiations (0 means very).
646 leftnexthop=xxx.xxx.xxx.1
647 leftsubnet=172.11.251.0/24
649 rightnexthop=yyy.yyy.yyy.1
650 rightsubnet=10.25.5.0/24
654 My cisco configuration looks like this...
657 crypto map VPN 30 ipsec-isakmp
658 set peer xxx.xxx.xxx.85
659 set transform-set 3des-md5
662 crypto ipsec transform-set 3des-md5 esp-3des esp-md5-hmac
664 crypto isakmp key ******** address xxx.xxx.xxx.85
667 crypto isakmp policy 3
670 authentication pre-share
673 access-list 130 permit ip 10.25.5.0 0.0.0.255 172.11.251.0 0.0.0.255
675 Sorry it took so long to send this out, but there is apparently an ipchains
676 firewall on the host behind the cisco, and it took some time to get
677 these rules straight.
679 I hope this helps someone....</pre>
680 Another similar post:
681 <pre>Subject: [Users] freeswan <--$gt; Cisco: success!
682 Date: Thu, 20 Sep 2001
683 From: "Wolfgang Tremmel" <w.tremmel@vianetworks.de>
685 I have seen several requests on the list for example
686 configurations for connection of Freeswan to Cisco, since
687 about 1 hour ago I had success, here my example configuration.
689 Background: My router is a 80486, connecting to the internet using
690 PPPoE via DSL. Kernel is 2.4.9, Freeswan is snap2001sep13b
691 And yes, I get a dynamic IP address
693 Router is a Cisco 4700, running IOS 12.2(2)T1 with 3DES
697 interfaces="ipsec0=ppp0"
706 disablearrivalcheck=no
711 leftsubnet=my.net.work.athome/29
712 right=x.x.x.x # fastEthernet0 of ciscorouter
713 rightnexthop=1.2.3.4 # next hop of ppp0
714 rightsubnet=0.0.0.0/0 # defaultroute via ipsec
721 %any x.x.x.x: PSK "thisisatestkey"
723 - ---- thats all on the linux router
724 - ---- now for the Cisco:
726 crypto isakmp policy 100
728 authentication pre-share
731 crypto isakmp key diesisteintest address y.y.0.0 255.255.0.0 !
732 network and mask of any possible address your ppp0 can have
734 crypto ipsec transform-set linuxbox esp-3des esp-sha-hmac
736 crypto dynamic-map linuxbox 100
737 set transform-set linuxbox
738 match address linuxbox
740 crypto map linuxbox local-address FastEthernet0
741 crypto map linuxbox isakmp authorization list linuxbox ! not sure if
742 that is really needed
743 crypto map linuxbox 100 ipsec-isakmp dynamic linuxbox discover
745 interface FastEthernet0
746 ip address x.x.x.x 255.255.255.192
750 ip access-list extended wtremmel
751 permit ip host x.x.x.x my.net.work.athome mask
756 <h4><a name="cisco.rsa">RSA keys are tricky</a></h4>
758 <p>A message from another user about using RSA keys with Cisco:</p>
759 <pre>From: jrussi@uol.com.br
760 Subject: Re: [Users] RSA public key and Cisco (3640)
761 Date: Sat, 2 Jun 2001
763 We use Cisco IOS 12.1.5(T) and freeswan 1.8
765 Here an example on how I copied the key from cisco:
768 117C311E 16192D86 8886C71D 11111115 11138B11 31881241 11C7E23B D6DB22
773 0x117C311E16192D868886C71D1111111511138B113188124111C7E23BD6DB2218DEC1BD...
775 We used at least 1024 bits long keys.
777 But it doesn´t matter. The problem is that cisco doesn´t agree with the RSA
778 schema from freeswan, I think. In Cisco, rsasig is to use with a CA, and
779 rsaencript did not work as well.
781 My case is worse than it. My first intention was to use freeswan in a road
782 warrior config. I really need to use CA, as Cisco needs a fix address to
783 use rsa public key. The public key to cisco is always associated to an IP
784 address ou FQDN. I quit. Will try the X509 patch and the Open CA software.
789 >Yes, I was just going to mention that the Cisco's key should be in
790 >ipsec.conf (just received your correction).
792 >I think that I have the Cisco side configured correctly ( I can't be sure
793 >because I can't test against the Freeswan).
795 >Starting from having the IPsec tunnel working with pre-share, I did the
796 >following on the Cisco side:
799 >(config)# crypto key pubkey-chain rsa
800 >(config-pubkey-chain)# addressed-key <ipaddress of freeswan>
801 >(config-pubkey-key)# key-string
802 >(config-pubkey-key)# <paste freeswan key here>
803 >(config-pubkey-key)#quit
804 >(config-pubkey-chain)#exit
807 >(config)# crypto isakmp policy 1
808 >(config-isakmp)# no authentication pre-share
809 >(config-isakmp)# authentication rsa-sig
810 >(config-isakmp)# exit
812 >How long is your RSA key that was generated on the Cisco? I tried copying
813 >the key out of the 3640 and pasting it into ipsec.conf, removing the spaces
814 >and adding a '0x' in the front. I get the 'key too small' error still. What
815 >version of freeswan are you using?
817 >I'm using Freeswan 1.9 w/ IOS 12.1(6).</pre>
819 <h4><a name="cisco.conc">Cisco VPN Concentrator</a></h4>
821 <p>Another mailing list thread discussed using FreeS/WAN with the Cisco VPN
822 Concentrator. Here is one user describing his problem:</p>
823 <pre>Subject: [Users] FreeSWAN and Cisco VPN CONCENTRATOR
824 Date: Thu, 25 Oct 2001
825 From: "M. Sticki" <msticki@web.de>
827 i have to establish a vpn tunnel between two companies.
828 one of the company is using the cisco vpn concentrator
829 and the other company is using redhat 7.1 and freeswan.
831 it is no a problem to estblish the tunnel between two freeswan
832 gateways or between a cisco vpn-client and the concentrator.
834 but the companies don't want to change their equipment.
835 and with this constellation i can't establish the tunnel.
837 the responce from cisco is: "THAT IS NOT SUPPORTED"
839 so this mailing list is my last chance, because i don't know how to go on</pre>
841 <p>and another user's answer:</p>
842 <pre>Subject: Re: [Users] FreeSWAN and Cisco VPN CONCENTRATOR
843 Date: Thu, 25 Oct 2001 14:21:17 +0200
844 From: Ghislaine Labouret <Ghislaine.Labouret@hsc.fr>
846 > i have to establish a vpn tunnel between two companies.
847 > one of the company is using the cisco vpn concentrator
848 > and the other company is using redhat 7.1 and freeswan.
850 > the responce from cisco is: "THAT IS NOT SUPPORTED"
852 At the IPsec 2001 conference which is behing held right now, we have
853 set up an interop demo platform which includes those two devices.
854 They are successfully interoperating using certificates.</pre>
856 <p>Later in the same thread:</p>
857 <pre>Subject: Re: [Users] FreeSWAN and Cisco VPN CONCENTRATOR
858 Date: Thu, 25 Oct 2001
859 From: Ghislaine Labouret <Ghislaine.Labouret@hsc.fr>
860 Organization: HSC (Herve Schauer Consultants)
864 > I've been trying to get those two to interoperate with certificates, but
865 > I have only succeeded with PSK. Can you shed some light on how you did
868 I will put the config files and different tests results from the demo on
869 http://www.hsc.fr/ipsec/ipsec2001/ next week.
871 With VPN3000, we had a problem with the DN comparison because of
872 encoding issues. The solution was to specify the VPN 3000 DN in binary
873 format in ipsec.conf. I leave it to Andreas Steffen to explain the exact
874 issue, as he is the one who solved it.</pre>
876 <h3><a name="bay">Nortel (Bay Networks) Contivity switch</a></h3>
878 <p>There is one known issue in FreeS/WAN-to-Contivity interoperation. Recent
879 versions of FreeS/WAN no longer support DH group 1 for key exchange. Older
880 versions of Contivity software support nothing else. Group 2 was added in
881 more recent releases. So:</p>
883 <li>older FreeS/WANs, such as 1.5, will work with any Contivity software.
884 Key exchange will be done using DH Group 1. This may not be secure.</li>
885 <li>current FreeS/WANs will work only with recent Contivity releases
886 supporting DH Group 2. Contivity 3.5 is one such release.</li>
889 <p>We recommend using a current software on both ends.</p>
891 <p>Some messages from the mailing list:</p>
892 <pre>Subject: Contivity Extranet Switch
893 Date: Fri, 11 Jun 1999
894 From: Matthias David Siebler <msiebler@nortelnetworks.com>
895 Reply-To: msiebler@alum.mit.edu
896 Organization: Nortel Networks
898 More interoperability results:
900 I successfully established a tunnel with a Nortel (formerly Bay (formerly New Oak)) Contivity
901 Extranet Switch running the latest release versions.
903 The CES is running V2.50 of the software and the Linux server is running V1.0.0 of the Free/SWAN
904 code on a RedHat 5.2 unit with the kernel upgraded to 2.0.36-3
906 I am using IKE with 3DES-HMAC-MD5
908 Note however, that tunnels cannot yet be configured as client tunnels since Free/SWAN does not yet
909 support aggressive mode. Hopefully, that will arrive soon, which would allow remote users to
910 connect to a CES using the Free/SWAN code as clients.</pre>
912 <p>and apparently Nortel want their product to work with FreeS/WAN:</p>
913 <pre>Subject: Is FreeSwan 3.1 a legitamate ipsec implementation when compared to its commercial competitors?
914 Date: Tue, 02 May 2000
915 From: Bill Stewart <bill.stewart@pobox.com>
917 Nortel's Contivity IPsec server has a formal policy of interoperability
918 with FreeS/WAN. I was quite pleased to hear it when they last talked to us,
919 and it makes sense in their business environment, since they let you use
920 their WinXX client software free, so this gives them support for Linux
923 <p>A more recent mailing list report is:</p>
924 <pre>Subject: Nortel Contivity and Free-S/WAN
925 Date: Wed, 7 Mar 2001
926 From: "JJ Streicher-Bremer" <jj@digisle.net>
928 OK, here is a very brief nuts and bolts breakdown on how to get this
929 combo working. I want to thank everyone at Free-S/WAN and everyone on
930 the list for your help in getting this to work.
932 Connecting FreeS/WAN to the Nortel Networks Contivity Extranet Switch:
935 FreeS/WAN v1.5 and Contivity ver 2.5 - 3.5 (might work with earlier
936 versions, but I have not tested it with this config)
938 FreeS/WAN v1.8 and COntivity ver 3.5 (the 3.5 version supports Diffe
939 Hilman group 2 key exchange)
942 1 - Configure the Contivity:
943 Set up a branch office tunnel group with the following settings:
947 Access Hours: Anytime
948 Call Admission Priority: Highest Priority
949 Forwarding Priority: Low Priority
950 Idle Timeout: 00:00:00
951 Forced Logoff: 00:00:00
953 RSVP: Token Bucket Depth: 3000 Bytes
954 RSVP: Token Bucket Rate: 28 Kbps
955 Branch Office Bandwidth Policy:
956 - Committed Rate: 56 Kbps
957 - Excess Rate: 128 Kbps
958 - Excess Action: Mark
961 - ESP - Triple DES with SHA1 Integrity: Enabled
962 - ESP - Triple DES with MD5 Integrity: Enabled
963 - ESP - 56-bit DES with SHA1 Integrity: Disabled
964 - ESP - 56-bit DES with MD5 Integrity: Disabled
965 *IKE Encryption and Diffie-Hellman Group: Triple DES with Group
968 Perfect Forward Secrecy: Enabled
969 Compression: Disabled
970 Rekey Timeout: 08:00:00
971 Rekey Data Count: (None)
972 *ISAKMP Retransmission Interval: 16
973 *ISAKMP Retransmission Max Attempts: 4
975 Set up a branch office tunnel inside this new group with the
979 Local - Public address of your COntivity
980 Remote - Your Free-S/WAN interface Address
982 IPSEC Authentication - Text Pre-Shared Key
983 One note here, I have had some trouble trying to use HEX
984 or Non alphanumeric chars in this key.
988 Local - networks you want to be able to access through the
990 Remote - networks that will be allowed through the tunnel
993 Get routing setup on your office network:
994 You will need to get a routing entry that will point all traffic
995 bound for your home network (the one that will be acciessible through
996 the tunnel) to the internal interface of the contivity system.
998 Configure Free-S/WAN:
999 Install, compile, and test Free-S/WAN
1000 Edit ipsec.conf for your new tunnel:
1001 --------------------------------------------------------
1004 interfaces="ipsec0=eth1"
1022 leftnexthop=10.0.0.1
1023 leftsubnet=10.0.1.0/24
1025 rightsubnet=172.16.1.0/24
1036 leftnexthop=10.0.0.1
1037 leftsubnet=10.0.1.0/24
1039 rightsubnet=172.16.2.0/24
1042 10.0.0.2 172.16.0.2 "Your big secret"
1043 ---------------------------------------------
1045 The above config is for this imaginary network:
1048 10.0.1.1 | |10.0.0.2 10.0.0.1++ Internet
1049 ---------| |-------------------++===========
1050 +------+ Home Router
1054 Internet ++ 172.16.0.2#### 172.16.1.0/24 These
1055 =========++--------------####---------172.16.2.0/24 are here somewhere
1056 Office Router Contivity
1059 This has worked for me. I am still having trouble with the tunnels
1060 dying after about 30-40 minutes of non-use. Don't know what that is
1061 about, but I'll keep you posted.</pre>
1063 <h3><a name="Raptor">Raptor Firewall</a></h3>
1065 <h4><a name="raptorNT">Raptor 5 on NT (old info)</a></h4>
1066 <pre> Subject: Interoperability with Raptor 5 (Success!)
1067 Date: Wed, 06 Jan 1999 16:19:27 -0500
1068 From: Chuck Bushong <chuckb@chandler-group.com>
1070 I don't know if this is useful information for anyone, but I have
1071 successfully established a VPN between RedHat 5.1 (kernel 2.0.34) running
1072 FreeS/WAN 0.91 and NT4 running Raptor 5. However, Pluto does not appear
1073 compatible with the Raptor IKE implementation. . . .
1075 Subject: RE: Interoperability with Raptor 5 (Success!)
1076 Date: Thu, 28 Jan 1999 17:22:55 -0500
1077 From: Chuck Bushong <chuckb@chandler-group.com>
1079 ... this VPN (at least the klips end) has been up under minimal
1080 utilization for three weeks plus without interruption. The
1081 machine seems very stable. Pat yourself on the back, gentlemen.
1082 Your beta release is more stable than certain companies' shipping
1085 Keep up the good work.</pre>
1087 <h4><a name="raptorsun">Raptor 6 on Solaris</a></h4>
1088 <pre>Subject: Re: successful interop. with Raptor 6.02
1089 From: "Charles G. Griebel" <cggrieb@biw.com>
1090 Date: Tue, 25 Jul 2000
1092 On Thu, Jul 20, 2000 at 12:04:40PM -0700, Kevin Traas wrote:
1093 > Great! I'm just about to start looking into this as well, so any
1094 > docs/info you can provide would be *greatly* appreciated. Immortalize
1095 > yourself! Get something written and added to the compatibility.html
1096 > file. Many will thank you.
1098 Can't be that hard. I'm just a freeswan newbie who hasn't even done a FS<->FS
1101 Anyway, I hope you find this helpful.
1105 -------------------------------------------------------------------------------
1107 Automatically keyed 3DES VPN between Raptor 6.02 on Solaris 2.6 (left) and
1108 FreeS/WAN 1.5 on 2.2.16 Intel (right)
1110 FreeS/WAN (right) information:
1111 -----------------------------
1116 interfaces="ipsec0=ppp0" # change to suite
1124 leftnexthop=10.0.0.2
1125 leftsubnet=192.168.0.0/24
1127 rightnexthop=10.1.1.1
1128 rightsubnet=172.16.1.0/24
1137 # note I haven't verified that underscores will actually work
1138 10.0.0.1 10.1.1.1: PSK "some_long_secret_with_plenty_of_chars"
1140 Raptor 6.02 (left) information:
1141 ------------------------------
1143 Name: left-external-kp-dynamic
1145 Profile Describing: local entity
1147 Identification Type: Address
1148 Identification: 10.1.1.1
1149 ISAKMP Hash Method: MD5
1150 ISAKMP Authentication: Shared_Key
1151 Shared Secret: some_long_secret_with_plenty_of_chars
1152 Time Expiration: 1080
1154 Name: right-external-kp-dynamic
1156 Profile Describing: remote entity
1158 Identification Type: Address
1159 Identification: 10.0.0.1
1162 Name: left-ss-dynamic
1163 Address: 192.168.0.0
1164 Netmask: 255.255.255.0
1165 Key Profile: left-ss-dynamic
1167 Name: right-ss-dynamic
1169 Netmask: 255.255.255.0
1170 Key Profile: right-ss-dynamic
1173 Name: left-to-right-tunnel
1174 Entity A: right-ss-dynamic
1175 Entity B: left-ss-dynamic
1176 Encapsulation: ISAKMP
1178 Pass traffic through proxies: [unchecked]
1179 Use Authentication Header: [unchecked]
1180 Use Encryption Header: [checked]
1181 Data Integrity Algorithm: MD5
1182 Data Privacy Algorithm: 3DES
1185 Data volume timeout: 2100000
1186 Lifetime timeout: 480
1187 Inactivity timeout: 0
1188 Transport mode: [unchecked]
1189 Perfect forward secrecy: [unchecked]
1194 I made the addresses fictitious RFC1918 addresses.
1195 I haven't tried PFS.
1196 I had problems getting an SA with manual keying -- I think it may be with the
1199 <h4><a name="raptorman">Raptor manual keying</a></h4>
1201 <p>A mailing list suggestion from FreeS/WAN technical lead Henry Spencer:</p>
1202 <pre>> In the Raptor settings, there are 2 sets of data (1 for each end). Each set
1203 > contains an SPI, 3 DES Keys and 1 MD5 hash. I only know how to include one
1204 > set, how do I include the other set? Is the other set needed?
1206 They may be using different keys for each direction, which is a bit
1207 unusual for manual keying, but not impossible. The simplest thing is
1208 probably to just give it two identical sets of data -- that should work.
1209 FreeS/WAN has provisions for asymmetric keys etc. in manual keying, but
1210 that stuff is lightly documented and lightly tested.</pre>
1212 <h3><a name="gauntlet">Gauntlet firewall GVPN</a></h3>
1213 <pre>Subject: Successful interop: FreeS/WAN 1.7 <-> Gauntlet Firewall GVPN 5.5
1214 Date: Tue, 21 Nov 2000
1216 Sending the following to the list, at Hugh's request.
1218 -----Original Message-----
1219 From: Reiner, Richard
1220 Sent: Tuesday, November 21, 2000 11:34 AM
1221 To: 'hugh@mimosa.com'
1225 > Good. But we don't think that you should be using our IPCOMP just
1226 > yet. It is flaky :-(
1228 I've seen no anomalies, although "allow ipcomp" is on at the Gauntlet
1229 end. Looking at my ipsec.conf I actually find no refereence to ipcomp.
1230 I presume it is disabled by default. In addition, reviewing my logs
1231 both on the Gauntlet end and the Linux end, I see nothing I can
1232 interpret as an indication that ipcomp was enabled during negotiation.
1233 So I have to correct my previous posting - I believe the link is *not*
1236 > This is interesting and we'd love a more complete writeup. It should
1237 > get incorporated into our interop documentation.
1239 Here are the relevant bits from ipsec.conf:
1242 interfaces=%defaultroute
1249 conn freeswan17-gauntlet55
1254 leftsubnet=10.0.1.0/24
1256 rightnexthop=3.3.3.4
1257 rightsubnet=10.0.2.0/24
1269 All settings on the Gauntlet side are the same (not shown here, as GUI
1270 screenshots are hard to show in ASCII... and the textual format that is
1271 generated by the Gauntlet GUI is ugly in the extreme).
1273 Note that ikelifetime is 1440m by default on the Gauntlet end, but
1274 freeswan does not support this value (max appears to be 480m), thus the
1275 Gauntlet end is also set to 480m to match freeswan's value.
1277 Also worth noting: I am using the excellent Seawall scripts to manage
1278 ipchains configuration on the freeswan end. It automatically generates
1279 a correct set of firewall rules for the link (along with doing many
1280 other convenient things).</pre>
1281 For more information on Seawall (the Seattle Firewall), see that project's <a
1282 href="http://seawall.sourceforge.net/">home page</a> on Sourceforge.
1284 <h3><a name="checkpoint">Checkpoint Firewall-1</a></h3>
1287 href="http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/fw-linuxvpn.pdf">HowTo</a>
1288 for connecting FreeS/WAN and this product can be downloaded from the vendor's
1289 site or browsed at a VPN mailing list <a
1290 href="http://kubarb.phsx.ukans.edu/~tbird/vpn.html">site</a>.</p>
1292 <p>A <a href="http://www.phoneboy.com/">resource page</a> full of Firewall-1
1295 <p>The mailing list reports success with this combination, but also some
1296 problems. Search the <a href="mail.html#archive">archives</a> for the full
1299 <p>Here is one message, about what seems to be the biggest problem:</p>
1300 <pre>Subject: Re: Pb establishing connection from FW1/3DES/SP2 with freeswan 1.5 - ACTE 2
1301 Date: Tue, 6 Feb 2001
1302 From: Claudia Schmeing <claudia@freeswan.org>
1304 > Thanx to Michael and Claudia, but this doesn't work from VPN1 to linux (as
1305 > linux to VPN1 is OK).
1308 > I think that VPN1 doesn't send "192.168.1.0/24" but "192.168.1.20/32" and,
1309 > as Claudia said, IPSEC SA need to match Exactly.
1311 I don't know about the rules on the VPN-1. You'll have to rely on people
1312 with applicable experience there...
1314 > Is it possible that freeswan doesn't do the inclusion process (ie if he
1315 > receive 192.168.1.20/32, i doesn't match that this is include in
1316 > 192.168.1.0/24) ?
1318 Yes, that's correct. It needs to match exactly, and inclusion is not
1319 part of this process.
1321 > Btw why VPN/1 send 192.168.1.20/32 and not 192.168.1.20/24 (the value that
1322 > Freeswan is waiting for)? A bug?
1324 I think Michael may be able to help you with this.
1326 > Have i a way to force Freeswan to do the "inclusion" (ie accept
1327 > 192.168.1.20/32 as a part of 192.160.1.20/24, even if the 2 IPSEC Sa
1328 > doesn't match exactly) ?
1331 Another strategy is to accept the fact that the Checkpoint
1332 proposes separate connections for each machine. If you define
1333 and add each of these connections on the Linux FreeS/WAN side, then
1334 Linux FreeS/WAN ought to accept the Checkpoint's proposals.
1336 The only possible difficulty with this strategy is that I don't know
1337 how Linux FreeS/WAN handles the concept of overlapping tunnels. I
1338 believe, though, that these tunnels can coexist, and if for any
1339 packet there are two options, a more general and a less general, the
1340 packet will be handled by the more specific tunnel. You would need
1341 to do a little testing to ensure you understand the behaviour and
1342 that this does actually solve your problem.
1344 I think it would be simplest to try to get the Checkpoint to propose the
1345 more general tunnel. Since I don't recall having seen this problem before,
1346 I suspect the simpler solution is doable.</pre>
1348 <h3><a name="redcreek">Redcreek Ravlin</a></h3>
1350 <p>We have reports of successful interoperation at an interop <a
1351 href="http://www.opus1.com/vpn/atl99display.html">conference</a>, but there
1352 is also a mailing list <a
1353 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00510.html">thread</a>
1354 discussing difficulties some users have encountered.</p>
1356 <h3><a name="sentinel">SSH Sentinel</a></h3>
1359 href="http://www.ssh.com/support/sentinel/documents.cfm">web site</a> has
1360 configuration examples for use with FreeS/WAN.</p>
1362 <p>One user reports:</p>
1363 <pre>Subject: [Users] Very Useful document, can a link to it be put on the FreeS/WAN web site?
1364 Date: Fri, 19 Oct 2001
1365 From: Simon Matthews <simon@paxonet.com>
1367 This is a very useful document on getting SSH Sentinel to work with
1368 FreeS/WAN using x509 certificates.
1369 http://www.ssh.com/download_files/openssl_mini-ca.pdf
1371 Perhaps a link to it could be put on the web site.
1373 There is also another document on FreeS/WAN <> SSH Sentinel interoperability: http://www.ssh.com/products/sentinel/SSH_Sentinel_Config_Examples.pdf Simon </pre>
1375 <p>The vendor seems serious about interop with us. Here is a message one of
1376 their staff posted on our list:</p>
1377 <pre>From: Jussi Torhonen <jt@ssh.com>
1378 Organization: SSH Communications Security Corp - http://www.ssh.com
1379 Subject: [Users] SSH Sentinel VPN client public beta #3 now available
1380 Date: Thu, 31 May 2001
1382 Hello, FreeS/WAN community !
1384 SSH Communications Security Corp has released a new public beta #3
1385 version of SSH Sentinel VPN client for Windows. We've got a lot of
1386 reports also from FreeS/WAN community and with that feedback we've
1387 improved interoperability and stability.
1389 For example PFS (Perfect Forward Secrecy in IKE rekey) can now be used
1390 between SSH Sentinel and FreeSWAN, and if using that user contributed
1391 X.509 patch and exporting the certificate from SSH Sentinel, now those
1392 -----[BEGIN|END] CERTIFICATE----- headers/footers are properly included
1393 in the exported PEM formatted certificate, so it can be imported to
1394 FreeSWAN with fswcert utility and OpenSSL tools.
1396 Thank you a lot for your feedback, colleagues !
1398 You can get that new public beta #3 and PDF formatted User Manual from
1399 ftp://ftp.ssh.com/pub/sentinel/ or via website
1400 http://www.ipsec.com/products/sentinel/beta/register.html
1402 For more information about the product, please check our website
1403 http://www.ipsec.com
1405 We eagerly want to make SSH Sentinel as the best VPN client on the
1406 market. If you want to contact our support, please send e-mail to
1407 sentinel-support@ssh.com or fill up our feedback form at
1408 http://www.ipsec.com/support/sentinel/beta_report.html
1411 Jussi Torhonen, SSH Sentinel Team
1412 Kuopio, Finland</pre>
1414 <p>There is one known problem withh SSH-FreeS/WAN interoperation, described
1415 in this message:</p>
1416 <pre>Subject: Re: [Users] Any plans for AES / Rijndael support ?
1417 Date: Tue, 11 Dec 2001
1418 From: Jussi Torhonen <jt@ssh.com>
1419 Organization: SSH Communications Security Corp - http://www.ssh.com
1423 > ... the installation
1424 > of Sentinel don't let you set 3DES as the default!
1425 > And when your want to add a connection the first
1426 > diagnostic-test goes wrong ! :-( ...
1428 In current SSH Sentinel release you can select 'Legacy proposal' option,
1429 when setting up a VPN Connection profile. That causes it to use 3DES
1430 as a default cipher and DES as a alternative one. The option was added
1431 there just to improve interoperability with legacy systems supporting
1432 3DES or even DES only.
1434 If no selecting Legacy Proposal option, SSH Sentinel sends quite a huge
1435 proposal list to the responder to find automatically one common cipher
1436 supported to be used for the connection. That proposal list is known to
1437 be problematic for some VPN gateway implementations like FreeSWAN.
1438 Typically the long proposal list itself may the a problem or fragmented
1439 packets of the long proposal list may be a probem.
1441 Now we've been living in a world of DES and 3DES, but hopefully in a
1442 near future the use of AES/Rijndael will increase. ...</pre>
1444 <p>FreeS/WAN does not yet support <a href="glossary.html">AES</a>.</p>
1446 <h3><a name="Fsecure">F-Secure VPN for Windows</a></h3>
1447 <pre> Subject: Identification through other than IP number
1448 Date: Tue, 13 Apr 1999
1449 From: Thomas Bellman <bellman@signum.se>
1451 ... Currently we are trying to interop FreeS/WAN
1452 with F-Secure VPN+ Client 4.0 (for MS Windows), and as long as
1453 the Windows machine has a fix IP address, and are initiating the
1454 IKE negotiations, things are working well. However, when the IP
1455 address is changing, it doesn't work. ...
1456 (I'll try to write something up about the problems we are having
1457 when Pluto is initiatior in another message.)</pre>
1459 <h3><a name="watchguard">Watchguard</a></h3>
1461 <p>Watchguard make a Linux-based firewall product. Ipchains author Rusty
1462 Russell thanks them for support and recommends them in one of his <a
1463 href="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-3.html#ss3.2">HowTos</a>.
1464 On the other hand, some comments on our mailing list about the Watchguard
1465 product have been quite unfavourable. See, for example, this <a
1466 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/08/msg00474.html">archive
1469 <p>Watchguard do not use FreeS/WAN in their product. They have their own
1470 IPsec implementation.</p>
1472 <p>We have had mailing list reports of successful interoperation between
1473 FreeS/WAN and the Watchguard firewall, using manually keyed connections. The
1474 user could not get automatically keyed connections to work; the message below
1477 <p>Here is some mail from a Watchguard employee about interoperation:</p>
1478 <pre>Subject: FreeS/WAN and WatchGuard Firebox interop
1479 Date: Mon, 18 Dec 2000
1480 From: Max Enders <menders@watchguard.com>
1482 I was recently given the task of testing IPSec interoperability
1483 with our product, the Firebox. I just wanted to let you know that
1484 I had success with a manual keyed tunnel. Here's what I used for
1488 Linux 2.2.18 i686 unknown
1490 "Trusted" interface: 192.168.0.1/24
1491 "External" interface: 192.168.1.1/24
1494 WatchGuard Live Security System v4.5
1495 Trusted interface: 192.168.2.1/24
1496 External interface: 192.168.1.2/24
1498 Because FreeS/WAN does not implement single DES, a dynamic keyed
1499 tunnel will not work. Our product strictly uses DES for main mode.
1500 We hope to address this in a future release. Here are instructions
1501 for configuring the Firebox:
1503 Open the Policy Manager and create a new IPSec gateway. Set the Key
1504 Negotiation Type to manual and enter the FreeS/WAN box's external
1505 IP address for the Remote Gateway IP. Configure a new tunnel with
1506 a unique SPI. Select 3DES-CBC for Encryption and MD5-HMAC for
1507 Authentication. Make an Encryption Key and Authentication Key.
1508 Copy the values and save them for configuration of the FreeS/WAN box.
1509 Configure a routing policy and any necessary services as you normally
1512 Here's how I configured FreeS/WAN:
1514 Modifications to /etc/ipsec.conf:
1516 Under the "config setup" section, add:
1520 At the end of the file, add the following connection:
1524 leftsubnet=192.168.0.0/24
1526 rightsubnet=192.168.2.0/24
1529 espenckey=0x515b0875793e3708517c3d4554012f7c0273375e51572a31
1530 espauthkey=0x072649041c2c0d452f7c15407576522f
1532 The spi used here should match the Firebox's. Note that the Policy Manager
1533 expects an SPI in decimal, not hexadecimal. The espenckey value should be
1534 0x and the Encryption Key you're using on the Firebox. Likewise for
1535 espauthkey and the Authentication Key on the Firebox.</pre>
1537 <pre>Subject: RE: Freeswan
1538 Date: Wed, 7 Feb 2001
1539 From: "Patrick Poncet" <pponcet@vaxxine.com>
1543 Voila... I wish to thank all the FreeS/WAN for putting out such a great
1544 product out! And also Philippe PAULEAU who pioneered interoperability
1545 between FreeS/WAN and Watchguard Firebox II and therefore showed me that my
1546 efforts would not be wasted!...
1548 Yes indeed FreeS/WAN to WatchGuard Firebox only works in manual keying mode
1549 and the best way to generate keys is to have the firebox generate the keys,
1550 then copy and paste into the ipsec.conf file on the FreeS/WAN side (don't
1551 forget to prefix the keys with '0x' in your ipsec.conf file.
1553 Also keep in mind that the SPI is in decimal on the Firebox side and HEX on
1554 the FreeS/WAN side!!! We spent 4 hours on fixing this HEX-DEC issue only :)</pre>
1556 <h3><a name="Xedia">Xedia Access Point/QVPN</a></h3>
1557 <pre> Subject: Interoperability result
1558 Date: Mon, 15 Mar 1999 18:08:12 -0500
1559 From: Paul Koning <pkoning@xedia.com>
1561 Here's another datapoint for the "FreeS/WAN interoperability
1564 I tested 0.92 against the Xedia Access Point/QVPN product, using
1565 dynamic keying (i.e., Pluto at work).
1567 Results: it works fine so long as you ask for 3DES. DES and no-crypto
1568 modes don't work when Pluto is involved.
1570 I did limited data testing, which seemed to be fine. No performance
1571 numbers yet, could do that if people are interested.
1573 Any questions, please ask.
1577 <h3><a name="pgpnet">PGP Mac and Windows IPsec client (PGPnet)</a></h3>
1579 <h3>McAfee VPN Client</h3>
1581 <p>From version 6.5 (1999) on, the <a href="glossary.html#PGP">PGP</a>
1582 products from <a href="http://www.pgp.com/">PGP Inc.</a> included an IPsec
1583 client program called PGPnet.</p>
1585 <p>The parent company, <a href="glossary.html#NAI">NAI,</a> have since
1586 re-organised their product line. They no longer sell PGP (it was put into
1587 maintenance in February 2002) and the IPsec product is now called McAfee VPN
1590 <p>Here is the first message about PGPnet to our mailing list, from a senior
1592 <pre> Subject: PGPnet interoperable with FreeSWAN
1593 Date: Mon, 05 Apr 1999 18:06:13 -0700
1594 From: Will Price <wprice@cyphers.net>
1596 Network Associates announced PGP 6.5 today. It includes a new product
1597 PGPnet which is a full IKE/IPSec client implementation. This product
1598 is for Windows and Macintosh. I just wanted to send a brief note to
1599 this list that the product was compatibility tested with FreeSWAN
1600 prior to its release, and the tests were successful!
1603 Will Price, Architect/Sr. Mgr., PGP Client Products
1604 Total Network Security Division
1605 Network Associates, Inc.</pre>
1607 <p>One version is downloadable at no cost for non-commercial use. See our <a
1608 href="web.html#tools">links</a>. That version does not support subnets.</p>
1610 <p>Several of the user-written HowTos mentioned <a href="#otherpub">above</a>
1611 cover interoperation between PGPnet and FreeS/WAN.</p>
1613 <p>A more recent post from the same PGP Inc staff member pointed out:</p>
1614 <pre>Make sure you're using PGP 7.0 or later as the key parser was improved
1615 in that release. (PGP 7.0.1 was just released)</pre>
1617 <p>Various users have reported various successes and problems talking to
1618 PGPnet with FreeS/WAN. There has also been a fairly complex discussion of
1619 some fine points of RFC interpretation between the implementers of the two
1620 systems. Check an archive of our <a href="mail.html">mailing list</a> for
1623 <p>A post summarising some of this, from our Pluto programmer:</p>
1624 <pre> Subject: PGPnet 6.5 and freeswan
1625 Date: Sun, 16 Jan 2000
1626 From: "D. Hugh Redelmeier" <hugh@mimosa.com>
1630 | OK, I'm stumped. I am trying to configure IPSEC to support road
1631 | warriors using PGPnet 6.5.
1633 | I've set up everything as per the man pages on the ipsec side.
1635 | I've set up everything on the PGPnet side per the docs for that package.
1637 | Pluto fails with this:
1639 | Jan 16 08:14:11 aphrodite Pluto[26401]: "homeusers" #8: no acceptable
1642 | and then it terminates the connection.
1644 As far as I can tell/remember, there are three common ways that PGPnet
1645 and FreeS/WAN don't get along.
1647 1. PGPnet proposes a longer lifetime for an SA than Pluto is willing
1650 2. After rekeying (i.e. after building a new SA bundle because the old
1651 one is about to expire), FreeS/WAN immediately switches to the new
1652 one while PGPnet continues using the old
1654 3. FreeS/WAN defaults to expecting Perfect Forward Secrecy and PGPnet
1657 Perhaps you are bumping into the first. In any case, look back
1658 in the log to see why Pluto rejected each transform</pre>
1660 <p>Some advice from the mailing list:</p>
1661 <pre> Subject: Re: Secure Gate Fails- PGPNet & FreeSwan
1662 Date: Wed, 28 Jun 2000
1663 From: Andreas Haumer <andreas@xss.co.at>
1665 I have a PGPnet setup running with FreeS/WAN working as secure
1666 gateway. It works quite fine, except for a re-negotiation problem
1667 I'm currently investigating, and in fact I have it running on some
1668 test equipment here right now!
1670 As I tried _several_ different non-working configuration settings
1671 I think I know the exact _one_ which works... :-)
1673 Here's my short "HOWTO":
1675 FreeS/WAN version: snap1000jun25b
1676 PGPnet: PGP Personal Privacy, Version 6.5.3
1677 Linux: 2.2.16 with some patches
1682 internal subnet [192.168.x.0/24]
1685 secure gateway with FreeS/WAN
1693 | [dynamically assigned IP address]
1694 road-warrior with PGPnet
1697 Configuration of FreeS/WAN:
1698 ==========================
1703 interfaces=%defaultroute
1720 leftsubnet=192.168.x.0/24
1725 b) /etc/ipsec.secrets
1727 a.b.c.x 0.0.0.0: "my very secret secret"
1730 Note: If you are running ipchains on your secure gateway,
1731 you have to open the firewall for all the IPsec packets
1732 and also for traffic from your ipsec interface!
1733 Don't masquerade the IPsec traffic!
1735 Check your logfiles if the firewall is blocking some
1739 Configuration of PGPnet:
1740 =======================
1742 (note that there is an excellent description, including
1743 screenshots of PGPnet, on <http://jixen.tripod.com/>)
1745 In short, do the following:
1747 Launch the PGPnet configuration tool and set defaults options
1748 =============================================================
1750 Start - Program - PGP - PGPnet
1754 Allow communications with unconfigured hosts
1755 Require valid authentication key
1756 Cache passphrases between logins
1761 Ciphers : Tripple DES
1763 Diffie-Hellman : 1024 and 1536
1764 Compression : LZS and Deflate
1765 Make the IKE proposal :
1766 Shared-Key - MD5 - 3DES -1024 bits on top of the list (move up)
1767 Make the IPSec proposal :
1768 NONE - MD5-TrippleDES -NONE on top of the list (move up)
1769 Select Perfect Forward Secrecy = 1024 bits
1773 Create the connection's definition.
1774 ==================================
1776 In the Hosts panel, ADD
1777 Name : Enter a name for the right gateway
1778 IPaddress : Enter its IP address visible to the internet (a.b.c.x)
1779 Select Secure Gateway
1780 Set shared Paraphrase : enter you preshared key
1781 Identity type : select IP address
1782 Identity : enter 0.0.0.0
1783 Remote Authentication : select Any valid key
1785 Select the newly created entry for the right gateway and click ADD,
1787 Name : Enter a name for the central subnet
1788 IP address : Enter its network IP address (192.168.x.0)
1789 Select Insecure Subnet
1790 Subnet Mask : enter its subnetmask (255.255.255.0)
1794 This should be it. Note that with this configuration there is
1795 still this re-keying problem: after 6 hours, the SA is expired
1796 and the connection fails. You have to re-connect your connection
1799 <p>and a note from the team's tech support person:</p>
1800 <pre>Date: Thu, 29 Jun 2000
1801 From: Claudia Schmeing
1803 There is a known issue with PGPNet which I don't see mentioned in the docs.
1804 It's likely related to this one, that you note on the site:
1806 >2. After rekeying (i.e. after building a new SA bundle because the old
1807 > one is about to expire), FreeS/WAN immediately switches to the new
1808 > one while PGPnet continues using the old
1810 The issue is: When taking down and subsequently recreating a connection,
1811 it can appear to come up, but it is unusable because PGPNet continues
1812 to use an old SA, which Linux FreeS/WAN no longer recognizes. The solution is
1813 to take down the old connection using PGPNet, so that it will then
1814 use the most recently generated SA.</pre>
1816 <h3><a name="IRE">IRE Safenet/SoftPK</a></h3>
1818 <p>IRE have an extensive line of IPsec products, including firewall software
1819 with IPsec, and hardware encryption devices for LAN or modem links. Their
1820 Soft-PK is a Win 98 and NT client. Quite a few people have used this with
1821 FreeS/WAN and, judging by mailing list reports, have had good results.</p>
1823 <p>SoftRemote is newer product integrating the IPsec client with personal
1824 firewall software. As yet, we have few reports on this. One is quoted <a
1825 href="#softremote">below</a>.</p>
1827 <h4><a name="softPK">SoftPK</a></h4>
1829 <p>Several documents are available:</p>
1832 href="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">PDF
1833 HowTo</a> titled <cite>FreeS/WAN 1.8 <--> IRE Safenet SoftPK 5.1.0
1834 Road-Warrior VPN Configuration Guide</cite> from Terradon
1835 Communications.</li>
1837 href="http://www.redbaronconsulting.com/freeswan/fswansafenet.pdf">PDF
1838 document</a> from Red Baron Consulting.</li>
1839 <li><a href="http://jixen.tripod.com/#Rw-IRE-to-Fwan">IRE-to-FreeS/WAN
1840 section</a> of Jean-Francois Nadeau's configuration document</li>
1843 <p>Some messages from the mailing list:</p>
1844 <pre>Subject: Re: Identification through other than IP number
1845 Date: Fri, 23 Apr 1999
1846 From: Tim Miller <cerebus+counterpane@haybaler.sackheads.org>
1850 > Anyone know of a low-cost MS-Win client that interoperates and does not
1851 > require purchasing a server license to get it?
1853 SafeNet/Soft-PK from IRE (http://www.ire.com) is a low-cost
1854 client (though I don't have the exact cost available at the moment).
1855 I've got it running on an NT4 workstation and it interoperates nicely
1856 (in transport mode, will try tunnel later) with FreeS/WAN. It's also
1857 ICSA IPsec certified.</pre>
1859 <p>A later report with some setup details:</p>
1860 <pre>Subject: RE: PGPnet and Freeswan one more time...
1861 Date: Sat, 16 Dec 2000
1862 From: "Tim Wilson" <timwilson@mediaone.net>
1864 Here are some details about using the IRE SafeNet Soft/PK client with a
1867 I applied the x509 patch to Pluto according to the instructions. I use the
1868 "leftcert" and "rightcert" keywords in the ipsec.conf file. This causes
1869 FreeSwan to read the public keys and identities from the cert files. The
1870 identities wanted and used by FreeSwan will then be the DNs in the certs.
1872 I used OpenSSL to generate keys and certs and to sign certs. When generating
1873 the gateway cert, you should *not* enter an e-mail address because it turns
1874 out that confuses Soft/PK. Also, Andreas Steffan tells me that you want to
1875 keep the cert short to avoid fragmentation, so use a 1024-bit RSA key and
1878 The FreeSwan gateway cert goes in /etc/ipsec.d/, the gateway private key is
1879 extracted from the key file using fswcert (part of the x509 patch) and
1880 pasted into /etc/ipsec.secrets, and a DER version of the gateway cert goes
1881 in /etc/x509cert.der. This is all according to the instructions that
1882 accompany the x509 patch.
1884 The Windows client is of course running Soft/PK in this case. I generated a
1885 private key and cert for the client on the Linux machine using OpenSSL. I
1886 created a pkcs12 file containing the client's private key and cert, which I
1887 put on a floppy and imported into Soft/PK. I also imported the gateway cert
1888 into Soft/PK (you can either import a self-signed cert for the gateway or
1889 the self-signed cert for the CA that signed the gateway cert--either works).
1891 Soft/PK allows you to configure practically everything for the connection.
1892 Here are the main points to watch for:
1894 On the first panel you have to set the peer identities. The gateway will
1895 identify itself using the DN in the gateway cert. So of course you have to
1896 configure Soft/PK to look for the correct DN. There's no problem with this
1897 as long as you didn't enter an e-mail address in the gateway cert. Just
1898 check "Connect using Secure Gateway tunnel", set ID type to "Distinguished
1899 Name", and enter the correct info in the dialog box.
1901 In "My identity" just select the client cert that you imported in pcks12
1902 format. Soft/PK apparently identifies itself with the DN from the cert,
1903 which is exactly what FreeSwan is looking for.
1905 In "Security Policy", you want Main mode and make the PFS setting agree with
1906 whatever FreeSwan is doing (FreeSwan uses PFS by default). If you use PFS I
1907 believe you must use DH group 2 as FreeSwan doesn't like group 1.
1909 Phase 1 Authentication must be "RSA signatures" and 3DES plus either MD5 or
1910 SHA-1 (I used MD5 but I believe FreeSwan accepts either). I left the
1911 lifetime unspecified. Also you must select DH group 2 because I believe that
1912 FreeSwan will not accept group 1.
1914 Phase 2 also must use 3DES and MD5 or SHA-1. I used no compression and only
1915 ESP and no AH, haven't tried other choices.
1917 Hope this helps.</pre>
1919 <h4><a name="softremote">SoftRemote</a></h4>
1921 <p>Here is a mailing list message reporting experience with the newer
1922 SoftRemote product.</p>
1923 <pre>From: Whit Blauvelt <whit@transpect.com>
1924 Subject: Re: [Users] RE: SafeNet SoftRemote 6.1 - FS 1.91 - HOW?
1925 Date: Fri, 16 Nov 2001
1927 Things I've learned in getting SoftRemote working with FreeS/WAN:
1929 Using SoftRemote on dial-in, if there is any configuration adjustment for
1930 which you stop and start FreeS/WAN, SoftRemote is totally lost until you
1931 disconnect and dial in again. The SoftRemote "Disconnect All" and subsequent
1932 "Reload Polilcies" options that show when right-clicking its icon in the
1933 tray do not fix this - the only thing I've found that works is hanging up
1934 and then redialing. This makes debugging a total pain, especially if you
1935 think you're testing your changes, because you're not.
1937 Not sure if this affects fixed IP connections from SoftRemote, or what the
1938 effective equivalent to hanging up and dialing in again would be to clear
1939 the problem there if it exists.
1941 Also, as I noted before: In configuring SoftRemote, there are a couple of
1942 new menu options that Soft-PK didn't have, just in case you're following
1943 examples given for that. Importantly, in setting the "Remote Party Identity
1944 and Addressing" choose "IP subnet" rather than "IP", and be sure to provide
1945 a mask which matches the subnet mask for that conn in ipsec.conf (e.g.
1946 255.255.255.0 and /24). </pre>
1948 <p>Much of the infornation available <a href="#softPK">above</a> for the
1949 earlier SoftPK product should also apply to SoftRemote.</p>
1951 <h3><a name="borderware">Borderware</a></h3>
1953 <h3><a name="freegate">Freegate</a></h3>
1954 <pre>Subject: ipsec interoperability FYI
1955 Date: Sun, 02 May 1999
1956 From: Sean Rooney <sean@coldstream.ca>
1958 we've been doing some basic interoperability testing of the following;
1960 PGP NT VPN 6.5 and freeswan both seem to work reasonably well with
1961 Borderware 6.0 and freegate 1.3 beta. [as well as eachother]
1963 more details coming soon.</pre>
1965 <h3><a name="timestep">Timestep</a></h3>
1966 <pre> Subject: TimeStep Permit/Gate interop works!
1967 Date: Thu, 10 Jun 1999
1968 From: Derick Cassidy <dcthebrain@geek.com>
1970 Just a quick note of success. TimeStep Permit/Gate (2520) and
1971 Free/Swan (June 4th snapshot) interoperate!
1973 I have them working in AUTO mode, with IKE. IPSec SA's are negotiated
1976 Here are the configs and a diagram for both configs.
1978 left subnet---| Timestep | --- internet --- | Linux box |
1980 The left subnet is defined as the red side of the timestep box.
1981 This network definition MUST exist in the Secure Map.
1990 leftnexthop=209.yyy.xxx.1
1991 leftsubnet=209.yyy.xxx.128/25
1992 right=24.aaa.bbb.203
1993 rightnexthop=24.aaa.bbb.1
1994 rightsubnet=24.aaa.bbb.203/32
1999 In the TimeStep permit/gate Secure Map
2002 target "209.yyy.xxx.128/255.255.255.128"
2003 mode "ISAKMP-Shared"
2004 tunnel "209.yyy.xxx.6"
2007 In the TimeStep Security Descriptor file
2009 begin security-descriptor
2011 IPSec "ESP 3DES MINUTES 300 or ESP 3DES HMAC MD5 MINUTES 300"
2012 ISAKMP "IDENTITY PFS 3DES MD5 MINUTES 1440
2013 or DES MD5 MINUTES 1440"
2016 The timestep has a shared secret for 24.aaa.bbb.203/255.255.255.255
2017 set in the Shared Secret Authentication tab of Permit/Config.</pre>
2019 <h3><a name="shiva">Shiva/Intel LANrover</a></h3>
2021 <p>A <a href="http://snowcrash.tdyc.com/freeswan/">web page</a> with Shiva
2022 compatibility information.</p>
2024 <h3><a name="solaris">Sun Solaris</a></h3>
2025 <pre> Subject: Re: FreeS/WAN and Solaris
2026 Date: Tue, 11 Jan 2000
2027 From: Peter Onion <Peter.Onion@btinternet.com>
2029 Slowaris 8 has a native (in kernel) IPSEC implementation.
2031 I've not done much interop testing yet, but I seem to rememeber we got a manual
2032 keyed connection between it and FreeSwan a few months ago.</pre>
2034 <h3><a name="sonicwall">Sonicwall</a></h3>
2035 <pre>Subject: Re: FreeS/WAN and SonicWall
2036 Date: Mon, 5 Feb 2001
2037 From: "Dilan Arumainathan" <dilan_a@impark.com>
2039 ***************************************************
2040 I know I HAVE TO write the mini-howto - but here is the beginning
2041 ***************************************************
2043 Here is my Sonicwall configuration for my working connection:
2049 rightnexthop=y.y.y.y
2050 rightsubnet=10.1.20.0/24
2051 #You need to set the Unique Firewall Identifier to the parameter that you
2052 #use as the rightid. <------IMPORTANT
2053 rightid=sw@sonicwall.com
2060 Your /etc/ipsec.secrets should be like this:
2061 x.x.x.x y.y.y.y sw@sonicwall.com : PSK "opensesame"
2063 On the Sonicwall create a new connection:
2066 IPSec Gateway address: 0.0.0.0
2068 Encryption Method: Strong Encrypt and Authenticate( EPS 3DES HMAC MD5)
2069 Shared Secret: opensesame</pre>
2071 <h3><a name="radguard">Radguard</a></h3>
2073 <p>Here are some mailing list comments from FreeS/WAN tech support person
2074 Claudia Schmeing on this:</p>
2075 <pre>It certainly has been possible to interop between Radguard VPN gateways and
2076 past Linux FreeS/WAN versions, as is evidenced by
2077 http://www.opus1.com/vpn/atl99display.html, as well as my own interop results
2078 from San Diego this year. There have been no major changes since SD that
2079 I would foresee affecting this.
2081 The Radguard team said that their VPN gateway will not respond to a peer
2082 request with PFS (Perfect Forward Secrecy) on, but it *will* successfully
2083 establish such a connection with Linux FreeS/WAN when Radguard is the
2084 initiator. Since PFS is a desirable feature in terms of cryptographic
2085 security, this asymmetry may frustrate efforts to provide a connection that
2086 is both as reliable as secure as possible.
2088 While it's not clear that rekeying will present a problem, I suspect that
2089 some fine tuning of the key life parameters may be needed. Unfortunately
2090 I was unable to do additional tests on this topic.
2092 Due to the PFS issue, when trying to maintain a connection with PFS,
2093 you may need to set the rekeying times shorter on the radguard side,
2094 in order to ensure that it is always the initiator.</pre>
2096 <h3><a name="IBM.s390">IBM System 390</a></h3>
2098 <p>IBM offer IPsec for their big mainframes. See this <a
2099 href="http://www-1.ibm.com/servers/eserver/zseries/networking/pdf/GM13-0029-00.pdf">PDF
2102 <p>We do not know of any tests of this with FreeS/WAN. If you do any, please
2105 <h3><a name="IBM.as400">IBM AS 400</a></h3>
2107 <p>From the mailing list:</p>
2108 <pre>Subject: [Users] AS/400 <-> FreeS/WAN connection
2109 Date: Mon, 24 Sep 2001 10:28:54 -0600
2110 From: "Brandon Peterson" <bsp@MCINTOSHSOFTWARE.COM>
2114 FYI, I got a connection working between my Linux box & AS/400. I had to make
2115 two adjustments to the code...
2117 1) Ignore the commit flag. (There were some patches floating on the list
2120 2) Make FreeS/WAN start with proposal # 1
2121 To do this, I modified connections.c and inserted after line 1006...
2122 /* Hack to make AS/400 happy */
2123 if (c->policy == 0) c->policy = 1;</pre>
2125 <p>Since that was written, FreeS/WAN has been changed to ignore the commit
2126 bit, so that adjustment should no longer be necessary.</p>
2128 <h3><a name="winclient">Windows or Mac clients</a></h3>
2130 <p>If you have Windows 2000 or XP, then you should be able to use the IPsec
2131 built into those systems. As far as we know, for all other Windows versions,,
2132 you will need a client program.</p>
2134 <p>I am a little confused about IPsec for Mac OS X. Before the release, there
2135 were reports it would include IPsec, but more recent information seems to
2136 indicate that it doesn't. If anyone knows more, please post to our <a
2137 href="mail.html">users mailing list</a>. For other Mac OSs, and perhaps for
2138 OS X, you will need a client program.</p>
2140 <p>Quite a number of client programs for IPsec on Windows are available. Some
2141 of the same vendors have Macintosh versions.</p>
2143 <p>Some of the <a href="#otherpub">user-written HowTos</a> have details of
2144 configuration for particular clients.</p>
2146 <p>Most of the relevant vendors are listed in this piece of list mail:</p>
2147 <pre> Subject: Re: Searching Windows95/98 and NT4.0 Clients for FreeS/WAN
2148 From: Claudia Schmeing <claudia@coldstream.ca>
2149 Date: Wed, 12 Jul 2000
2153 for Win 95, 98 and NT 4.0
2154 http://www.datafellows.com/products/vpnplus
2157 Checkpoint SecureRemote VPN-1 4.1
2158 ---------------------------------
2159 for Win 95, 98 and NT
2160 http://www.checkpoint.com/techsupport/freedownloads.html
2163 Raptor Firewall, Raptor MobileNT 5.0
2164 -------------------------------------
2165 Mobile NT is a "Client"* for Win 95, 98 (except SE), & First Edition Windows NT
2166 up to Service Pack 4. It ships with DES; triple DES may be available as an
2167 add-on depending on your location.
2169 Firewall is for Win NT 4.0 or Win 2000.
2170 http://www.axent.com
2175 a "Client" for Win 95, 98 and NT 4.0 *
2179 Xedia's AccessPoint QVPN "Client" or "Builder"
2180 ----------------------------------------------
2182 "Client" is for Win 98 *
2183 http://www.xedia.com
2185 * "Client" in this context indicates software that does not support a subnet
2186 behind its end of the connection.</pre>
2188 <p>That mail omits the <a href="#pgpnet">PGPnet client</a> because the user
2189 asking the question already knew of it. The <a href="#sentinel">SSH
2190 Sentinel</a> client, released since the above message, is another
2191 possibility. Both of those have members of the vendor's staff active on our
2192 mailing list, an excellent sign for both interoperability and support.</p>
2194 <p>We also know of some other Windows IPsec clients:</p>
2196 <li><a href="http://www.lucent.com/ins/products/ipsec/">Lucent</a></li>
2197 <li><a href="http://www.ashleylaurent.com/">Ashleylaurent</a></li>
2200 <p>No doubt there are others we don't know of.</p>
2202 <h3><a name="NTdomain">NT domains vs. tunnels</a></h3>
2204 <p>There has been some mailing list discussion of making NT domains work
2205 across FreeS/WAN tunnels.</p>
2207 <p>Robert Cotran asked:</p>
2208 <pre>> I have a VPN setup between two subnets (192.168.1.x and 192.168.2.x). I
2209 > would like to be able to join the NT domain on 192.168.1.x from the
2210 > 192.168.2.x subnet. Is this possible? Do I have to forward specific ports
2211 > to do this? I've already set up WINS entries for all the machines, so
2212 > accessing computers by their NetBIOS names works perfectly. Please let me
2213 > know about this domain thing. Thanks!</pre>
2214 Dilan Arumainathan answered:
2215 <pre>All you need to do is to:
2217 1. Enable NetBIOS over TCP.
2218 2. Create a "lmhosts" file and enter the address of a BDC or a PDC like
2219 192.168.1.[x] [Your PDC/BDC servername] #PRE #DOM:[Your Domain Name]
2220 eg. 192.168.1.1 MYOWNPDC #PRE #DOM:DENSI-NT
2222 3. Reboot if necessary.</pre>
2223 and Sebastien Pfieffer provided a slightly different answer:
2224 <pre>For a trust relationship to work between NT domains in different
2225 (sub)nets all domain controllers of the 1st domain have to know about
2226 all controllers of the other domain.
2227 Either you use the described LMHOSTS entry for every domain controller
2228 of both domains or consider setting up WINS service(s).</pre>
2229 We suspect that in some cases it may be more complex than that. See the
2230 discussion of <a href="#lin2k">Linux services and Windows 2000</a> below and
2231 the <a href="#otherpub">Interop HowTo</a> documents listed above.
2233 <h3><a name="win2k">Windows 2000</a></h3>
2235 <p>Windows 2000 ships with an IPsec implementation built in.</p>
2237 <p>There are restrictions. We have had mailing list reports that only the
2238 server version will act as a gateway, working with a subnet behind it, and
2239 other versions offer only "client" functionality, with no subnet. We have
2240 some <a href="#client.server">comment</a> on this "client/server" distinction
2241 in an earlier section.</p>
2243 <p>Some versions of Windows 2000 ship with only weak encryption. You need to
2244 upgrade them with the strong encryption pack, available either via the
2245 Windows 2000 update service or from <a
2246 href="http://www.microsoft.com/windows2000/downloads/recommended/encryption/default.asp">Microsoft's
2249 <p>Windows 2000 IPsec sometimes exhibits remarkably odd behaviour. It will
2250 allow you to configure it for 3DES only, then ignore your settings and fall
2251 back to single DES in some circumstances. Microsoft have said they will fix
2253 href="http://www.wired.com/news/technology/0,1282,36336,00.html">Wired
2256 <h4><a name="lin2k">Other Linux services related to Win 2000</a></h4>
2258 <p>Windows 2000 also uses a number of other security mechanisms which have
2259 Linux equivalents. To integrate well with Windows 2000, you may need to look
2260 at several open source projects other than FreeS/WAN:</p>
2262 <li>Windows 2000 builds L2TP tunnels over (some of?) its IPsec connections.
2263 There is some older code for a a Linux <a
2264 href="http://www.marko.net/l2tp/">L2TP Daemon</a> and a <a
2265 href="http://sourceforge.net/projects/l2tpd">Sourceforge project</a>.</li>
2266 <li>Kerberos authentication is used in Windows 2000.
2268 <li><a href="http://web.mit.edu/network/kerberos-form.html">MIT
2269 Kerberos site</a></li>
2271 href="http://www.isi.edu/~brian/security/kerberos.html">"'Moron's
2273 <li>Kerberos <a href="http://alycia.dementia.org/kerberos.html">links
2276 <p>The Windows 2000 Kerberos implementation includes proprietary
2277 modifications. This is a security worry since it is by no means clear
2278 that the modified version remains secure. It also creates interoperation
2279 problems. Microsoft have released documentation on their modifications,
2280 but only under a license that hampers attempts either to audit their code
2281 for security flaws or to build other implementations that interoperate
2284 <li><a href="http://www.samba.org/">Samba</a> is a Linux implementation of
2285 the Windows SMB protocol, allowing disk sharing and other network
2287 <li><a href="http://tipxd.sourceforge.net/">tipxd</a>, the Tunelling IPX
2288 Daemon, encapsulates IPX for transport over IP.</li>
2291 <p>Here is a mailing list message, from FreeS/WAN team tech support person
2292 Claudia Schmeing, discussing Windows 2000 and L2TP:</p>
2295 > I want some information about IPsec with L2TP.
2296 > I'm going to build the IPsec tunnel on the L2TP tunnel.
2298 > Is there any case like this already implemented?
2300 It's used, but rarely. In many cases, IPSec alone is sufficient.
2302 In this thread, Timo Teras reports that he configured the L2TP/IPSec
2303 hybrid with Win2k. He gives some pointers.
2304 http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00545.html
2306 See also John P. Eisenmenger's report on his own experiences at:
2307 http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00195.html</pre>
2309 <h4><a name="interop.win2k">FreeS/WAN-to-Win2000 interop</a></h4>
2311 <p>As for IPsec interoperation between Windows 2000 and FreeS/WAN, there are
2312 several web sites listed under <a href="#otherpub">Interop HowTo</a>
2313 documents above.</p>
2316 href="http://support.microsoft.com/support/kb/articles/Q257/2/25.ASP">Microsoft
2317 page</a> on Windows 2000 IPsec troubleshooting may also be helpful.</p>
2319 <p>One user has written a tool to simplify the setup. Here is his description
2320 from the mailing list:</p>
2321 <pre>Subject: [Users] Win2K
2322 Date: Tue, 2 Oct 2001
2323 From: Marcus Müller <marcus@ebootis.de>
2325 I've written a small Tool for freeswan-win2k Interaction.
2326 Using this tool you can use a roadwarrior running Win2K
2327 to connect to Freeswan 1.91 with X509 patch.
2329 The tool has the following features:
2331 - FreeSwan like Configuration File
2332 - It sets up the complete Win2k configuration
2333 - It reads dynamic RAS/DHCP adresses and updates the IPSec Config
2335 You only need the following items:
2337 2. Win2k Service Pack 2 (for high encryption)
2338 3. Microsoft ipsecpol tool (included in the resource kit / Downloadable
2340 4. FreeSwan with working X.509 Patch and X.509 Certificates for your
2342 5. FreeSwan like Config-File
2343 6. The small "ipsec.exe" Tool
2345 I have tested it on several Client PCs in different environment
2347 I am planning to offer it as Open Source. Right now I don't know the
2348 right way of distributing my work. Because of the widespread interest,
2349 I would like to place it on the FreeSwan homepage.
2351 Rightnow anyone interested should mail me for a Copy, so I get some
2354 Thank you for the great FreeSwan System !!!</pre>
2356 <p>This tool is now available from the author's <a
2357 href="http://vpn.ebootis.de/">web page</a>.</p>