freeswan/doc/src/interop.html

   1 <html>
   2 <head>
   3   <meta http-equiv="Content-Type" content="text/html">
   4   <title>FreeS/WAN interoperation</title>
   5   <meta name="keywords"
   6   content="Linux, IPsec, VPN, security, FreeSWAN, interoperation">
   7   <!--
   8
   9   Written by Sandy Harris for the Linux FreeS/WAN project
  10   Freely distributable under the GNU General Public License
  11
  12   More information at www.freeswan.org
  13   Feedback to users@lists.freeswan.org
  14
  15   CVS information:
  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 $
  19
  20   CVS revision numbers do not correspond to FreeS/WAN release numbers.
  21   -->
  22 </head>
  23
  24 <body>
  25 <h1 name="interop">Interoperation with other IPsec implementations</h1>
  26
  27 <p>The IPsec protocols are designed to allow interoperation between different
  28 implementations. Other sections of this documentation have more detail on:</p>
  29 <ul>
  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>
  34 </ul>
  35
  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>
  38
  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>
  47
  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
  53 release.</p>
  54
  55 <p>There is additional information on interoperability testing in our <a
  56 href="web.html#interop.web">web links</a> section.</p>
  57
  58 <h2><a name="interop.problem">Interoperability problems</a></h2>
  59
  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>
  65
  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>
  70
  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
  74 problems.</p>
  75
  76 <h3><a name="req.features">Possible problem areas</a></h3>
  77
  78 <p>Known areas where problems may appear are:</p>
  79 <ul>
  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
  91     that way will fail.
  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>
  96   </li>
  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
 109     secure.</p>
 110   </li>
 111   <li>The IKE protocol allows several types of optional message. Two things
 112     happen which are allowed by the RFCs:
 113     <ul>
 114       <li>Some implementations send various optional messages.</li>
 115       <li>FreeS/WAN ignores them.</li>
 116     </ul>
 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>
 127 </ul>
 128
 129 <p>The general rule is that to interoperate with FreeS/WAN, the other
 130 implementation should be configured for:</p>
 131 <ul>
 132   <li>main mode</li>
 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>
 136 </ul>
 137
 138 <p>This is possible for most implementations.</p>
 139
 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>
 143
 144 <h3>Documentation and terminology problems</h3>
 145
 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>
 150
 151 <p>Known examples are:</p>
 152 <ul>
 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
 156   key".</li>
 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>
 161 </ul>
 162
 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>
 166
 167 <h3><a name="one-way">If it only works in one direction</a></h3>
 168
 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>
 171
 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>
 175
 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>
 179
 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
 186 different software.
 187
 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
 190 software.</p>
 191
 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
 196 version".</p>
 197
 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>
 202
 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>
 208
 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>
 213
 214 <h3><a name="noDES">Systems that want to use single DES</a></h3>
 215
 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>
 220
 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
 227 discussion.</p>
 228
 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>
 234 <ul>
 235   <li>your government, especially any department concerned with protecting
 236     citizens' privacy or your nation's communication infrastructure</li>
 237   <li>the vendor</li>
 238   <li>the embassy of the nation whose laws are problematic for you</li>
 239 </ul>
 240
 241 <p>Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES
 242 now.</p>
 243
 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>
 249
 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
 252 encryption</a>.</p>
 253
 254 <h2><a name="patch.interop">Patches to extend interoperability</a></h2>
 255
 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
 258 patches</a>.</p>
 259
 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>
 268
 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
 272 issue.</p>
 273
 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>
 280
 281 <h2><a name="otherpub">Interop HowTo documents</a></h2>
 282
 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>
 287 <ul>
 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:
 291     <ul>
 292       <li>FreeS/WAN</li>
 293       <li>Open BSD IPsec</li>
 294       <li>Windows 98 with PGPnet</li>
 295     </ul>
 296   </li>
 297   <li>Jean-Francois Nadeau's <a href="http://jixen.tripod.com/">practical
 298     configurations</a> document covers FreeS/WAN interoperation with
 299     <ul>
 300       <li>Windows 2000 IPsec</li>
 301       <li>NAI PGPnet</li>
 302       <li>IRE Safenet SoftPK.</li>
 303     </ul>
 304   </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
 308     FreeS/WAN and:
 309     <ul>
 310       <li>Windows 2000</li>
 311       <li>PGPnet</li>
 312     </ul>
 313   </li>
 314   <li><a
 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:
 317     <ul>
 318       <li>Windows 2000</li>
 319       <li>PGPnet</li>
 320       <li>SSH Sentinel</li>
 321     </ul>
 322   </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
 328     2000</a></li>
 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&amp;page=ipsec-x509">FreeS/WAN
 339     with X.509 patch and Windows 2000</a></li>
 340 </ul>
 341
 342 <p>See also our lists of:</p>
 343 <ul>
 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>
 347 </ul>
 348
 349 <h3><a name="ipsec.2001"></a>Interop info from the IPsec 2001 conference</h3>
 350
 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 &lt;Ghislaine.Labouret@hsc.fr&gt;
 355 Organization: HSC (Herve Schauer Consultants)
 356
 357 During the IPsec 2001 conference held in Paris last month, an
 358 interoperability demonstration including FreeS/WAN was set up.
 359
 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.
 363
 364 The results and configuration files are now available online:
 365 http://www.hsc.fr/ipsec/ipsec2001/</pre>
 366
 367 <h2><a name="mail.interop">Interoperation with specific products</a></h2>
 368
 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>
 372
 373 <p>A large thank you is in order to all the list contributors. This document
 374 would not exist without you.</p>
 375
 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>
 381
 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.
 386
 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>
 390
 391 <h4><a name="config.old">Using your old config files</a></h4>
 392
 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>
 397
 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>
 406
 407 <h3><a name="OpenBSD">OpenBSD</a></h3>
 408
 409 <p>Two user-written HowTos we know of cover interoperation between FreeS/WAN
 410 and Open BSD IPsec:</p>
 411 <ul>
 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>
 415 </ul>
 416
 417 <p>The <a href="http://www.openbsd.org/faq/faq13.html">OpenBSD FAQ</a>
 418 includes information on their IPsec implementation.</p>
 419
 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 &lt;niklas@appli.se&gt;
 425
 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
 428 the IKE level.</pre>
 429
 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
 435
 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.
 438 |
 439 | Is this documented behaviour for either FreeS/WAN or isakmpd?  (Anyway
 440 | a reasonable error message would not hurt.)
 441
 442 The limit is not in FreeS/WAN, so we don't document it :-)
 443
 444 I guess we could mention this on our interop pages.  Claudia?
 445
 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).
 448
 449 - isamkpd documentation should state the limit
 450
 451 - isakmpd should diagnose that the PSK was too long
 452
 453 - isakmpd should suggest that this type of problem (undigestable
 454   message) might be caused by mis-matched PSK
 455
 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.
 459
 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
 462 with
 463         probable authentication (preshared secret) failure:
 464
 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>
 468
 469 <h3><a name="FreeBSD">FreeBSD</a></h3>
 470
 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>
 473
 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 &lt;Ghislaine.Labouret@hsc.fr&gt;
 478
 479 On Thu, 28 Dec 2000 13:53:01 -0500, Sandy Harris wrote:
 480
 481 &gt; FreeBSD:
 482 &gt;
 483 &gt; For FreeBSD, I find list discussion of 3DES key formats, presumably for manual
 484 &gt; keying. We have 192-bit, 3 64-bit keys including parity bits, while FreeBSD 4.0
 485 &gt; used 168-bit, 3 56-bit keys without the parity bits. Has FreeBSD changed this?
 486
 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
 490 keying.
 491
 492 &gt; For auto keying, I find reports of sucessful use of pre-shared secrets, but
 493 &gt; nothing on RSA authentication.
 494
 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.
 502
 503 &gt; Does FreeBSD support that?
 504
 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.
 508
 509 &gt; Are the key formats compatible, or has anyone written translation code?
 510
 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>
 514
 515 <h3><a name="NetBSD">NetBSD</a></h3>
 516
 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>
 520
 521 <h3><a name="Cisco">Cisco Routers</a></h3>
 522
 523 <h4><a name="cisco.info">Information from Cisco</a></h4>
 524
 525 <p>Useful pages on Cisco sites include:</p>
 526 <ul>
 527   <li><a
 528     href="http://www.cisco.com/warp/public/471/top_issues/vpn/vpn_index.shtml">VPN
 529     support</a></li>
 530   <li><a
 531     href="http://www.ieng.com/warp/public/707/index.shtml#ipsec">IPsec</a></li>
 532 </ul>
 533
 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
 538 |
 539 | ...
 540 |
 541 | This feature is supported only on the following platforms:
 542 |
 543 |     1720
 544 |     2600 Series
 545 |     3600 Series
 546 |     4000 Series
 547 |     4500 Series
 548 |     AS5300 Series
 549 |     7200 Series
 550 |     7500 Series</pre>
 551
 552 <h4><a name="cisco.list">From our mailing list</a></h4>
 553
 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
 559 them here.</p>
 560
 561 <p>Several other pages have possibly useful information:</p>
 562 <ul>
 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>
 565   <li>mailing list <a
 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>
 573   <li>a short <a
 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>
 576 </ul>
 577
 578 <h4><a name="cisco.psk">Shared secrets work</a></h4>
 579
 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
 585
 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.
 590
 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.
 593
 594 Here is the network...
 595
 596           host 172.11.251.34
 597              |
 598            -------------------  172.11.251.0/24
 599                    |
 600                 linux router
 601                    |
 602            -------------------  172.11.252.0/24
 603                    |
 604                    |    172.11.252.2
 605               freeswan linux
 606                    |    xxx.xxx.xxx.85
 607                    |
 608                    |    xxx.xxx.xxx.1
 609                 router
 610                    |
 611                 INTERNET
 612                    |.
 613                 router
 614                    |    yyy.yyy.yyy.1
 615                    |
 616                    |    yyy.yyy.yyy.21
 617                cisco router
 618                    |    10.25.5.1
 619                    |
 620            -------------------   10.25.5.0
 621              |
 622            host 10.25.5.44
 623
 624
 625 My ipsec.conf looks like this...
 626
 627 config setup
 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.
 632         klipsdebug=all
 633         plutodebug=none
 634         plutoload=%search
 635         plutostart=%search
 636         # Close down old connection when new one using same ID shows up.
 637         uniqueids=yes
 638
 639 # defaults for subsequent connection descriptions
 640 conn %default
 641         # How persistent to be in (re)keying negotiations (0 means very).
 642         keyingtries=0
 643
 644 conn cisco1
 645         left=xxx.xxx.xxx.85
 646         leftnexthop=xxx.xxx.xxx.1
 647         leftsubnet=172.11.251.0/24
 648         right=yyy.yyy.yyy.21
 649         rightnexthop=yyy.yyy.yyy.1
 650         rightsubnet=10.25.5.0/24
 651         lifetime=8h
 652         auto=start
 653
 654 My cisco configuration looks like this...
 655
 656
 657 crypto map VPN 30 ipsec-isakmp
 658  set peer xxx.xxx.xxx.85
 659  set transform-set 3des-md5
 660  match address 130
 661
 662 crypto ipsec transform-set 3des-md5 esp-3des esp-md5-hmac
 663
 664 crypto isakmp key ******** address xxx.xxx.xxx.85
 665
 666
 667 crypto isakmp policy 3
 668  encr 3des
 669  hash md5
 670  authentication pre-share
 671  group 2
 672
 673 access-list 130 permit ip 10.25.5.0 0.0.0.255 172.11.251.0 0.0.0.255
 674
 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.
 678
 679 I hope this helps someone....</pre>
 680 Another similar post:
 681 <pre>Subject: [Users] freeswan &lt;--$gt; Cisco: success!
 682    Date: Thu, 20 Sep 2001
 683    From: "Wolfgang Tremmel" &lt;w.tremmel@vianetworks.de&gt;
 684
 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.
 688
 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
 692
 693                 Router is a Cisco 4700, running IOS 12.2(2)T1 with 3DES
 694
 695 ipsec.conf:
 696 config setup
 697         interfaces="ipsec0=ppp0"
 698         klipsdebug=none
 699         plutodebug=none
 700         plutoload=%search
 701         plutostart=%search
 702         uniqueids=yes
 703
 704 conn %default
 705         keyingtries=0
 706         disablearrivalcheck=no
 707
 708 conn cisco
 709         type=tunnel
 710         left=%defaultroute
 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
 715         keyexchange=ike
 716         authby=secret
 717         lifetime=8h
 718         pfs=yes
 719
 720 ipsec.secret:
 721 %any x.x.x.x: PSK "thisisatestkey"
 722
 723 - ---- thats all on the linux router
 724 - ---- now for the Cisco:
 725
 726 crypto isakmp policy 100
 727  encr 3des
 728  authentication pre-share
 729  group 2
 730  lifetime 3600
 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
 733
 734 crypto ipsec transform-set linuxbox esp-3des esp-sha-hmac
 735
 736 crypto dynamic-map linuxbox 100
 737  set transform-set linuxbox
 738  match address linuxbox
 739
 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
 744
 745 interface FastEthernet0
 746  ip address x.x.x.x 255.255.255.192
 747  full-duplex
 748  crypto map linuxbox
 749
 750 ip access-list extended wtremmel
 751  permit ip host x.x.x.x my.net.work.athome mask
 752
 753
 754 Wolfgang</pre>
 755
 756 <h4><a name="cisco.rsa">RSA keys are tricky</a></h4>
 757
 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
 762
 763 We use Cisco IOS 12.1.5(T) and freeswan 1.8
 764
 765 Here an example on how I copied the key from cisco:
 766
 767 Key Data:
 768   117C311E 16192D86 8886C71D 11111115 11138B11 31881241 11C7E23B D6DB22
 769   18DEC1BD....
 770
 771 Will become
 772
 773 0x117C311E16192D868886C71D1111111511138B113188124111C7E23BD6DB2218DEC1BD...
 774
 775 We used at least 1024 bits long keys.
 776
 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.
 780
 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.
 785
 786 Deyvi
 787 &gt;&gt;(off list)
 788 &gt;
 789 &gt;Yes, I was just going to mention that the Cisco's key should be in
 790 &gt;ipsec.conf (just received your correction).
 791 &gt;
 792 &gt;I think that I have the Cisco side configured correctly ( I can't be sure
 793 &gt;because I can't test against the Freeswan).
 794 &gt;
 795 &gt;Starting from having the IPsec tunnel working with pre-share, I did the
 796 &gt;following on the Cisco side:
 797 &gt;
 798 &gt;#config t
 799 &gt;(config)# crypto key pubkey-chain rsa
 800 &gt;(config-pubkey-chain)# addressed-key <ipaddress of freeswan>
 801 &gt;(config-pubkey-key)# key-string
 802 &gt;(config-pubkey-key)# <paste freeswan key here>
 803 &gt;(config-pubkey-key)#quit
 804 &gt;(config-pubkey-chain)#exit
 805 &gt;
 806 &gt;# config t
 807 &gt;(config)# crypto isakmp policy 1
 808 &gt;(config-isakmp)# no authentication pre-share
 809 &gt;(config-isakmp)# authentication rsa-sig
 810 &gt;(config-isakmp)# exit
 811 &gt;
 812 &gt;How long is your RSA key that was generated on the Cisco? I tried copying
 813 &gt;the key out of the 3640 and pasting it into ipsec.conf, removing the spaces
 814 &gt;and adding a '0x' in the front. I get the 'key too small' error still. What
 815 &gt;version of freeswan are you using?
 816 &gt;
 817 &gt;I'm using Freeswan 1.9 w/ IOS 12.1(6).</pre>
 818
 819 <h4><a name="cisco.conc">Cisco VPN Concentrator</a></h4>
 820
 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" &lt;msticki@web.de&gt;
 826
 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.
 830
 831 it is no a problem to estblish the tunnel between two freeswan
 832 gateways or between a cisco vpn-client and the concentrator.
 833
 834 but the companies don't want to change their equipment.
 835 and with this constellation i can't establish the tunnel.
 836
 837 the responce from cisco is: "THAT IS NOT SUPPORTED"
 838
 839 so this mailing list is my last chance, because i don't know how to go on</pre>
 840
 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 &lt;Ghislaine.Labouret@hsc.fr&gt;
 845
 846 &gt; i have to establish a vpn tunnel between two companies.
 847 &gt; one of the company is using the cisco vpn concentrator
 848 &gt; and the other company is using redhat 7.1 and freeswan.
 849 [...]
 850 &gt; the responce from cisco is: "THAT IS NOT SUPPORTED"
 851
 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>
 855
 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 &lt;Ghislaine.Labouret@hsc.fr&gt;
 860 Organization: HSC (Herve Schauer Consultants)
 861
 862 Juri Jensen wrote:
 863
 864 &gt; I've been trying to get those two to interoperate with certificates, but
 865 &gt; I have only succeeded with PSK. Can you shed some light on how you did
 866 &gt; it....?
 867
 868 I will put the config files and different tests results from the demo on
 869 http://www.hsc.fr/ipsec/ipsec2001/ next week.
 870
 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>
 875
 876 <h3><a name="bay">Nortel (Bay Networks) Contivity switch</a></h3>
 877
 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>
 882 <ul>
 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>
 887 </ul>
 888
 889 <p>We recommend using a current software on both ends.</p>
 890
 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 &lt;msiebler@nortelnetworks.com&gt;
 895 Reply-To: msiebler@alum.mit.edu
 896 Organization: Nortel Networks
 897
 898 More interoperability results:
 899
 900 I successfully established a tunnel with a Nortel (formerly Bay (formerly New Oak)) Contivity
 901 Extranet Switch running the latest release versions.
 902
 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
 905
 906 I am using IKE with 3DES-HMAC-MD5
 907
 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>
 911
 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 &lt;bill.stewart@pobox.com&gt;
 916
 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
 921 clients.</pre>
 922
 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" &lt;jj@digisle.net&gt;
 927
 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.
 931
 932 Connecting FreeS/WAN to the Nortel Networks Contivity Extranet Switch:
 933
 934 What you need:
 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)
 937 or
 938 FreeS/WAN v1.8 and COntivity ver 3.5 (the 3.5 version supports Diffe
 939 Hilman group 2 key exchange)
 940
 941 What to do:
 942 1 - Configure the Contivity:
 943    Set up a branch office tunnel group with the following settings:
 944
 945         Connectivity:
 946         Nailed Up: Disabled
 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
 952         RSVP: Disabled
 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
 959
 960         Encryption:
 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
 966 2 (1024-bit prime)
 967         Vendor ID: Disabled
 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
 974
 975         Set up a branch office tunnel inside this new group with the
 976 following settings:
 977
 978         Endpoint Addresses
 979         Local - Public address of your COntivity
 980         Remote - Your Free-S/WAN interface Address
 981                 Tunnel Type - IPSEC
 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.
 985
 986         Under IP:
 987         Static Routing
 988         Local - networks you want to be able to access through the
 989 tunnel
 990         Remote - networks that will be allowed through the tunnel
 991         NAT - None
 992
 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.
 997
 998    Configure Free-S/WAN:
 999         Install, compile, and test Free-S/WAN
1000         Edit ipsec.conf for your new tunnel:
1001 --------------------------------------------------------
1002 ipsec.conf --
1003 config setup
1004         interfaces="ipsec0=eth1"
1005         forwardcontrol=no
1006         klipsdebug=none
1007         plutodebug=none
1008         manualstart=
1009         plutoload=%search
1010         plutostart=%search
1011         plutowait=no
1012 conn net1
1013         type=tunnel
1014         auto=start
1015         auth=esp
1016         authby=secret
1017         keyexchange=ike
1018         keylife=1h
1019         keyingtries=1
1020         pfs=yes
1021         left=10.0.0.2
1022         leftnexthop=10.0.0.1
1023         leftsubnet=10.0.1.0/24
1024         right=172.16.0.2
1025         rightsubnet=172.16.1.0/24
1026 conn net2
1027         type=tunnel
1028         auto=start
1029         auth=esp
1030         authby=secret
1031         keyexchange=ike
1032         keylife=1h
1033         keyingtries=1
1034         pfs=yes
1035         left=10.0.0.2
1036         leftnexthop=10.0.0.1
1037         leftsubnet=10.0.1.0/24
1038         right=172.16.0.2
1039         rightsubnet=172.16.2.0/24
1040
1041 ipsec.secrets --
1042 10.0.0.2 172.16.0.2 "Your big secret"
1043 ---------------------------------------------
1044
1045 The above config is for this imaginary network:
1046
1047          +------+
1048 10.0.1.1 |      |10.0.0.2   10.0.0.1++ Internet
1049 ---------|      |-------------------++===========
1050          +------+            Home Router
1051          Free-S/WAN host
1052
1053
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
1057
1058
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>
1062
1063 <h3><a name="Raptor">Raptor Firewall</a></h3>
1064
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 &lt;chuckb@chandler-group.com&gt;
1069
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. . . .
1074
1075 Subject: RE: Interoperability with Raptor 5 (Success!)
1076 Date: Thu, 28 Jan 1999 17:22:55 -0500
1077 From: Chuck Bushong &lt;chuckb@chandler-group.com&gt;
1078
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
1083 product.
1084
1085 Keep up the good work.</pre>
1086
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" &lt;cggrieb@biw.com&gt;
1090    Date: Tue, 25 Jul 2000
1091
1092 On Thu, Jul 20, 2000 at 12:04:40PM -0700, Kevin Traas wrote:
1093 &gt; Great!  I'm just about to start looking into this as well, so any
1094 &gt; docs/info you can provide would be *greatly* appreciated.  Immortalize
1095 &gt; yourself!  Get something written and added to the compatibility.html
1096 &gt; file.  Many will thank you.
1097
1098 Can't be that hard.  I'm just a freeswan newbie who hasn't even done a FS<->FS
1099 tunnel yet :)
1100
1101 Anyway, I hope you find this helpful.
1102
1103 Chock
1104
1105 -------------------------------------------------------------------------------
1106
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)
1109
1110 FreeS/WAN (right) information:
1111 -----------------------------
1112
1113 ipsec.conf
1114 ----------
1115 config setup
1116         interfaces="ipsec0=ppp0"    # change to suite
1117         klipsdebug=
1118         plutodebug=
1119         plutoload=sample
1120         plutostart=sample
1121
1122 conn sample
1123         left=10.0.0.1
1124         leftnexthop=10.0.0.2
1125         leftsubnet=192.168.0.0/24
1126         right=10.1.1.1
1127         rightnexthop=10.1.1.1
1128         rightsubnet=172.16.1.0/24
1129         auto=add
1130         keyexchange=ike
1131         pfs=no
1132         lifetime=8h
1133         esp=3des-md5-96
1134
1135 ipsec.secrets
1136 -------------
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"
1139
1140 Raptor 6.02 (left) information:
1141 ------------------------------
1142 Key Profiles:
1143     Name: left-external-kp-dynamic
1144     Type: Dynamic
1145     Profile Describing: local entity
1146     Gateway: 10.1.1.1
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
1153
1154     Name: right-external-kp-dynamic
1155     Type: Dynamic
1156     Profile Describing: remote entity
1157     Gateway: 10.0.0.1
1158     Identification Type: Address
1159     Identification: 10.0.0.1
1160
1161 Secure Subnets:
1162     Name: left-ss-dynamic
1163     Address: 192.168.0.0
1164     Netmask: 255.255.255.0
1165     Key Profile: left-ss-dynamic
1166
1167     Name: right-ss-dynamic
1168     Address: 172.16.1.0
1169     Netmask: 255.255.255.0
1170     Key Profile: right-ss-dynamic
1171
1172 Secure Tunnel:
1173     Name: left-to-right-tunnel
1174     Entity A: right-ss-dynamic
1175     Entity B: left-ss-dynamic
1176     Encapsulation: ISAKMP
1177     Filter: [none]
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
1183
1184     [Advanced settings]
1185     Data volume timeout: 2100000
1186     Lifetime timeout: 480
1187     Inactivity timeout: 0
1188     Transport mode: [unchecked]
1189     Perfect forward secrecy: [unchecked]
1190     Proxy: [checked]
1191
1192 ----
1193 Notes:
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
1197  SPI's.</pre>
1198
1199 <h4><a name="raptorman">Raptor manual keying</a></h4>
1200
1201 <p>A mailing list suggestion from FreeS/WAN technical lead Henry Spencer:</p>
1202 <pre>&gt; In the Raptor settings, there are 2 sets of data (1 for each end). Each set
1203 &gt; contains an SPI, 3 DES Keys and 1 MD5 hash. I only know how to include one
1204 &gt; set, how do I include the other set? Is the other set needed?
1205
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>
1211
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
1215
1216 Sending the following to the list, at Hugh's request.
1217
1218 -----Original Message-----
1219 From: Reiner, Richard
1220 Sent: Tuesday, November 21, 2000 11:34 AM
1221 To: 'hugh@mimosa.com'
1222
1223 Hugh,
1224
1225 &gt; Good.  But we don't think that you should be using our IPCOMP just
1226 &gt; yet.  It is flaky :-(
1227
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*
1234 using ipcomp.
1235
1236 &gt; This is interesting and we'd love a more complete writeup.  It should
1237 &gt; get incorporated into our interop documentation.
1238
1239 Here are the relevant bits from ipsec.conf:
1240
1241 config setup
1242         interfaces=%defaultroute
1243         klipsdebug=none
1244         plutodebug=none
1245         plutoload=%search
1246         plutostart=%search
1247         uniqueids=yes
1248
1249 conn freeswan17-gauntlet55
1250         auto=start
1251         type=tunnel
1252         left=1.1.1.1
1253         leftnexthop=1.1.1.2
1254         leftsubnet=10.0.1.0/24
1255         right=3.3.3.3
1256         rightnexthop=3.3.3.4
1257         rightsubnet=10.0.2.0/24
1258         authby=secret
1259         keyexchange=ike
1260         ikelifetime=480m
1261         auth=esp
1262         esp=3des-md5-96
1263         keylife=480m
1264         keyingtries=8
1265         pfs=no
1266         rekeymargin=9m
1267         rekeyfuzz=25%
1268
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).
1272
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.
1276
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.
1283
1284 <h3><a name="checkpoint">Checkpoint Firewall-1</a></h3>
1285
1286 <p>A PDF <a
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>
1291
1292 <p>A <a href="http://www.phoneboy.com/">resource page</a> full of Firewall-1
1293 information.</p>
1294
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
1297 story.</p>
1298
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 &lt;claudia@freeswan.org&gt;
1303
1304 &gt; Thanx to Michael and Claudia, but this doesn't work from VPN1 to linux (as
1305 &gt; linux to VPN1 is OK).
1306 ...
1307
1308 &gt; I think that VPN1 doesn't send "192.168.1.0/24" but "192.168.1.20/32" and,
1309 &gt; as Claudia said, IPSEC SA need to match Exactly.
1310
1311 I don't know about the rules on the VPN-1. You'll have to rely on people
1312 with applicable experience there...
1313
1314 &gt; Is it possible that freeswan doesn't do the inclusion process (ie if he
1315 &gt; receive 192.168.1.20/32, i doesn't match that this is include in
1316 &gt; 192.168.1.0/24) ?
1317
1318 Yes, that's correct. It needs to match exactly, and inclusion is not
1319 part of this process.
1320
1321 &gt; Btw why VPN/1 send 192.168.1.20/32 and not 192.168.1.20/24 (the value that
1322 &gt; Freeswan is waiting for)? A bug?
1323
1324 I think Michael may be able to help you with this.
1325
1326 &gt; Have i a way to force Freeswan to do the "inclusion" (ie accept
1327 &gt; 192.168.1.20/32 as a part of 192.160.1.20/24, even if the 2 IPSEC Sa
1328 &gt; doesn't match exactly) ?
1329
1330 No, but...
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.
1335
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.
1343
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>
1347
1348 <h3><a name="redcreek">Redcreek Ravlin</a></h3>
1349
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>
1355
1356 <h3><a name="sentinel">SSH Sentinel</a></h3>
1357
1358 <p>The vendor's <a
1359 href="http://www.ssh.com/support/sentinel/documents.cfm">web site</a> has
1360 configuration examples for use with FreeS/WAN.</p>
1361
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 &lt;simon@paxonet.com&gt;
1366
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
1370
1371 Perhaps a link to it could be put on the web site.
1372
1373 There is also another document on FreeS/WAN &lt;&gt; SSH Sentinel interoperability: http://www.ssh.com/products/sentinel/SSH_Sentinel_Config_Examples.pdf Simon </pre>
1374
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 &lt;jt@ssh.com&gt;
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
1381
1382 Hello, FreeS/WAN community !
1383
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.
1388
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.
1395
1396 Thank you a lot for your feedback, colleagues !
1397
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
1401
1402 For more information about the product, please check our website
1403 http://www.ipsec.com
1404
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
1409
1410 Best regards,
1411 Jussi Torhonen, SSH Sentinel Team
1412 Kuopio, Finland</pre>
1413
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
1420
1421 Markus Weber wrote:
1422
1423 &gt; ... the installation
1424 &gt; of Sentinel don't let you set 3DES as the default!
1425 &gt; And when your want to add a connection the first
1426 &gt; diagnostic-test goes wrong ! :-( ...
1427
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.
1433
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.
1440
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>
1443
1444 <p>FreeS/WAN does not yet support <a href="glossary.html">AES</a>.</p>
1445
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 &lt;bellman@signum.se&gt;
1450
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>
1458
1459 <h3><a name="watchguard">Watchguard</a></h3>
1460
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
1467 message</a>.</p>
1468
1469 <p>Watchguard do not use FreeS/WAN in their product. They have their own
1470 IPsec implementation.</p>
1471
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
1475 explains this.</p>
1476
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 &lt;menders@watchguard.com&gt;
1481
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
1485 my test:
1486
1487 RedHat Linux 6.2
1488 Linux 2.2.18 i686 unknown
1489 Linux FreeS/WAN 1.8
1490 "Trusted" interface: 192.168.0.1/24
1491 "External" interface: 192.168.1.1/24
1492
1493 Firebox II FastVPN
1494 WatchGuard Live Security System v4.5
1495 Trusted interface: 192.168.2.1/24
1496 External interface: 192.168.1.2/24
1497
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:
1502
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
1510 would.
1511
1512 Here's how I configured FreeS/WAN:
1513
1514 Modifications to /etc/ipsec.conf:
1515
1516 Under the "config setup" section, add:
1517
1518 manualstart=firebox
1519
1520 At the end of the file, add the following connection:
1521
1522 conn firebox
1523 left=192.168.1.1
1524 leftsubnet=192.168.0.0/24
1525 right=192.168.1.2
1526 rightsubnet=192.168.2.0/24
1527 spi=0x101
1528 esp=3des-md5-96
1529 espenckey=0x515b0875793e3708517c3d4554012f7c0273375e51572a31
1530 espauthkey=0x072649041c2c0d452f7c15407576522f
1531
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>
1536 A user comments:
1537 <pre>Subject: RE: Freeswan
1538    Date: Wed, 7 Feb 2001
1539    From: "Patrick Poncet" &lt;pponcet@vaxxine.com&gt;
1540
1541 It's working!!!
1542
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!...
1547
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.
1552
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>
1555
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 &lt;pkoning@xedia.com&gt;
1560
1561 Here's another datapoint for the "FreeS/WAN interoperability
1562 database".
1563
1564 I tested 0.92 against the Xedia Access Point/QVPN product, using
1565 dynamic keying (i.e., Pluto at work).
1566
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.
1569
1570 I did limited data testing, which seemed to be fine.  No performance
1571 numbers yet, could do that if people are interested.
1572
1573 Any questions, please ask.
1574
1575         paul</pre>
1576
1577 <h3><a name="pgpnet">PGP Mac and Windows IPsec client (PGPnet)</a></h3>
1578
1579 <h3>McAfee VPN Client</h3>
1580
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>
1584
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
1588 Client</p>
1589
1590 <p>Here is the first message about PGPnet to our mailing list, from a senior
1591 PGP employee:</p>
1592 <pre>   Subject: PGPnet interoperable with FreeSWAN
1593    Date: Mon, 05 Apr 1999 18:06:13 -0700
1594    From: Will Price &lt;wprice@cyphers.net&gt;
1595
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!
1601 [snip]
1602 - --
1603 Will Price, Architect/Sr. Mgr., PGP Client Products
1604 Total Network Security Division
1605 Network Associates, Inc.</pre>
1606
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>
1609
1610 <p>Several of the user-written HowTos mentioned <a href="#otherpub">above</a>
1611 cover interoperation between PGPnet and FreeS/WAN.</p>
1612
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>
1616
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
1621 details.</p>
1622
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" &lt;hugh@mimosa.com&gt;
1627
1628 | From: Yan Seiner
1629 |
1630 | OK, I'm stumped.  I am trying to configure IPSEC to support road
1631 | warriors using PGPnet 6.5.
1632 |
1633 | I've set up everything as per the man pages on the ipsec side.
1634 |
1635 | I've set up everything on the PGPnet side per the docs for that package.
1636 |
1637 | Pluto fails with this:
1638 |
1639 | Jan 16 08:14:11 aphrodite Pluto[26401]: "homeusers" #8: no acceptable
1640 | Oakley Transform
1641 |
1642 | and then it terminates the connection.
1643
1644 As far as I can tell/remember, there are three common ways that PGPnet
1645 and FreeS/WAN don't get along.
1646
1647 1. PGPnet proposes a longer lifetime for an SA than Pluto is willing
1648    to accept.
1649
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
1653
1654 3. FreeS/WAN defaults to expecting Perfect Forward Secrecy and PGPnet
1655    does not.
1656
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>
1659
1660 <p>Some advice from the mailing list:</p>
1661 <pre>   Subject: Re: Secure Gate Fails- PGPNet &amp; FreeSwan
1662    Date: Wed, 28 Jun 2000
1663    From: Andreas Haumer &lt;andreas@xss.co.at&gt;
1664
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!
1669
1670 As I tried _several_ different non-working configuration settings
1671 I think I know the exact _one_ which works... :-)
1672
1673 Here's my short "HOWTO":
1674
1675 FreeS/WAN version: snap1000jun25b
1676 PGPnet: PGP Personal Privacy, Version 6.5.3
1677 Linux: 2.2.16 with some patches
1678
1679 Network setup:
1680 =============
1681
1682 internal subnet [192.168.x.0/24]
1683 |
1684 |        [192.168.x.1]
1685 secure gateway with FreeS/WAN
1686 |        [a.b.c.x]
1687 |
1688 |        [a.b.c.y]
1689 router to internet
1690 |
1691 |   Internet
1692 |
1693 |        [dynamically assigned IP address]
1694 road-warrior with PGPnet
1695
1696
1697 Configuration of FreeS/WAN:
1698 ==========================
1699
1700 a) /etc/ipsec.conf
1701
1702 config setup
1703         interfaces=%defaultroute
1704         klipsdebug=none
1705         plutodebug=none
1706         plutoload=%search
1707         plutostart=%search
1708
1709 conn %default
1710         keyingtries=1
1711         authby=secret
1712         left=a.b.c.x
1713         leftnexthop=a.b.c.y
1714
1715 conn gw-rw
1716         right=0.0.0.0
1717         auto=add
1718
1719 conn subnet-rw
1720         leftsubnet=192.168.x.0/24
1721         right=0.0.0.0
1722         auto=add
1723
1724
1725 b) /etc/ipsec.secrets
1726
1727 a.b.c.x 0.0.0.0: "my very secret secret"
1728
1729
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!
1734
1735 Check your logfiles if the firewall is blocking some
1736 important packets!
1737
1738
1739 Configuration of PGPnet:
1740 =======================
1741
1742 (note that there is an excellent description, including
1743 screenshots of PGPnet, on &lt;http://jixen.tripod.com/&gt;)
1744
1745 In short, do the following:
1746
1747 Launch the PGPnet configuration tool and set defaults options
1748 =============================================================
1749
1750 Start - Program - PGP - PGPnet
1751 View - Options
1752 General Panel :
1753   Expert Mode
1754   Allow communications with unconfigured hosts
1755   Require valid authentication key
1756   Cache passphrases between logins
1757   IKE Duration : 6h
1758   IPsec : 6h
1759 Advanced panel :
1760   Selected options :
1761     Ciphers : Tripple DES
1762     Hashes : MD5
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
1770 Press OK
1771
1772
1773 Create the connection's definition.
1774 ==================================
1775
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
1784 Press Ok
1785   Select the newly created entry for the right gateway and click ADD,
1786 YES
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)
1791 Press OK, YES, YES
1792
1793
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
1797 with PGPnet.</pre>
1798
1799 <p>and a note from the team's tech support person:</p>
1800 <pre>Date: Thu, 29 Jun 2000
1801 From: Claudia Schmeing
1802
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:
1805
1806 &gt;2. After rekeying (i.e. after building a new SA bundle because the old
1807 &gt;   one is about to expire), FreeS/WAN immediately switches to the new
1808 &gt;   one while PGPnet continues using the old
1809
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>
1815
1816 <h3><a name="IRE">IRE Safenet/SoftPK</a></h3>
1817
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>
1822
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>
1826
1827 <h4><a name="softPK">SoftPK</a></h4>
1828
1829 <p>Several documents are available:</p>
1830 <ul>
1831   <li><a
1832     href="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">PDF
1833     HowTo</a> titled <cite>FreeS/WAN 1.8 &lt;--&gt; IRE Safenet SoftPK 5.1.0
1834     Road-Warrior VPN Configuration Guide</cite> from Terradon
1835   Communications.</li>
1836   <li><a
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>
1841 </ul>
1842
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 &lt;cerebus+counterpane@haybaler.sackheads.org&gt;
1847
1848 Randy Dees writes:
1849
1850  &gt; Anyone know of a low-cost MS-Win client that interoperates and does not
1851  &gt; require purchasing a server license to get it?
1852
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>
1858
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" &lt;timwilson@mediaone.net&gt;
1863
1864 Here are some details about using the IRE SafeNet Soft/PK client with a
1865 FreeSwan gateway.
1866
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.
1871
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
1876 succinct names.
1877
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.
1883
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).
1890
1891 Soft/PK allows you to configure practically everything for the connection.
1892 Here are the main points to watch for:
1893
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.
1900
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.
1904
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.
1908
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.
1913
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.
1916
1917 Hope this helps.</pre>
1918
1919 <h4><a name="softremote">SoftRemote</a></h4>
1920
1921 <p>Here is a mailing list message reporting experience with the newer
1922 SoftRemote product.</p>
1923 <pre>From: Whit Blauvelt &lt;whit@transpect.com&gt;
1924 Subject: Re: [Users] RE: SafeNet SoftRemote 6.1 - FS 1.91 - HOW?
1925 Date: Fri, 16 Nov 2001
1926
1927 Things I've learned in getting SoftRemote working with FreeS/WAN:
1928
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.
1936
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.
1940
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>
1947
1948 <p>Much of the infornation available <a href="#softPK">above</a> for the
1949 earlier SoftPK product should also apply to SoftRemote.</p>
1950
1951 <h3><a name="borderware">Borderware</a></h3>
1952
1953 <h3><a name="freegate">Freegate</a></h3>
1954 <pre>Subject: ipsec interoperability FYI
1955    Date: Sun, 02 May 1999
1956    From: Sean Rooney &lt;sean@coldstream.ca&gt;
1957
1958 we've been doing some basic interoperability testing of the following;
1959
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]
1962
1963 more details coming soon.</pre>
1964
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 &lt;dcthebrain@geek.com&gt;
1969
1970 Just a quick note of success.  TimeStep Permit/Gate (2520) and
1971 Free/Swan (June 4th snapshot) interoperate!
1972
1973 I have them working in AUTO mode, with IKE.  IPSec SA's are negotiated
1974 with 3DES and MD5.
1975
1976 Here are the configs and a diagram for both configs.
1977
1978 left subnet---| Timestep | --- internet --- | Linux box |
1979
1980 The left subnet is defined as the red side of the timestep box.
1981  This network definition MUST exist in the Secure Map.
1982
1983 On the Linux box:
1984
1985 ipsec.conf
1986
1987 conn timestep
1988         type=tunnel
1989         left=209.yyy.xxx.6
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
1995         keyexchange=ike
1996         keylife=8h
1997         keyingtries=0
1998
1999 In the TimeStep permit/gate Secure Map
2000
2001 begin static-map
2002         target "209.yyy.xxx.128/255.255.255.128"
2003         mode   "ISAKMP-Shared"
2004         tunnel "209.yyy.xxx.6"
2005 end
2006
2007 In the TimeStep Security Descriptor file
2008
2009 begin security-descriptor
2010         Name    "High"
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"
2014 end
2015
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>
2018
2019 <h3><a name="shiva">Shiva/Intel LANrover</a></h3>
2020
2021 <p>A <a href="http://snowcrash.tdyc.com/freeswan/">web page</a> with Shiva
2022 compatibility information.</p>
2023
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 &lt;Peter.Onion@btinternet.com&gt;
2028
2029 Slowaris 8 has a native (in kernel) IPSEC implementation.
2030
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>
2033
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" &lt;dilan_a@impark.com&gt;
2038
2039 ***************************************************
2040 I know I HAVE TO write the mini-howto - but here is the beginning
2041 ***************************************************
2042
2043 Here is my Sonicwall configuration for my working connection:
2044
2045 conn testauto
2046         left=x.x.x.x
2047         leftnexthop=x.x.x.x
2048         right=y.y.y.y
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. &lt;------IMPORTANT
2053         rightid=sw@sonicwall.com
2054         authby=secret
2055         auth=esp
2056         esp=3des-hmac-md5
2057         ikelifetime=6h
2058         keylife=5h
2059
2060 Your /etc/ipsec.secrets should be like this:
2061 x.x.x.x y.y.y.y sw@sonicwall.com : PSK "opensesame"
2062
2063 On the Sonicwall create a new connection:
2064
2065 Name: testauto
2066 IPSec Gateway address: 0.0.0.0
2067 SA life time: 18000
2068 Encryption Method: Strong Encrypt and Authenticate( EPS 3DES HMAC MD5)
2069 Shared Secret: opensesame</pre>
2070
2071 <h3><a name="radguard">Radguard</a></h3>
2072
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.
2080
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.
2087
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.
2091
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>
2095
2096 <h3><a name="IBM.s390">IBM System 390</a></h3>
2097
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
2100 document</a>.</p>
2101
2102 <p>We do not know of any tests of this with FreeS/WAN. If you do any, please
2103 tell us.</p>
2104
2105 <h3><a name="IBM.as400">IBM AS 400</a></h3>
2106
2107 <p>From the mailing list:</p>
2108 <pre>Subject: [Users] AS/400 &lt;-&gt; FreeS/WAN connection
2109    Date: Mon, 24 Sep 2001 10:28:54 -0600
2110    From: "Brandon Peterson" &lt;bsp@MCINTOSHSOFTWARE.COM&gt;
2111
2112 All,
2113
2114 FYI, I got a connection working between my Linux box &amp; AS/400. I had to make
2115 two adjustments to the code...
2116
2117 1) Ignore the commit flag. (There were some patches floating on the list
2118 last week)
2119
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-&gt;policy == 0) c-&gt;policy = 1;</pre>
2124
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>
2127
2128 <h3><a name="winclient">Windows or Mac clients</a></h3>
2129
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>
2133
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>
2139
2140 <p>Quite a number of client programs for IPsec on Windows are available. Some
2141 of the same vendors have Macintosh versions.</p>
2142
2143 <p>Some of the <a href="#otherpub">user-written HowTos</a> have details of
2144 configuration for particular clients.</p>
2145
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 &lt;claudia@coldstream.ca&gt;
2149     Date: Wed, 12 Jul 2000
2150
2151 F-Secure VPN+
2152 -------------
2153 for Win 95, 98 and NT 4.0
2154 http://www.datafellows.com/products/vpnplus
2155
2156
2157 Checkpoint SecureRemote VPN-1 4.1
2158 ---------------------------------
2159 for Win 95, 98 and NT
2160 http://www.checkpoint.com/techsupport/freedownloads.html
2161
2162
2163 Raptor Firewall, Raptor MobileNT 5.0
2164 -------------------------------------
2165 Mobile NT is a "Client"* for Win 95, 98 (except SE), &amp; 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.
2168
2169 Firewall is for Win NT 4.0 or Win 2000.
2170 http://www.axent.com
2171
2172
2173 IRE SafeNet SoftPK
2174 ------------------
2175 a "Client" for Win 95, 98 and NT 4.0 *
2176 http://www.ire.com
2177
2178
2179 Xedia's AccessPoint QVPN "Client" or "Builder"
2180 ----------------------------------------------
2181 "Builder" is for NT
2182 "Client" is for Win 98 *
2183 http://www.xedia.com
2184
2185 * "Client" in this context indicates software that does not support a subnet
2186 behind its end of the connection.</pre>
2187
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>
2193
2194 <p>We also know of some other Windows IPsec clients:</p>
2195 <ul>
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>
2198 </ul>
2199
2200 <p>No doubt there are others we don't know of.</p>
2201
2202 <h3><a name="NTdomain">NT domains vs. tunnels</a></h3>
2203
2204 <p>There has been some mailing list discussion of making NT domains work
2205 across FreeS/WAN tunnels.</p>
2206
2207 <p>Robert Cotran asked:</p>
2208 <pre>&gt; I have a VPN setup between two subnets (192.168.1.x and 192.168.2.x).  I
2209 &gt; would like to be able to join the NT domain on 192.168.1.x from the
2210 &gt; 192.168.2.x subnet.  Is this possible?  Do I have to forward specific ports
2211 &gt; to do this?  I've already set up WINS entries for all the machines, so
2212 &gt; accessing computers by their NetBIOS names works perfectly.  Please let me
2213 &gt; know about this domain thing.  Thanks!</pre>
2214 Dilan Arumainathan answered:
2215 <pre>All you need to do is to:
2216
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
2221
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.
2232
2233 <h3><a name="win2k">Windows 2000</a></h3>
2234
2235 <p>Windows 2000 ships with an IPsec implementation built in.</p>
2236
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>
2242
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
2247 web site</a>.</p>
2248
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
2252 this. See this <a
2253 href="http://www.wired.com/news/technology/0,1282,36336,00.html">Wired
2254 article</a>.</p>
2255
2256 <h4><a name="lin2k">Other Linux services related to Win 2000</a></h4>
2257
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>
2261 <ul>
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.
2267     <ul>
2268       <li><a href="http://web.mit.edu/network/kerberos-form.html">MIT
2269         Kerberos site</a></li>
2270       <li><a
2271         href="http://www.isi.edu/~brian/security/kerberos.html">"'Moron's
2272         Guide"</a></li>
2273       <li>Kerberos <a href="http://alycia.dementia.org/kerberos.html">links
2274         page</a></li>
2275     </ul>
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
2282     with it.</p>
2283   </li>
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
2286   services</li>
2287   <li><a href="http://tipxd.sourceforge.net/">tipxd</a>, the Tunelling IPX
2288     Daemon, encapsulates IPX for transport over IP.</li>
2289 </ul>
2290
2291 <p>Here is a mailing list message, from FreeS/WAN team tech support person
2292 Claudia Schmeing, discussing Windows 2000 and L2TP:</p>
2293 <pre>You write,
2294
2295 &gt; I want some information about IPsec with L2TP.
2296 &gt; I'm going to build the IPsec tunnel on the L2TP tunnel.
2297 &gt; Is it strange?
2298 &gt; Is there any case like this already implemented?
2299
2300 It's used, but rarely. In many cases, IPSec alone is sufficient.
2301
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
2305
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>
2308
2309 <h4><a name="interop.win2k">FreeS/WAN-to-Win2000 interop</a></h4>
2310
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>
2314
2315 <p>This <a
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>
2318
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 &lt;marcus@ebootis.de&gt;
2324
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.
2328
2329 The tool has the following features:
2330
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
2334
2335 You only need the following items:
2336 1. Win2k Client
2337 2. Win2k Service Pack 2 (for high encryption)
2338 3. Microsoft ipsecpol tool (included in the resource kit / Downloadable
2339 from Microsoft)
2340 4. FreeSwan with working X.509 Patch and X.509 Certificates for your
2341 Clients
2342 5. FreeSwan like Config-File
2343 6. The small "ipsec.exe" Tool
2344
2345 I have tested it on several Client PCs in different environment
2346
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.
2350
2351 Rightnow anyone interested should mail me for a Copy, so I get some
2352 more testers.
2353
2354 Thank you for the great FreeSwan System !!!</pre>
2355
2356 <p>This tool is now available from the author's <a
2357 href="http://vpn.ebootis.de/">web page</a>.</p>
2358 </body>
2359 </html>