freeswan/doc/interop.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <HTML>
   3 <HEAD>
   4 <TITLE> Introduction to FreeS/WAN</TITLE>
   5 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   6 </HEAD>
   7 <BODY>
   8 <A HREF="toc.html">Contents</a>
   9 <A HREF="compat.html">Previous</a>
  10 <A HREF="politics.html">Next</a>
  11 <HR>
  12 <H1 name="interop"><A NAME="10">Interoperation with other IPSEC
  13 implementations</A></H1>
  14 <P> The IPSEC protocols are designed to allow interoperation between
  15 different implementations. Other sections of this documentation have
  16 more detail on: </P>
  17 <UL>
  18 <LI>the IPSEC <A href="ipsec.html">protocol specifications</A></LI>
  19 <LI>parts of the protocols <A href="compat.html#spec">implemented or
  20 ommitted</A> in FreeS/WAN </LI>
  21 <LI><A href="web.html#implement">other implementations</A></LI>
  22 </UL>
  23 <P> FreeS/WAN does interoperate successfully with many other
  24 implementations. The ones we know about are listed <A href="#mail.interop">
  25 below</A>.</P>
  26 <P> Of course &quot;the devil is in the details&quot; and the IPSEC protocols
  27 have a lot of details. At least one <A href="http://www.counterpane.com/ipsec.pdf">
  28 critique</A> has argued that the protocols should be simplified.
  29 Various of those details can and do cause difficulties for
  30 interoperation. Should you encounter such problems, please let us know
  31 via the <A href="mail.html">mailing list</A>. We will likely be able to
  32 help you, and your report may be useful both to other users and to the
  33 implementation teams.</P>
  34 <P><STRONG> Note:</STRONG> This file is updated often, whenever I
  35 notice an interesting interop report on the mailing list. If you are
  36 reading the version that ships with a FreeS/WAN release or is posted on
  37 the web, and what you need isn't here, consider downloading the latest
  38 snapshot to get the latest version of the doc. Perhaps I've added what
  39 you need since the last release. </P>
  40 <P> There is additional information on interoperability testing in our <A
  41 href="web.html#interop">web links</A> section. </P>
  42 <H2><A name="patch.interop">Patches to extend interoperability</A></H2>
  43  Sometimes interoperation requires user-contributed patches or add-ons
  44 on the FreeS/WAN end. In general, no patches to the actual IPSEC code
  45 are required. The problem is to make FreeS/WAN recognise RSA keys
  46 stored in formats other than ours. Each such format needs either a
  47 patch to make FreeS/WAN understand that format or a utility to
  48 translate it to the FreeS/WAN format.
  49 <P> For example, unmodified FreeS/WAN cannot use RSA keys generated by <A
  50 href="glossary.html#PGP">PGP</A> or keys stored in <A href="glossary.html#X.509">
  51 X.509</A> certificates, but patches or utilities are available for both
  52 those formats. See this list of <A href="web.html#patch"> patches and
  53 add-ons</A>. </P>
  54 <H2><A name="interop.problem">Interoperability problems</A></H2>
  55 <P> The IPSEC RFCs are complex and include a number of optional
  56 features.  There is considerable opportunity for even two correct,
  57 standard-conforming,  implementations to disagree on details in a way
  58 that blocks interoperation.  Of course, misinterpretations of the
  59 standards and implementation or  configuration errors on either end can
  60 also foul things up.</P>
  61 <P>That said, FreeS/WAN interoperates successfully with many other
  62  implementations. There is a <A href="#mail.interop">list</A> below.</P>
  63 <P> Known areas where problems may appear are:</P>
  64 <UL>
  65 <LI><STRONG>FreeS/WAN does not implement single DES</STRONG> because <A href="politics.html#desnotsecure">
  66 DES is insecure</A>. Suggestions on what to do if  the device you want
  67 to talk to has only DES are <A href="#noDES">below</A>.</LI>
  68 <LI><STRONG>FreeS/WAN does not implement Diffie-Hellman group 1</STRONG>
  69  because it  it is not entirely clear that this is secure.</LI>
  70 <LI>The RFCs define two modes for IKE negotiations -- main mode and
  71  aggressive mode. Aggressive mode is slightly faster, but reveals more
  72  information to an eavesdropper. Specifically, it lets an eavesdropper
  73  know what identities are in use. <STRONG>FreeS/WAN does not implement
  74  aggressive mode</STRONG>, so any negotiation another implementation
  75  tries that way will fail. </LI>
  76 <P> In principle this should not be a problem  since main mode support
  77 is required in all implementations and aggressive  mode is optional.
  78  In practice, it is sometimes a problem.  Some implementations default
  79 to  aggressive mode unless you configure them for main mode.</P>
  80 <LI> For automatic keying, <STRONG>the FreeS/WAN default is to provide <A
  81 href="glossary.html#PFS"> perfect forward secrecy</A></STRONG>. We see
  82 no reason not  to; this is more secure and costs little. Some other
  83 implementations,  however, turn PFS off by default. </LI>
  84 <P> You can turn PFS off in FreeS/WAN with the <VAR>pfs=no</VAR>
  85  setting in <A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A>,
  86 but if possible  we suggest you enable it on the other end instead.
  87 That is more secure.</P>
  88 <LI> The IKE protocol allows several types of optional message. Two
  89 things happen  which are allowed by the RFCs:
  90 <UL>
  91 <LI>Some implementations send various optional messages. </LI>
  92 <LI>FreeS/WAN ignores them. </LI>
  93 </UL>
  94  However, problems may arise if the other end relies on some expected
  95 effect  of these messages. There are two FAQ questions dealing with
  96 this, one on the <A href="faq.html#ignore"> log message</A> FreeS/WAN
  97 gives when ignoring  optional payloads and one on the <A href="faq.html#deadtunnel">
  98 delete SA</A> payload. </LI>
  99 </UL>
 100 <P> The general rule is that to interoperate with FreeS/WAN, the other
 101 implementation should be configured for:</P>
 102 <UL>
 103 <LI>main mode</LI>
 104 <LI>triple DES encryption</LI>
 105 <LI>Diffie-Hellman Group 2 or 5 </LI>
 106 </UL>
 107 <P> This is possible for most implementations.</P>
 108 <H3><A name="noDES">Systems that want to use single DES</A></H3>
 109 <P> Linux FreeS/WAN does not support single DES transforms. Neither
 110 Pluto's IKE connections nor KLIPS' IPSEC connections can use DES. Since <A
 111 href="politics.html#desnotsecure">DES is insecure</A> we do not, and
 112 will not at any future time, provide it.</P>
 113 <P> DES is, unfortunately, a mandatory part of the <A href="glossary.html#IPSEC">
 114 IPSEC</A> standard. Despite that, we will not implement DES. We believe
 115 it is more important to provide security than to comply with a standard
 116 which has been <A href="politics.html#weak">subverted</A> into allowing
 117 weak algorithms. See our <A href="politics.html">history and politics</A>
 118  section for discussion.</P>
 119 <P> Some implementations may offer DES as the default. In such cases we
 120 urge you to change them to <A href="glossary.html#3DES">Triple DES</A>.
 121 If this is not possible, for example because <A href="politics.html#exlaw">
 122 export laws</A> prevent your vendor from offerring you adequate
 123 crytography, we urge you to complain vigorously to one or more of:</P>
 124 <UL>
 125 <LI>your government, especially any department concerned with
 126 protecting citizens'  privacy or your nation's communication
 127 infrastructure</LI>
 128 <LI>the vendor</LI>
 129 <LI>the embassy of the nation whose laws are problematic for you</LI>
 130 </UL>
 131 <P> Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES
 132 now. </P>
 133 <P> FreeS/WAN does have <A href="glossary.html#DES">DES</A> code in it
 134 as a sort of historical accident, since we need it to implement our
 135 default (currently, our only) block cipher, <A href="glossary.html#3DES">
 136 Triple DES</A>. However, since <A href="politics.html#desnotsecure">DES
 137 is insecure</A>, we do not provide any interface to that code.</P>
 138 <P> As a matter of project policy, we will not help anyone subvert
 139 FreeS/WAN to provide <A href="politics.html#desnotsecure">insecure DES
 140 encryption</A>. </P>
 141 <H2><A name="otherpub">Interop HowTo documents</A></H2>
 142 <P> The FreeS/WAN team does not have the resources to test with
 143 anything like the full range of <A href="web.html#implement">other
 144 IPSEC implementations</A> out there. Fortunately, some of our users are
 145 doing a fine job of filling the gap by providing HowTo information:</P>
 146 <UL>
 147 <LI>Hans-Jorg Hoxer's <A href="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html">
 148  HowTo</A> covering interoperation between any two of:
 149 <UL>
 150 <LI>FreeS/WAN</LI>
 151 <LI>Open BSD IPSEC</LI>
 152 <LI>Windows 98 with PGPnet</LI>
 153 </UL>
 154 </LI>
 155 <LI>Jean-Francois Nadeau's <A href="http://jixen.tripod.com/">practical
 156  configurations</A> document covers FreeS/WAN interoperation with
 157 <UL>
 158 <LI>Windows 2000 IPSEC</LI>
 159 <LI>NAI PGPnet</LI>
 160 <LI>IRE Safenet SoftPK.</LI>
 161 </UL>
 162 </LI>
 163 <LI>Oscar Delgado's <A href="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">
 164  page</A> has a PDF document covering interop using X.509  certificates
 165 between FreeS/WAN and:
 166 <UL>
 167 <LI>Windows 2000 </LI>
 168 <LI>PGPnet </LI>
 169 </UL>
 170 </LI>
 171 <LI>Terrandon Communications provide a <A href="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">
 172  PDF HowTO</A> on using FreeS/WAN with IRE SafeNet </LI>
 173 <LI>Telenor provide a HowTo on <A href="http://security.nta.no/freeswan-w2k.html">
 174 FreeS/WAN and Windows 2000</A></LI>
 175 <LI>Carl's Guide for <A href="http://el06-24-29-255-187.ce.mediaone.net/carl/linux/ipsec/swan-w2k/swanw2k-b.html">
 176  FreeS/WAN and Windows 2000</A></LI>
 177 <LI>Ryan's <A href="http://www-ec.njit.edu/~rxt1077/Howto.txt">HowTo</A>
 178  for getting PGPnet to  connect with FreeS/WAN using x509 certs through
 179 a Linksys router, with IPSec passthru enabled. </LI>
 180 </UL>
 181 <P> See also our list of available <A href="web.html#patch">patches and
 182 add-ons</A>. </P>
 183 <H2><A name="mail.interop">Interoperation with specific products</A></H2>
 184 <P> Most of the information in this section is gleaned from the mailing
 185 list. For additional information, search one of the list <A href="mail.html#archives">
 186 archives</A>.</P>
 187 <P> A large thank you is in order to all the list contributors. This
 188 document would not exist without you. </P>
 189 <P><STRONG> Anyone who has tested with an implementation not listed
 190 here, please report results</STRONG> to the <A href="mail.html">mailing
 191 list</A>. I generally include the sender's email address when I quote
 192 list messages here; &quot;credit where credit is due&quot;. If you would prefer
 193 that I not do that with yours, please mention that.</P>
 194 <H3><A name="oldswan">Older versions of FreeS/WAN</A></H3>
 195  Any two versions of FreeS/WAN should interoperate, and many
 196 combinations have been tested doing so successfully. In particular,
 197 every release is tested against its predecessor before it goes out.
 198 <P> However, if you do encounter a problem involving an older version,
 199 we are likely to suggest you upgrade. We do not have the resources to
 200 support multiple versions. </P>
 201 <P> The <A href="faq.html#old_to_new">FAQ</A> also discusses this. </P>
 202 <H3><A name="OpenBSD">OpenBSD</A></H3>
 203  Two documents we know of cover interoperation between FreeS/WAN and
 204 Open BSD IPSEC:
 205 <UL>
 206 <LI>Hans-Jorg Hoxer's <A href="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html">
 207 HowTo</A></LI>
 208 <LI>Skyper's <A href="http://www.segfault.net/ipsec/">guide</A></LI>
 209 </UL>
 210 <P> This report is from one of the OpenBSD IPSEC developers, a regular
 211  participant on our mailing list:</P>
 212 <PRE>
 213 Subject: spi.c bug
 214    Date: Tue, 23 Feb 1999
 215    From: Niklas Hallqvist &lt;niklas@appli.se&gt;
 216
 217 PS.  I don't know if you have an interop list anywhere, but you should
 218 know FreeS/WAN interops with OpenBSD both at the IPSec level and at
 219 the IKE level.
 220 </PRE>
 221 <P> He has also talked of porting NetBSD's isakmpd(8) to Linux, but has
 222 (as of late April '99) made no announcement of availability. This would
 223 provide an alternative to our pluto(8) daemon with a somewhat different
 224 feature set. Our <A href="glossary.html#KLIPS">KLIPS</A> kernel code
 225 would still be used.</P>
 226 <P> The <A href="http://www.openbsd.org/faq/faq13.html">OpenBSD FAQ</A>
 227  includes information on their IPSEC implementation. </P>
 228 <H3><A name="FreeBSD">FreeBSD</A></H3>
 229 <P>The only <A href="http://www.r4k.net/ipsec/">reference</A> we have
 230 to IPSEC for FreeBSD says their code was ported from OpenBSD.</P>
 231 <P> Here is a mailing list message on FreeBSD interoperation: </P>
 232 <PRE>
 233 Subject: Re: Interop with [Free|Open|Net]BSD
 234    Date: Fri, 29 Dec 2000
 235    From: Ghislaine Labouret &lt;Ghislaine.Labouret@hsc.fr&gt;
 236
 237 On Thu, 28 Dec 2000 13:53:01 -0500, Sandy Harris wrote:
 238
 239 &gt; FreeBSD:
 240 &gt;
 241 &gt; For FreeBSD, I find list discussion of 3DES key formats, presumably for manual
 242 &gt; keying. We have 192-bit, 3 64-bit keys including parity bits, while FreeBSD 4.0
 243 &gt; used 168-bit, 3 56-bit keys without the parity bits. Has FreeBSD changed this?
 244
 245 I still don't understand what made Spike Gronim say that KAME wants a
 246 168 bits key; I have always been using 192 bits keys with KAME and had
 247 no interoperability problem between KAME and FreeS/WAN using manual
 248 keying.
 249
 250 &gt; For auto keying, I find reports of sucessful use of pre-shared secrets, but
 251 &gt; nothing on RSA authentication.
 252
 253 I had KAME (20001023 snapshot) and FreeS/WAN 1.6 successfully
 254 interoperate using both PSK and RSA-sig authentication. The config
 255 files, certificates and test keys used are available online:
 256 http://www.hsc.fr/ipsec/ipsec2000/kame/
 257 http://www.hsc.fr/ipsec/ipsec2000/freeswan/
 258 Not much details though, as this is just a report and not a how-to. Will
 259 improve it if I can find spare time.
 260
 261 &gt; Does FreeBSD support that?
 262
 263 KAME can use RSA-sig and can either exchange certificates online or get
 264 them from a file. I tested the latter. No test with the X.509 patch for
 265 FreeS/WAN yet, though that's in my short term plans too.
 266
 267 &gt; Are the key formats compatible, or has anyone written translation code?
 268
 269 KAME wants the keys inside certificates, in PEM format. To extract the
 270 keys for FreeS/WAN I used the fswcert utility, but it can be done &quot;by
 271 hand&quot; using openssl.
 272 </PRE>
 273 <H3><A name="NetBSD">NetBSD</A></H3>
 274  NetBSD has an IPSEC implementation, described in this <A href="http://www.netbsd.org/Documentation/network/ipsec/">
 275 FAQ</A>.
 276 <H3><A name="Cisco">Cisco Routers</A></H3>
 277  Useful pages on Cisco sites include:
 278 <UL>
 279 <LI><A href="http://www.cisco.com/warp/public/471/top_issues/vpn/vpn_index.shtml">
 280 VPN support</A></LI>
 281 <LI><A href="http://www.ieng.com/warp/public/700/tech_configs.html">
 282 sample configurations</A></LI>
 283 </UL>
 284 <P> Here is a mailing list <A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00578.html">
 285 message</A> with subject &quot;FreeS/WAN and Cisco 3030 VPN Concentrator&quot;
 286 and an attached MS-Word document on the setup. </P>
 287 <P> A sample FreeS/WAN configuration, used in testing with Cisco at an
 288 interop conference, is in another list <A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00095.html">
 289 message</A>. Unfortunately, it does not give the matching Cisco
 290 configuration. </P>
 291 <P> Here is our first interop success report: </P>
 292 <PRE>
 293 Subject: cisco &lt;-&gt; pluto IKE interop is here........
 294    Date: Thu, 28 Jan 1999
 295    From: Ian Calderbank
 296
 297 Ok, tried todays pluto (28 jan) snapshot against a (wait for it) 3des
 298 cisco box, one with some more serious grunt for benchmarking when the time
 299 comes.
 300
 301 And the good news is that pluto and cisco's IKE seem to interoperate. At
 302 the end of things both devices seem to be happy that they have IKE and
 303 IPSEC SA's. I can't send any traffic over it cos klips seems to be broken
 304 (peter seems to be on the case), but fundamentally, pluto seems to be
 305 interoperable with cisco for SA negotiation.
 306
 307 I've attached some ipsec barf output - pluto still complains a few times,
 308 but it gets there :-)
 309 </PRE>
 310 <P> A later message from Ian:</P>
 311 <PRE>
 312 This configuration is provided as-is and with no assistance or guarantee
 313 that it works whatsover. In particular your attention is drawn to the versions
 314 of operating systems and IPSEC that were used in the test. Configurations
 315 for later versions of freeswan and cisco IOS may well be different.
 316
 317 Cisco router: 3640 (R4700 processor), ios 12.0(2a)T1), 3DES IPSEC feature set
 318 ( you do need the 3des version).
 319 Linux box: P150, freeswan 29/jan/99 snapshot, Redhat 5.2, kernel 2.0.36.
 320 Interconnect: 10 Base T.
 321 Algorithm: ESP 3des/md5
 322
 323 CPU loadings:
 324 Cisco 3640 : 98%
 325 Freeswan P150 : load average: 0.08, 0.06, 0.01
 326
 327 Throughput: 1.1 Mbit/sec at the application layer, approx 1.2Mbit/sec, 100 packet/sec on
 328 the external network. There were no chokes present, so the limit would
 329 appear to be the 3640, given it was running near flat out.
 330
 331 --------------------------
 332
 333 Freeswan config:
 334 /etc/ipsec-auto
 335
 336 auto    ipsec-router-test
 337         type=tunnel
 338         left=x.x.x.x
 339 # x.x.x.x = linux box public ip address
 340         right=y.y.y.y
 341 # y.y.y.y = router public ip address
 342         rightsubnet=192.168.2.0/24
 343 # private network behind the router - host to which throughput testing was done is here.
 344         keyexchange=ike
 345         encrypt=yes
 346         authenticate=no
 347         pfs=no
 348         lifetime=8h
 349
 350 ----------------------------
 351
 352 Cisco Router config:
 353
 354 crypto isakmp policy 1
 355  encr 3des
 356  hash md5
 357  authentication pre-share
 358 crypto isakmp key SECRET-VALUE address x.x.x.x
 359 crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
 360 crypto map TEST 1 ipsec-isakmp
 361  set peer x.x.x.x
 362  set transform-set 3DES-MD5
 363  match address 101
 364 access-list 101 permit ip 192.168.2.0 0.0.0.255 host x.x.x.x
 365 interface
 366 crypto map TEST
 367 </PRE>
 368 <P> A <A href="http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t2/3desips.htm">
 369 page</A> on Cisco's site gave this list (early Jan 2000, before new US
 370 export  regulations went into effect):</P>
 371 <PRE>
 372 | Triple DES Encryption for IPSec
 373 |
 374 | ...
 375 |
 376 | This feature is supported only on the following platforms:
 377 |
 378 |     1720
 379 |     2600 Series
 380 |     3600 Series
 381 |     4000 Series
 382 |     4500 Series
 383 |     AS5300 Series
 384 |     7200 Series
 385 |     7500 Series
 386 </PRE>
 387  A message from another user about using RSA keys with Cisco:
 388 <PRE>
 389 From: jrussi@uol.com.br
 390 Subject: Re:Re: Re:Re: [Users] RSA public key and Cisco (3640)
 391 Date: Sat, 2 Jun 2001
 392
 393 We use Cisco IOS 12.1.5(T) and freeswan 1.8
 394
 395 Here an example on how I copied the key from cisco:
 396
 397 Key Data:
 398   117C311E 16192D86 8886C71D 11111115 11138B11 31881241 11C7E23B D6DB22
 399   18DEC1BD....
 400
 401 Will become
 402
 403 0x117C311E16192D868886C71D1111111511138B113188124111C7E23BD6DB2218DEC1BD...
 404
 405 We used at least 1024 bits long keys.
 406
 407 But it doesn&acute;t matter. The problem is that cisco doesn&acute;t agree with the RSA schema from freeswan, I think. In Cisco, rsasig is to use with a CA, and rsaencript did not work as well.
 408
 409 My case is worse than it. My first intention was to use freeswan in a road warrior config. I really need to use CA, as Cisco needs a fix address to use rsa public key. The public key to cisco is always associated to an IP address ou FQDN. I quit. Will try the X509 patch and the Open CA software.
 410
 411 Deyvi
 412 &gt;&gt;(off list)
 413 &gt;
 414 &gt;Yes, I was just going to mention that the Cisco's key should be in
 415 &gt;ipsec.conf (just received your correction).
 416 &gt;
 417 &gt;I think that I have the Cisco side configured correctly ( I can't be sure
 418 &gt;because I can't test against the Freeswan).
 419 &gt;
 420 &gt;Starting from having the IPsec tunnel working with pre-share, I did the
 421 &gt;following on the Cisco side:
 422 &gt;
 423 &gt;#config t
 424 &gt;(config)# crypto key pubkey-chain rsa
 425 &gt;(config-pubkey-chain)# addressed-key
 426 <!--ipaddress of freeswan-->
 427
 428 &gt;(config-pubkey-key)# key-string
 429 &gt;(config-pubkey-key)#
 430 <!--paste freeswan key here-->
 431
 432 &gt;(config-pubkey-key)#quit
 433 &gt;(config-pubkey-chain)#exit
 434 &gt;
 435 &gt;# config t
 436 &gt;(config)# crypto isakmp policy 1
 437 &gt;(config-isakmp)# no authentication pre-share
 438 &gt;(config-isakmp)# authentication rsa-sig
 439 &gt;(config-isakmp)# exit
 440 &gt;
 441 &gt;How long is your RSA key that was generated on the Cisco? I tried copying
 442 &gt;the key out of the 3640 and pasting it into ipsec.conf, removing the spaces
 443 &gt;and adding a '0x' in the front. I get the 'key too small' error still. What
 444 &gt;version of freeswan are you using?
 445 &gt;
 446 &gt;I'm using Freeswan 1.9 w/ IOS 12.1(6).
 447 &gt;
 448 &gt;
 449 &gt;----- Original Message -----
 450 &gt;From:
 451 <!--jrussi@uol.com.br-->
 452
 453 &gt;To: &quot;James Rowe&quot;
 454 <!--jrowe@cisco.com-->
 455 ;
 456 <!--jrussi@uol.com.br-->
 457
 458 &gt;Cc:
 459 <!--users@lists.freeswan.org-->
 460
 461 &gt;Sent: Thursday, May 31, 2001 5:15 PM
 462 &gt;Subject: Re:Re: [Users] RSA public key and Cisco (3640)
 463 &gt;
 464 &gt;
 465 &gt;&gt; We had no problems with the key. Just be sure to remove the blank spaces
 466 &gt;from the key (general key) that cisco generates.
 467 &gt;&gt;
 468 &gt;&gt; Just remove the blank, put all together as a long line (all the lines to a
 469 &gt;single line) and add a &quot;0x&quot; at the key that Cisco give to you, and paste to
 470 &gt;ipsec.secrets.
 471 &gt;&gt;
 472 &gt;&gt; The public key from FreeSwan, you just remove the &quot;0x&quot; and paste to the
 473 &gt;command line at cisco. They will not complain about the keys.
 474 &gt;&gt;
 475 &gt;&gt; But my problem is with the proposal configured at Cisco. What to you think
 476 &gt;to use? I tried &quot;authentication rsasig&quot; and &quot;rsaencrip&quot; with no results.
 477 &gt;Cisco always sends me an &quot;No proposal choosen&quot; error message.
 478 &gt;&gt;
 479 &gt;&gt; I road an old message from someone called Brian here at this list, where
 480 &gt;he says that FreeSwan will not accept authentication rsaencript from Cisco.
 481 &gt;But rsasig is to use with a CA certification. So my question is: is it
 482 &gt;possible to use Cisco with public RSA keying, without a CA? The thread ended
 483 &gt;without an answer to it.
 484 &gt;&gt;
 485 &gt;&gt; Deyvi
 486 &gt;&gt; &gt;&gt;Hello,
 487 &gt;&gt; &gt;
 488 &gt;&gt; &gt;I am working on the same issue. I have pre-shared working, but would like
 489 &gt;to
 490 &gt;&gt; &gt;use RSA public keys. It seems that the Cisco key is too short. When
 491 &gt;starting
 492 &gt;&gt; &gt;IPsec in init.d, it says that the Cisco key is not secure because it is
 493 &gt;less
 494 &gt;&gt; &gt;than 512 bits, even tough the key is really over 768 bits. Claudia thinks
 495 &gt;&gt; &gt;this is a parsing problem and suggested to take a look at the source
 496 &gt;code.
 497 &gt;&gt; &gt;
 498 &gt;&gt; &gt;Some pointers that I have found while working on this:
 499 &gt;&gt; &gt;
 500 &gt;&gt; &gt;You must add a '0x' to the front of the Cisco key when entering it into
 501 &gt;&gt; &gt;Freeswan, and remove the '0x' when entering the freeswan key into the
 502 &gt;Cisco
 503 &gt;&gt; &gt;3640.
 504 &gt;&gt; &gt;
 505 &gt;&gt; &gt;The case of the hexadecimal letters in the key does not matter. Thinking
 506 &gt;&gt; &gt;that freeswan stopped reading the key when it encountered the first
 507 &gt;&gt; &gt;uppercase letter in the Cisco key (freeswan keys are lowercase, Cisco's
 508 &gt;are
 509 &gt;&gt; &gt;uppercase), I changed everything to lowercase. Didn't help.
 510 &gt;&gt; &gt;
 511 &gt;&gt; &gt;I'll let you know if I make any progess on this. I'd appreciate if you
 512 &gt;would
 513 &gt;&gt; &gt;let me know if you get this working. Thanks.
 514 &gt;&gt; &gt;
 515 &gt;&gt; &gt;-- Jim Rowe
 516 &gt;&gt; &gt;
 517 &gt;&gt; &gt;----- Original Message -----
 518 &gt;&gt; &gt;From:
 519 <!--jrussi@uol.com.br-->
 520
 521 &gt;&gt; &gt;To:
 522 <!--users@lists.freeswan.org-->
 523
 524 &gt;&gt; &gt;Sent: Thursday, May 31, 2001 2:52 PM
 525 &gt;&gt; &gt;Subject: [Users] RSA public key and Cisco (3640)
 526 &gt;&gt; &gt;
 527 &gt;&gt; &gt;
 528 &gt;&gt; &gt;&gt; Does anyone have a sucessful Cisco config file to use in a
 529 &gt;freswan-cisco
 530 &gt;&gt; &gt;conection using RSA public key?
 531 &gt;&gt; &gt;&gt;
 532 &gt;&gt; &gt;&gt; We were able to setup a pre-shared conection, but would like to try
 533 &gt;public
 534 &gt;&gt; &gt;keying.
 535 </PRE>
 536 <H3><A name="bay">Nortel (Bay Networks) Contivity switch</A></H3>
 537  There is one known issue in FreeS/WAN-to-Contivity interoperation.
 538 Recent versions of FreeS/WAN no longer support DH group 1 for key
 539 exchange. Older versions of Contivity software support nothing else.
 540 Group 2 was added in more recent releases. So:
 541 <UL>
 542 <LI>older FreeS/WANs, such as 1.5, will work with any Contivity
 543 software. Key exchange will be done using DH Group 1. This may not be
 544 secure. </LI>
 545 <LI>current FreeS/WANs will work only with recent Contivity releases
 546 supporting DH Group 2. Contivity 3.5 is one such release. </LI>
 547 </UL>
 548  We recommend using the latest Contivity release.
 549 <P> Some messages from the mailing list: </P>
 550 <PRE>
 551 Subject: Contivity Extranet Switch
 552    Date: Fri, 11 Jun 1999
 553    From: Matthias David Siebler &lt;msiebler@nortelnetworks.com&gt;
 554 Reply-To: msiebler@alum.mit.edu
 555 Organization: Nortel Networks
 556
 557 More interoperability results:
 558
 559 I successfully established a tunnel with a Nortel (formerly Bay (formerly New Oak)) Contivity
 560 Extranet Switch running the latest release versions.
 561
 562 The CES is running V2.50 of the software and the Linux server is running V1.0.0 of the Free/SWAN
 563 code on a RedHat 5.2 unit with the kernel upgraded to 2.0.36-3
 564
 565 I am using IKE with 3DES-HMAC-MD5
 566
 567 Note however, that tunnels cannot yet be configured as client tunnels since Free/SWAN does not yet
 568 support aggressive mode.  Hopefully, that will arrive soon, which would allow remote users to
 569 connect to a CES using the Free/SWAN code as clients.
 570 </PRE>
 571 <P> and apparently Nortel want their product to work with FreeS/WAN:</P>
 572 <PRE>Subject: Is FreeSwan 3.1 a legitamate ipsec implementation when compared to its commercial competitors?
 573    Date: Tue, 02 May 2000
 574    From: Bill Stewart &lt;bill.stewart@pobox.com&gt;
 575
 576 Nortel's Contivity IPSEC server has a formal policy of interoperability
 577 with FreeS/WAN.   I was quite pleased to hear it when they last talked to us,
 578 and it makes sense in their business environment, since they let you use
 579 their WinXX client software free, so this gives them support for Linux
 580 clients.
 581 </PRE>
 582 <P> A more recent mailing list report is: </P>
 583 <PRE>
 584 Subject: Nortel Contivity and Free-S/WAN
 585    Date: Wed, 7 Mar 2001
 586    From:  &quot;JJ Streicher-Bremer&quot; &lt;jj@digisle.net&gt;
 587
 588 OK, here is a very brief nuts and bolts breakdown on how to get this
 589 combo working.  I want to thank everyone at Free-S/WAN and everyone on
 590 the list for your help in getting this to work.
 591
 592 Connecting FreeS/WAN to the Nortel Networks Contivity Extranet Switch:
 593
 594 What you need:
 595 FreeS/WAN v1.5 and Contivity ver 2.5 - 3.5 (might work with earlier
 596 versions, but I have not tested it with this config)
 597 or
 598 FreeS/WAN v1.8 and COntivity ver 3.5 (the 3.5 version supports Diffe
 599 Hilman group 2 key exchange)
 600
 601 What to do:
 602 1 - Configure the Contivity:
 603    Set up a branch office tunnel group with the following settings:
 604
 605         Connectivity:
 606         Nailed Up: Disabled
 607         Access Hours: Anytime
 608         Call Admission Priority: Highest Priority
 609         Forwarding Priority: Low Priority
 610         Idle Timeout: 00:00:00
 611         Forced Logoff: 00:00:00
 612         RSVP: Disabled
 613         RSVP: Token Bucket Depth: 3000 Bytes
 614         RSVP: Token Bucket Rate: 28 Kbps
 615         Branch Office Bandwidth Policy:
 616         - Committed Rate: 56 Kbps
 617         - Excess Rate: 128 Kbps
 618         - Excess Action: Mark
 619
 620         Encryption:
 621         - ESP - Triple DES with SHA1 Integrity: Enabled
 622         - ESP - Triple DES with MD5 Integrity: Enabled
 623         - ESP - 56-bit DES with SHA1 Integrity: Disabled
 624         - ESP - 56-bit DES with MD5 Integrity: Disabled
 625         *IKE Encryption and Diffie-Hellman Group: Triple DES with Group
 626 2 (1024-bit prime)
 627         Vendor ID: Disabled
 628         Perfect Forward Secrecy: Enabled
 629         Compression: Disabled
 630         Rekey Timeout: 08:00:00
 631         Rekey Data Count:  (None)
 632         *ISAKMP Retransmission Interval: 16
 633         *ISAKMP Retransmission Max Attempts: 4
 634
 635         Set up a branch office tunnel inside this new group with the
 636 following settings:
 637
 638         Endpoint Addresses
 639         Local - Public address of your COntivity
 640         Remote - Your Free-S/WAN interface Address
 641                 Tunnel Type - IPSEC
 642         IPSEC Authentication - Text Pre-Shared Key
 643                 One note here, I have had some trouble trying to use HEX
 644 or Non alphanumeric chars in this key.
 645
 646         Under IP:
 647         Static Routing
 648         Local - networks you want to be able to access through the
 649 tunnel
 650         Remote - networks that will be allowed through the tunnel
 651         NAT - None
 652
 653    Get routing setup on your office network:
 654         You will need to get a routing entry that will point all traffic
 655 bound for your home network (the one that will be acciessible through
 656 the tunnel) to the internal interface of the contivity system.
 657
 658    Configure Free-S/WAN:
 659         Install, compile, and test Free-S/WAN
 660         Edit ipsec.conf for your new tunnel:
 661 --------------------------------------------------------
 662 ipsec.conf --
 663 config setup
 664         interfaces=&quot;ipsec0=eth1&quot;
 665         forwardcontrol=no
 666         klipsdebug=none
 667         plutodebug=none
 668         manualstart=
 669         plutoload=%search
 670         plutostart=%search
 671         plutowait=no
 672 conn net1
 673         type=tunnel
 674         auto=start
 675         auth=esp
 676         authby=secret
 677         keyexchange=ike
 678         keylife=1h
 679         keyingtries=1
 680         pfs=yes
 681         left=10.0.0.2
 682         leftnexthop=10.0.0.1
 683         leftsubnet=10.0.1.0/24
 684         right=172.16.0.2
 685         rightsubnet=172.16.1.0/24
 686 conn net2
 687         type=tunnel
 688         auto=start
 689         auth=esp
 690         authby=secret
 691         keyexchange=ike
 692         keylife=1h
 693         keyingtries=1
 694         pfs=yes
 695         left=10.0.0.2
 696         leftnexthop=10.0.0.1
 697         leftsubnet=10.0.1.0/24
 698         right=172.16.0.2
 699         rightsubnet=172.16.2.0/24
 700
 701 ipsec.secrets --
 702 10.0.0.2 172.16.0.2 &quot;Your big secret&quot;
 703 ---------------------------------------------
 704
 705 The above config is for this imaginary network:
 706
 707          +------+
 708 10.0.1.1 |      |10.0.0.2   10.0.0.1++ Internet
 709 ---------|      |-------------------++===========
 710          +------+            Home Router
 711          Free-S/WAN host
 712
 713
 714 Internet ++    172.16.0.2####         172.16.1.0/24 These
 715 =========++--------------####---------172.16.2.0/24 are here somewhere
 716    Office Router       Contivity
 717
 718
 719    This has worked for me.  I am still having trouble with the tunnels
 720 dying after about 30-40 minutes of non-use.  Don't know what that is
 721 about, but I'll keep you posted.
 722 </PRE>
 723 <H3><A name="Raptor">Raptor Firewall</A></H3>
 724 <H4><A name="raptorNT">Raptor 5 on NT (old info)</A></H4>
 725 <PRE>
 726    Subject: Interoperability with Raptor 5 (Success!)
 727    Date: Wed, 06 Jan 1999 16:19:27 -0500
 728    From: Chuck Bushong &lt;chuckb@chandler-group.com&gt;
 729
 730 I don't know if this is useful information for anyone, but I have
 731 successfully established a VPN between RedHat 5.1 (kernel 2.0.34) running
 732 FreeS/WAN 0.91 and NT4 running Raptor 5.  However, Pluto does not appear
 733 compatible with the Raptor IKE implementation. . . .
 734
 735 Subject: RE: linux-ipsec: Interoperability with Raptor 5 (Success!)
 736 Date: Thu, 28 Jan 1999 17:22:55 -0500
 737 From: Chuck Bushong &lt;chuckb@chandler-group.com&gt;
 738
 739 ... this VPN (at least the klips end) has been up under minimal
 740 utilization for three weeks plus without interruption.  The
 741 machine seems very stable.  Pat yourself on the back, gentlemen.
 742 Your beta release is more stable than certain companies' shipping
 743 product.
 744
 745 Keep up the good work.
 746 </PRE>
 747 <H4><A name="raptorsun">Raptor 6 on Solaris</A></H4>
 748 <PRE>
 749 Subject: Re: successful interop. with Raptor 6.02
 750    From: &quot;Charles G. Griebel&quot; &lt;cggrieb@biw.com&gt;
 751    Date: Tue, 25 Jul 2000
 752
 753 On Thu, Jul 20, 2000 at 12:04:40PM -0700, Kevin Traas wrote:
 754 &gt; Great!  I'm just about to start looking into this as well, so any
 755 &gt; docs/info you can provide would be *greatly* appreciated.  Immortalize
 756 &gt; yourself!  Get something written and added to the compatibility.html
 757 &gt; file.  Many will thank you.
 758
 759 Can't be that hard.  I'm just a freeswan newbie who hasn't even done a FS
 760 <!----->
 761 FS
 762 tunnel yet :)
 763
 764 Anyway, I hope you find this helpful.
 765
 766 Chock
 767
 768 -------------------------------------------------------------------------------
 769
 770 Automatically keyed 3DES VPN between Raptor 6.02 on Solaris 2.6 (left) and
 771    FreeS/WAN 1.5 on 2.2.16 Intel (right)
 772
 773 FreeS/WAN (right) information:
 774 -----------------------------
 775
 776 ipsec.conf
 777 ----------
 778 config setup
 779         interfaces=&quot;ipsec0=ppp0&quot;    # change to suite
 780         klipsdebug=
 781         plutodebug=
 782         plutoload=sample
 783         plutostart=sample
 784
 785 conn sample
 786         left=10.0.0.1
 787         leftnexthop=10.0.0.2
 788         leftsubnet=192.168.0.0/24
 789         right=10.1.1.1
 790         rightnexthop=10.1.1.1
 791         rightsubnet=172.16.1.0/24
 792         auto=add
 793         keyexchange=ike
 794         pfs=no
 795         lifetime=8h
 796         esp=3des-md5-96
 797
 798 ipsec.secrets
 799 -------------
 800 # note I haven't verified that underscores will actually work
 801 10.0.0.1 10.1.1.1: PSK &quot;some_long_secret_with_plenty_of_chars&quot;
 802
 803 Raptor 6.02 (left) information:
 804 ------------------------------
 805 Key Profiles:
 806     Name: left-external-kp-dynamic
 807     Type: Dynamic
 808     Profile Describing: local entity
 809     Gateway: 10.1.1.1
 810     Identification Type: Address
 811     Identification: 10.1.1.1
 812     ISAKMP Hash Method: MD5
 813     ISAKMP Authentication: Shared_Key
 814     Shared Secret: some_long_secret_with_plenty_of_chars
 815     Time Expiration: 1080
 816
 817     Name: right-external-kp-dynamic
 818     Type: Dynamic
 819     Profile Describing: remote entity
 820     Gateway: 10.0.0.1
 821     Identification Type: Address
 822     Identification: 10.0.0.1
 823
 824 Secure Subnets:
 825     Name: left-ss-dynamic
 826     Address: 192.168.0.0
 827     Netmask: 255.255.255.0
 828     Key Profile: left-ss-dynamic
 829
 830     Name: right-ss-dynamic
 831     Address: 172.16.1.0
 832     Netmask: 255.255.255.0
 833     Key Profile: right-ss-dynamic
 834
 835 Secure Tunnel:
 836     Name: left-to-right-tunnel
 837     Entity A: right-ss-dynamic
 838     Entity B: left-ss-dynamic
 839     Encapsulation: ISAKMP
 840     Filter: [none]
 841     Pass traffic through proxies: [unchecked]
 842     Use Authentication Header: [unchecked]
 843     Use Encryption Header: [checked]
 844     Data Integrity Algorithm: MD5
 845     Data Privacy Algorithm: 3DES
 846
 847     [Advanced settings]
 848     Data volume timeout: 2100000
 849     Lifetime timeout: 480
 850     Inactivity timeout: 0
 851     Transport mode: [unchecked]
 852     Perfect forward secrecy: [unchecked]
 853     Proxy: [checked]
 854
 855 ----
 856 Notes:
 857 I made the addresses fictitious RFC1918 addresses.
 858 I haven't tried PFS.
 859 I had problems getting an SA with manual keying -- I think it may be with the
 860  SPI's.
 861 </PRE>
 862 <H4><A name="raptorman">Raptor manual keying</A></H4>
 863  A mailing list suggestion from FreeS/WAN technical lead Henry Spencer:
 864 <PRE>
 865 &gt; In the Raptor settings, there are 2 sets of data (1 for each end). Each set
 866 &gt; contains an SPI, 3 DES Keys and 1 MD5 hash. I only know how to include one
 867 &gt; set, how do I include the other set? Is the other set needed?
 868
 869 They may be using different keys for each direction, which is a bit
 870 unusual for manual keying, but not impossible.  The simplest thing is
 871 probably to just give it two identical sets of data -- that should work.
 872 FreeS/WAN has provisions for asymmetric keys etc. in manual keying, but
 873 that stuff is lightly documented and lightly tested.
 874 </PRE>
 875 <H3><A name="gauntlet">Gauntlet firewall GVPN</A></H3>
 876 <PRE>
 877 Subject:  Successful interop: FreeS/WAN 1.7
 878 <!----->
 879  Gauntlet Firewall GVPN 5.5
 880    Date: Tue, 21 Nov 2000
 881
 882 Sending the following to the list, at Hugh's request.
 883
 884 -----Original Message-----
 885 From: Reiner, Richard
 886 Sent: Tuesday, November 21, 2000 11:34 AM
 887 To: 'hugh@mimosa.com'
 888
 889 Hugh,
 890
 891 &gt; Good.  But we don't think that you should be using our IPCOMP just
 892 &gt; yet.  It is flaky :-(
 893
 894 I've seen no anomalies, although &quot;allow ipcomp&quot; is on at the Gauntlet
 895 end.  Looking at my ipsec.conf I actually find no refereence to ipcomp.
 896  I presume it is disabled by default.  In addition, reviewing my logs
 897 both on the Gauntlet end and the Linux end, I see nothing I can
 898 interpret as an indication that ipcomp was enabled during negotiation.
 899 So I have to correct my previous posting - I believe the link is *not*
 900 using ipcomp.
 901
 902 &gt; This is interesting and we'd love a more complete writeup.  It should
 903 &gt; get incorporated into our interop documentation.
 904
 905 Here are the relevant bits from ipsec.conf:
 906
 907 config setup
 908         interfaces=%defaultroute
 909         klipsdebug=none
 910         plutodebug=none
 911         plutoload=%search
 912         plutostart=%search
 913         uniqueids=yes
 914
 915 conn freeswan17-gauntlet55
 916         auto=start
 917         type=tunnel
 918         left=1.1.1.1
 919         leftnexthop=1.1.1.2
 920         leftsubnet=10.0.1.0/24
 921         right=3.3.3.3
 922         rightnexthop=3.3.3.4
 923         rightsubnet=10.0.2.0/24
 924         authby=secret
 925         keyexchange=ike
 926         ikelifetime=480m
 927         auth=esp
 928         esp=3des-md5-96
 929         keylife=480m
 930         keyingtries=8
 931         pfs=no
 932         rekeymargin=9m
 933         rekeyfuzz=25%
 934
 935 All settings on the Gauntlet side are the same (not shown here, as GUI
 936 screenshots are hard to show in ASCII... and the textual format that is
 937 generated by the Gauntlet GUI is ugly in the extreme).
 938
 939 Note that ikelifetime is 1440m by default on the Gauntlet end, but
 940 freeswan does not support this value (max appears to be 480m), thus the
 941 Gauntlet end is also set to 480m to match freeswan's value.
 942
 943 Also worth noting: I am using the excellent Seawall scripts to manage
 944 ipchains configuration on the freeswan end.  It automatically generates
 945 a correct set of firewall rules for the link (along with doing many
 946 other convenient things).
 947 </PRE>
 948  For more information on Seawall (the Seattle Firewall), see that
 949 project's <A href="http://seawall.sourceforge.net/">home page</A> on
 950 Sourceforge.
 951 <H3><A name="checkpoint">Checkpoint Firewall-1</A></H3>
 952 <P> A PDF <A href="http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/fw-linuxvpn.pdf">
 953 HowTo</A> for connecting FreeS/WAN and this product can be downloaded
 954 from the  vendor's site or browsed at a VPN mailing list <A href="http://kubarb.phsx.ukans.edu/~tbird/vpn.html">
 955 site</A>.</P>
 956 <P> The mailing list reports success with this combination, but also
 957 some problems. Search the <A href="mail.html#archive">archives</A> for
 958 the full story. </P>
 959 <P> Here is one message, about what seems to be the biggest problem: </P>
 960 <PRE>
 961 Subject: Re: Pb establishing connection from FW1/3DES/SP2 with freeswan 1.5 - ACTE 2
 962    Date: Tue, 6 Feb 2001
 963    From: Claudia Schmeing &lt;claudia@freeswan.org&gt;
 964
 965 &gt; Thanx to Michael and Claudia, but this doesn't work from VPN1 to linux (as
 966 &gt; linux to VPN1 is OK).
 967 ...
 968
 969 &gt; I think that VPN1 doesn't send &quot;192.168.1.0/24&quot; but &quot;192.168.1.20/32&quot; and,
 970 &gt; as Claudia said, IPSEC SA need to match Exactly.
 971
 972 I don't know about the rules on the VPN-1. You'll have to rely on people
 973 with applicable experience there...
 974
 975 &gt; Is it possible that freeswan doesn't do the inclusion process (ie if he
 976 &gt; receive 192.168.1.20/32, i doesn't match that this is include in
 977 &gt; 192.168.1.0/24) ?
 978
 979 Yes, that's correct. It needs to match exactly, and inclusion is not
 980 part of this process.
 981
 982 &gt; Btw why VPN/1 send 192.168.1.20/32 and not 192.168.1.20/24 (the value that
 983 &gt; Freeswan is waiting for)? A bug?
 984
 985 I think Michael may be able to help you with this.
 986
 987 &gt; Have i a way to force Freeswan to do the &quot;inclusion&quot; (ie accept
 988 &gt; 192.168.1.20/32 as a part of 192.160.1.20/24, even if the 2 IPSEC Sa
 989 &gt; doesn't match exactly) ?
 990
 991 No, but...
 992 Another strategy is to accept the fact that the Checkpoint
 993 proposes separate connections for each machine. If you define
 994 and add each of these connections on the Linux FreeS/WAN side, then
 995 Linux FreeS/WAN ought to accept the Checkpoint's proposals.
 996
 997 The only possible difficulty with this strategy is that I don't know
 998 how Linux FreeS/WAN handles the concept of overlapping tunnels. I
 999 believe, though, that these tunnels can coexist, and if for any
1000 packet there are two options, a more general and a less general, the
1001 packet will be handled by the more specific tunnel. You would need
1002 to do a little testing to ensure you understand the behaviour and
1003 that this does actually solve your problem.
1004
1005 I think it would be simplest to try to get the Checkpoint to propose the
1006 more general tunnel. Since I don't recall having seen this problem before,
1007 I suspect the simpler solution is doable.
1008 </PRE>
1009 <H3><A name="redcreek">Redcreek Ravlin</A></H3>
1010  We have reports of successful interoperation at an interop <A href="http://www.opus1.com/vpn/atl99display.html">
1011 conference</A>, but there is also a mailing list <A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00510.html">
1012  thread</A> discussing difficulties some users have encountered.
1013 <H3><A name="sentinel">SSH Sentinel</A></H3>
1014  The vendor's <A href="http://www.ipsec.com/products/sentinel/documents.html">
1015  web site</A> has configuration examples for use with FreeS/WAN.
1016 <P> The vendor seems serious about interop with us. Here is a message
1017 one of their staff posted on our list: </P>
1018 <PRE>
1019 From: Jussi Torhonen &lt;jt@ssh.com&gt;
1020 Organization: SSH Communications Security Corp - http://www.ssh.com
1021 Subject: [Users] SSH Sentinel VPN client public beta #3 now available
1022 Date: Thu, 31 May 2001
1023
1024 Hello, FreeS/WAN community !
1025
1026 SSH Communications Security Corp has released a new public beta #3
1027 version of SSH Sentinel VPN client for Windows. We've got a lot of
1028 reports also from FreeS/WAN community and with that feedback we've
1029 improved interoperability and stability.
1030
1031 For example PFS (Perfect Forward Secrecy in IKE rekey) can now be used
1032 between SSH Sentinel and FreeSWAN, and if using that user contributed
1033 X.509 patch and exporting the certificate from SSH Sentinel, now those
1034 -----[BEGIN|END] CERTIFICATE----- headers/footers are properly included
1035 in the exported PEM formatted certificate, so it can be imported to
1036 FreeSWAN with fswcert utility and OpenSSL tools.
1037
1038 Thank you a lot for your feedback, colleagues !
1039
1040 You can get that new public beta #3 and PDF formatted User Manual from
1041 ftp://ftp.ssh.com/pub/sentinel/ or via website
1042 http://www.ipsec.com/products/sentinel/beta/register.html
1043
1044 For more information about the product, please check our website
1045 http://www.ipsec.com
1046
1047 We eagerly want to make SSH Sentinel as the best VPN client on the
1048 market. If you want to contact our support, please send e-mail to
1049 sentinel-support@ssh.com or fill up our feedback form at
1050 http://www.ipsec.com/support/sentinel/beta_report.html
1051
1052 Best regards,
1053 Jussi Torhonen, SSH Sentinel Team
1054 Kuopio, Finland
1055 </PRE>
1056 <H3><A name="Fsecure">F-Secure VPN for Windows</A></H3>
1057 <PRE>   Subject: linux-ipsec: Identification through other than IP number
1058    Date: Tue, 13 Apr 1999
1059    From: Thomas Bellman &lt;bellman@signum.se&gt;
1060
1061 ... Currently we are trying to interop FreeS/WAN
1062 with F-Secure VPN+ Client 4.0 (for MS Windows), and as long as
1063 the Windows machine has a fix IP address, and are initiating the
1064 IKE negotiations, things are working well.  However, when the IP
1065 address is changing, it doesn't work. ...
1066 (I'll try to write something up about the problems we are having
1067 when Pluto is initiatior in another message.)
1068 </PRE>
1069 <H3><A name="watchguard">Watchguard</A></H3>
1070 <P> Watchguard make a Linux-based firewall product. Ipchains author
1071 Rusty Russell thanks them for support and recommends them in one of his <A
1072 href="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-3.html#ss3.2">HowTos</A>
1073 . On the other hand, some comments on our mailing list about the
1074 Watchguard product have been quite unfavourable. See, for example, this <A
1075 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/08/msg00474.html">
1076 archive message</A>. </P>
1077 <P> Watchguard do not use FreeS/WAN in their product. They have their
1078 own IPSEC implementation. </P>
1079 <P> We have had mailing list reports of successful interoperation
1080 between FreeS/WAN and the Watchguard firewall, using manually keyed
1081 connections. The user could not get automatically keyed connections to
1082 work; the message below explains this. </P>
1083 <P> Here is some mail from a Watchguard employee about interoperation: </P>
1084 <PRE>
1085 Subject: FreeS/WAN and WatchGuard Firebox interop
1086    Date: Mon, 18 Dec 2000
1087    From: Max Enders &lt;menders@watchguard.com&gt;
1088
1089 I was recently given the task of testing IPSec interoperability
1090 with our product, the Firebox. I just wanted to let you know that
1091 I had success with a manual keyed tunnel. Here's what I used for
1092 my test:
1093
1094 RedHat Linux 6.2
1095 Linux 2.2.18 i686 unknown
1096 Linux FreeS/WAN 1.8
1097 &quot;Trusted&quot; interface: 192.168.0.1/24
1098 &quot;External&quot; interface: 192.168.1.1/24
1099
1100 Firebox II FastVPN
1101 WatchGuard Live Security System v4.5
1102 Trusted interface: 192.168.2.1/24
1103 External interface: 192.168.1.2/24
1104
1105 Because FreeS/WAN does not implement single DES, a dynamic keyed
1106 tunnel will not work. Our product strictly uses DES for main mode.
1107 We hope to address this in a future release. Here are instructions
1108 for configuring the Firebox:
1109
1110 Open the Policy Manager and create a new IPSec gateway. Set the Key
1111 Negotiation Type to manual and enter the FreeS/WAN box's external
1112 IP address for the Remote Gateway IP. Configure a new tunnel with
1113 a unique SPI. Select 3DES-CBC for Encryption and MD5-HMAC for
1114 Authentication. Make an Encryption Key and Authentication Key.
1115 Copy the values and save them for configuration of the FreeS/WAN box.
1116 Configure a routing policy and any necessary services as you normally
1117 would.
1118
1119 Here's how I configured FreeS/WAN:
1120
1121 Modifications to /etc/ipsec.conf:
1122
1123 Under the &quot;config setup&quot; section, add:
1124
1125 manualstart=firebox
1126
1127 At the end of the file, add the following connection:
1128
1129 conn firebox
1130 left=192.168.1.1
1131 leftsubnet=192.168.0.0/24
1132 right=192.168.1.2
1133 rightsubnet=192.168.2.0/24
1134 spi=0x101
1135 esp=3des-md5-96
1136 espenckey=0x515b0875793e3708517c3d4554012f7c0273375e51572a31
1137 espauthkey=0x072649041c2c0d452f7c15407576522f
1138
1139 The spi used here should match the Firebox's. Note that the Policy Manager
1140 expects an SPI in decimal, not hexadecimal. The espenckey value should be
1141 0x and the Encryption Key you're using on the Firebox. Likewise for
1142 espauthkey and the Authentication Key on the Firebox.
1143 </PRE>
1144  A user comments:
1145 <PRE>
1146 Subject: RE: Freeswan
1147    Date: Wed, 7 Feb 2001
1148    From: &quot;Patrick Poncet&quot; &lt;pponcet@vaxxine.com&gt;
1149
1150 It's working!!!
1151
1152 Voila...  I wish to thank all the FreeS/WAN for putting out such a great
1153 product out!  And also Philippe PAULEAU who pioneered interoperability
1154 between FreeS/WAN and Watchguard Firebox II and therefore showed me that my
1155 efforts would not be wasted!...
1156
1157 Yes indeed FreeS/WAN to WatchGuard Firebox only works in manual keying mode
1158 and the best way to generate keys is to have the firebox generate the keys,
1159 then copy and paste into the ipsec.conf file on the FreeS/WAN side (don't
1160 forget to prefix the keys with '0x' in your ipsec.conf file.
1161
1162 Also keep in mind that the SPI is in decimal on the Firebox side and HEX on
1163 the FreeS/WAN side!!!  We spent 4 hours on fixing this HEX-DEC issue only :)
1164 </PRE>
1165 <H3><A name="Xedia">Xedia Access Point/QVPN</A></H3>
1166 <PRE>   Subject: linux-ipsec: Interoperability result
1167    Date: Mon, 15 Mar 1999 18:08:12 -0500
1168   From: Paul Koning &lt;pkoning@xedia.com&gt;
1169
1170 Here's another datapoint for the &quot;FreeS/WAN interoperability
1171 database&quot;.
1172
1173 I tested 0.92 against the Xedia Access Point/QVPN product, using
1174 dynamic keying (i.e., Pluto at work).
1175
1176 Results: it works fine so long as you ask for 3DES.  DES and no-crypto
1177 modes don't work when Pluto is involved.
1178
1179 I did limited data testing, which seemed to be fine.  No performance
1180 numbers yet, could do that if people are interested.
1181
1182 Any questions, please ask.
1183
1184         paul
1185 </PRE>
1186 <H3><A name="pgpnet">PGP Mac and Windows IPSEC Client</A></H3>
1187 <P> Since version 6.5, the <A href="glossary.html#PGP">PGP</A> products
1188 from <A href="http://www.pgp.com/">PGP Inc.</A> have included an IPSEC
1189 client program.</P>
1190 <P> Here is the first message about it to our mailing list, from a
1191 senior PGP employee:</P>
1192 <PRE>   Subject: linux-ipsec: PGPnet interoperable with FreeSWAN
1193    Date: Mon, 05 Apr 1999 18:06:13 -0700
1194    From: Will Price &lt;wprice@cyphers.net&gt;
1195     To:  linux-ipsec@clinet.fi
1196
1197 Network Associates announced PGP 6.5 today.  It includes a new product
1198 PGPnet which is a full IKE/IPSec client implementation.  This product
1199 is for Windows and Macintosh.  I just wanted to send a brief note to
1200 this list that the product was compatibility tested with FreeSWAN
1201 prior to its release, and the tests were successful!
1202 [snip]
1203 - --
1204 Will Price, Architect/Sr. Mgr., PGP Client Products
1205 Total Network Security Division
1206 Network Associates, Inc.</PRE>
1207 <P> One version is downloadable at no cost for non-commercial use. See
1208 our <A href="web.html#tools">links</A>. That version does not support
1209 subnets. </P>
1210 <P> Several of the user-written HowTos mentioned <A href="#otherpub">
1211 above</A> cover interoperation between PGPnet and FreeS/WAN.</P>
1212 <P> A more recent post from the same PGP Inc staff member pointed out: </P>
1213 <PRE>
1214 Make sure you're using PGP 7.0 or later as the key parser was improved
1215 in that release.  (PGP 7.0.1 was just released)
1216 </PRE>
1217 <P> Various users have reported various successes and problems talking
1218 to PGPnet with FreeS/WAN. There has also been a fairly complex
1219 discussion of some fine points of RFC interpretation between the
1220 implementers of the two systems. Check an archive of our <A href="mail.html">
1221 mailing list</A> for details.</P>
1222 <P> A post summarising some of this, from our Pluto programmer:</P>
1223 <PRE>
1224    Subject: PGPnet 6.5 and freeswan
1225    Date: Sun, 16 Jan 2000
1226    From: &quot;D. Hugh Redelmeier&quot; &lt;hugh@mimosa.com&gt;
1227
1228 | From: Yan Seiner
1229 |
1230 | OK, I'm stumped.  I am trying to configure IPSEC to support road
1231 | warriors using PGPnet 6.5.
1232 |
1233 | I've set up everything as per the man pages on the ipsec side.
1234 |
1235 | I've set up everything on the PGPnet side per the docs for that package.
1236 |
1237 | Pluto fails with this:
1238 |
1239 | Jan 16 08:14:11 aphrodite Pluto[26401]: &quot;homeusers&quot; #8: no acceptable
1240 | Oakley Transform
1241 |
1242 | and then it terminates the connection.
1243
1244 As far as I can tell/remember, there are three common ways that PGPnet
1245 and FreeS/WAN don't get along.
1246
1247 1. PGPnet proposes a longer lifetime for an SA than Pluto is willing
1248    to accept.
1249
1250 2. After rekeying (i.e. after building a new SA bundle because the old
1251    one is about to expire), FreeS/WAN immediately switches to the new
1252    one while PGPnet continues using the old
1253
1254 3. FreeS/WAN defaults to expecting Perfect Forward Secrecy and PGPnet
1255    does not.
1256
1257 Perhaps you are bumping into the first.  In any case, look back
1258 in the log to see why Pluto rejected each transform
1259 </PRE>
1260 <P> Some advice from the mailing list:</P>
1261 <PRE>
1262    Subject: Re: Secure Gate Fails- PGPNet &amp; FreeSwan
1263    Date: Wed, 28 Jun 2000
1264    From: Andreas Haumer &lt;andreas@xss.co.at&gt;
1265
1266 I have a PGPnet setup running with FreeS/WAN working as secure
1267 gateway. It works quite fine, except for a re-negotiation problem
1268 I'm currently investigating, and in fact I have it running on some
1269 test equipment here right now!
1270
1271 As I tried _several_ different non-working configuration settings
1272 I think I know the exact _one_ which works... :-)
1273
1274 Here's my short &quot;HOWTO&quot;:
1275
1276 FreeS/WAN version: snap1000jun25b
1277 PGPnet: PGP Personal Privacy, Version 6.5.3
1278 Linux: 2.2.16 with some patches
1279
1280 Network setup:
1281 =============
1282
1283 internal subnet [192.168.x.0/24]
1284 |
1285 |        [192.168.x.1]
1286 secure gateway with FreeS/WAN
1287 |        [a.b.c.x]
1288 |
1289 |        [a.b.c.y]
1290 router to internet
1291 |
1292 |   Internet
1293 |
1294 |        [dynamically assigned IP address]
1295 road-warrior with PGPnet
1296
1297
1298 Configuration of FreeS/WAN:
1299 ==========================
1300
1301 a) /etc/ipsec.conf
1302
1303 config setup
1304         interfaces=%defaultroute
1305         klipsdebug=none
1306         plutodebug=none
1307         plutoload=%search
1308         plutostart=%search
1309
1310 conn %default
1311         keyingtries=1
1312         authby=secret
1313         left=a.b.c.x
1314         leftnexthop=a.b.c.y
1315
1316 conn gw-rw
1317         right=0.0.0.0
1318         auto=add
1319
1320 conn subnet-rw
1321         leftsubnet=192.168.x.0/24
1322         right=0.0.0.0
1323         auto=add
1324
1325
1326 b) /etc/ipsec.secrets
1327
1328 a.b.c.x 0.0.0.0: &quot;my very secret secret&quot;
1329
1330
1331 Note: If you are running ipchains on your secure gateway,
1332 you have to open the firewall for all the IPsec packets
1333 and also for traffic from your ipsec interface!
1334 Don't masquerade the IPsec traffic!
1335
1336 Check your logfiles if the firewall is blocking some
1337 important packets!
1338
1339
1340 Configuration of PGPnet:
1341 =======================
1342
1343 (note that there is an excellent description, including
1344 screenshots of PGPnet, on &lt;http://jixen.tripod.com/&gt;)
1345
1346 In short, do the following:
1347
1348 Launch the PGPnet configuration tool and set defaults options
1349 =============================================================
1350
1351 Start - Program - PGP - PGPnet
1352 View - Options
1353 General Panel :
1354   Expert Mode
1355   Allow communications with unconfigured hosts
1356   Require valid authentication key
1357   Cache passphrases between logins
1358   IKE Duration : 6h
1359   IPsec : 6h
1360 Advanced panel :
1361   Selected options :
1362     Ciphers : Tripple DES
1363     Hashes : MD5
1364     Diffie-Hellman : 1024 and 1536
1365     Compression : LZS and Deflate
1366   Make the IKE proposal :
1367     Shared-Key - MD5 - 3DES -1024 bits on top of the list (move up)
1368   Make the IPSec proposal :
1369     NONE - MD5-TrippleDES -NONE on top of the list (move up)
1370   Select Perfect Forward Secrecy = 1024 bits
1371 Press OK
1372
1373
1374 Create the connection's definition.
1375 ==================================
1376
1377 In the Hosts panel, ADD
1378   Name : Enter a name for the right gateway
1379   IPaddress : Enter its IP address visible to the internet (a.b.c.x)
1380   Select Secure Gateway
1381   Set shared Paraphrase : enter you preshared key
1382   Identity type : select IP address
1383   Identity : enter 0.0.0.0
1384   Remote Authentication : select Any valid key
1385 Press Ok
1386   Select the newly created entry for the right gateway and click ADD,
1387 YES
1388   Name : Enter a name for the central subnet
1389   IP address : Enter its network IP address (192.168.x.0)
1390   Select Insecure Subnet
1391   Subnet Mask : enter its subnetmask (255.255.255.0)
1392 Press OK, YES, YES
1393
1394
1395 This should be it. Note that with this configuration there is
1396 still this re-keying problem: after 6 hours, the SA is expired
1397 and the connection fails. You have to re-connect your connection
1398 with PGPnet.</PRE>
1399 <P>and a note from the team's tech support person:</P>
1400 <PRE>Date: Thu, 29 Jun 2000
1401 From: Claudia Schmeing
1402
1403 There is a known issue with PGPNet which I don't see mentioned in the docs.
1404 It's likely related to this one, that you note on the site:
1405
1406 &gt;2. After rekeying (i.e. after building a new SA bundle because the old
1407 &gt;   one is about to expire), FreeS/WAN immediately switches to the new
1408 &gt;   one while PGPnet continues using the old
1409
1410 The issue is: When taking down and subsequently recreating a connection,
1411 it can appear to come up, but it is unusable because PGPNet continues
1412 to use an old SA, which Linux FreeS/WAN no longer recognizes. The solution is
1413 to take down the old connection using PGPNet, so that it will then
1414 use the most recently generated SA.</PRE>
1415 <H3><A name="IRE">IRE Safenet/SoftPK</A></H3>
1416 <P> IRE have an extensive line of IPSEC products, including firewall
1417 software with IPSEC, and hardware encryption devices for LAN or modem
1418 links. Their  Soft-PK is a Win 98 and NT client.</P>
1419 <P> Quite a few people seem to be using this with FreeS/WAN and,
1420 judging by mailing list reports, to be getting good results.  Several
1421 documents are available: </P>
1422 <UL>
1423 <LI><A href="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">
1424  PDF HowTo</A> titled <CITE>FreeS/WAN 1.8 &lt;--&gt; IRE Safenet SoftPK 5.1.0
1425 Road-Warrior VPN Configuration Guide</CITE> from Terradon
1426 Communications. </LI>
1427 <LI><A href="http://www.redbaronconsulting.com/freeswan/fswansafenet.pdf">
1428  PDF document</A> from Red Baron Consulting. </LI>
1429 <LI><A href="http://jixen.tripod.com/#Rw-IRE-to-Fwan"> IRE-to-FreeS/WAN
1430 section</A> of  Jean-Francois Nadeau's configuration document </LI>
1431 </UL>
1432 <P>Some messages from the mailing list:</P>
1433 <PRE>
1434 Subject: Re: Identification through other than IP number
1435 Date:  Fri, 23 Apr 1999
1436 From:  Tim Miller &lt;cerebus+counterpane@haybaler.sackheads.org&gt;
1437
1438 Randy Dees writes:
1439
1440  &gt; Anyone know of a low-cost MS-Win client that interoperates and does not
1441  &gt; require purchasing a server license to get it?
1442
1443         SafeNet/Soft-PK from IRE (http://www.ire.com) is a low-cost
1444 client (though I don't have the exact cost available at the moment).
1445 I've got it running on an NT4 workstation and it interoperates nicely
1446 (in transport mode, will try tunnel later) with FreeS/WAN.  It's also
1447 ICSA IPsec certified.
1448 </PRE>
1449  A later report from a different user:
1450 <PRE>
1451 Subject: Interop.. testing. WIN32 client : Success Story
1452 Date: Thu, 11 Nov 1999
1453 From: Jean-Francois Nadeau &lt;jna@microflex.ca&gt;
1454
1455 You can add IRE's products in the supported, well working (and cheap)
1456 WIN32 client. I tested it (SafeNet SoftPK 3DES) against Freeswan 1.0
1457 and 1.1 in both tunnel and transport mode in a RoadWarrior configuration.  No bug.
1458
1459 The software is light, non-intrusive and transparent for the user.....defenitly,
1460 thats a good one.
1461
1462 The tunnel is establish on demand.
1463
1464 Using shared keys....but hope to use certificates with it soon (well,
1465 when Freeswan will ;)).
1466 </PRE>
1467  A recent report with some setup details:
1468 <PRE>
1469 Subject: RE: linux-ipsec: PGPnet and Freeswan one more time...
1470    Date: Sat, 16 Dec 2000
1471   From: &quot;Tim Wilson&quot; &lt;timwilson@mediaone.net&gt;
1472
1473 Here are some details about using the IRE SafeNet Soft/PK client with a
1474 FreeSwan gateway.
1475
1476 I applied the x509 patch to Pluto according to the instructions. I use the
1477 &quot;leftcert&quot; and &quot;rightcert&quot; keywords in the ipsec.conf file. This causes
1478 FreeSwan to read the public keys and identities from the cert files. The
1479 identities wanted and used by FreeSwan will then be the DNs in the certs.
1480
1481 I used OpenSSL to generate keys and certs and to sign certs. When generating
1482 the gateway cert, you should *not* enter an e-mail address because it turns
1483 out that confuses Soft/PK. Also, Andreas Steffan tells me that you want to
1484 keep the cert short to avoid fragmentation, so use a 1024-bit RSA key and
1485 succinct names.
1486
1487 The FreeSwan gateway cert goes in /etc/ipsec.d/, the gateway private key is
1488 extracted from the key file using fswcert (part of the x509 patch) and
1489 pasted into /etc/ipsec.secrets, and a DER version of the gateway cert goes
1490 in /etc/x509cert.der. This is all according to the instructions that
1491 accompany the x509 patch.
1492
1493 The Windows client is of course running Soft/PK in this case. I generated a
1494 private key and cert for the client on the Linux machine using OpenSSL. I
1495 created a pkcs12 file containing the client's private key and cert, which I
1496 put on a floppy and imported into Soft/PK. I also imported the gateway cert
1497 into Soft/PK (you can either import a self-signed cert for the gateway or
1498 the self-signed cert for the CA that signed the gateway cert--either works).
1499
1500 Soft/PK allows you to configure practically everything for the connection.
1501 Here are the main points to watch for:
1502
1503 On the first panel you have to set the peer identities. The gateway will
1504 identify itself using the DN in the gateway cert. So of course you have to
1505 configure Soft/PK to look for the correct DN. There's no problem with this
1506 as long as you didn't enter an e-mail address in the gateway cert. Just
1507 check &quot;Connect using Secure Gateway tunnel&quot;, set ID type to &quot;Distinguished
1508 Name&quot;, and enter the correct info in the dialog box.
1509
1510 In &quot;My identity&quot; just select the client cert that you imported in pcks12
1511 format. Soft/PK apparently identifies itself with the DN from the cert,
1512 which is exactly what FreeSwan is looking for.
1513
1514 In &quot;Security Policy&quot;, you want Main mode and make the PFS setting agree with
1515 whatever FreeSwan is doing (FreeSwan uses PFS by default). If you use PFS I
1516 believe you must use DH group 2 as FreeSwan doesn't like group 1.
1517
1518 Phase 1 Authentication must be &quot;RSA signatures&quot; and 3DES plus either MD5 or
1519 SHA-1 (I used MD5 but I believe FreeSwan accepts either). I left the
1520 lifetime unspecified. Also you must select DH group 2 because I believe that
1521 FreeSwan will not accept group 1.
1522
1523 Phase 2 also must use 3DES and MD5 or SHA-1. I used no compression and only
1524 ESP and no AH, haven't tried other choices.
1525
1526 Hope this helps.
1527 </PRE>
1528 <H3><A name="borderware">Borderware</A></H3>
1529 <H3><A name="freegate">Freegate</A></H3>
1530 <PRE>Subject: ipsec interoperability FYI
1531    Date: Sun, 02 May 1999
1532    From: Sean Rooney &lt;sean@coldstream.ca&gt;
1533
1534 we've been doing some basic interoperability testing of the following;
1535
1536 PGP NT VPN 6.5 and freeswan both seem to work reasonably well with
1537 Borderware 6.0 and freegate 1.3 beta. [as well as eachother]
1538
1539 more details coming soon.</PRE>
1540 <H3><A name="timestep">Timestep</A></H3>
1541 <PRE>
1542    Subject: TimeStep Permit/Gate interop works!
1543    Date: Thu, 10 Jun 1999
1544    From: Derick Cassidy &lt;dcthebrain@geek.com&gt;
1545
1546 Just a quick note of success.  TimeStep Permit/Gate (2520) and
1547 Free/Swan (June 4th snapshot) interoperate!
1548
1549 I have them working in AUTO mode, with IKE.  IPSec SA's are negotiated
1550 with 3DES and MD5.
1551
1552 Here are the configs and a diagram for both configs.
1553
1554 left subnet---| Timestep | --- internet --- | Linux box |
1555
1556 The left subnet is defined as the red side of the timestep box.
1557  This network definition MUST exist in the Secure Map.
1558
1559 On the Linux box:
1560
1561 ipsec.conf
1562
1563 conn timestep
1564         type=tunnel
1565         left=209.yyy.xxx.6
1566         leftnexthop=209.yyy.xxx.1
1567         leftsubnet=209.yyy.xxx.128/25
1568         right=24.aaa.bbb.203
1569         rightnexthop=24.aaa.bbb.1
1570         rightsubnet=24.aaa.bbb.203/32
1571         keyexchange=ike
1572         keylife=8h
1573         keyingtries=0
1574
1575 In the TimeStep permit/gate Secure Map
1576
1577 begin static-map
1578         target &quot;209.yyy.xxx.128/255.255.255.128&quot;
1579         mode   &quot;ISAKMP-Shared&quot;
1580         tunnel &quot;209.yyy.xxx.6&quot;
1581 end
1582
1583 In the TimeStep Security Descriptor file
1584
1585 begin security-descriptor
1586         Name    &quot;High&quot;
1587         IPSec   &quot;ESP 3DES MINUTES 300 or ESP 3DES HMAC MD5 MINUTES 300&quot;
1588         ISAKMP  &quot;IDENTITY PFS 3DES MD5 MINUTES 1440
1589                                 or DES MD5 MINUTES 1440&quot;
1590 end
1591
1592 The timestep has a shared secret for 24.aaa.bbb.203/255.255.255.255
1593 set in the Shared Secret Authentication tab of Permit/Config.</PRE>
1594 <H3><A name="shiva">Shiva/Intel LANrover</A></H3>
1595 <P>A <A href="http://snowcrash.tdyc.com/freeswan/">web page</A> with
1596 Shiva  compatibility information.</P>
1597 <H3><A name="solaris">Sun Solaris</A></H3>
1598 <PRE>   Subject: Re: FreeS/WAN and Solaris
1599    Date: Tue, 11 Jan 2000
1600    From: Peter Onion &lt;Peter.Onion@btinternet.com&gt;
1601
1602 Slowaris 8 has a native (in kernel) IPSEC implementation.
1603
1604 I've not done much interop testing yet, but I seem to rememeber we got a manual
1605 keyed connection between it and FreeSwan a few months ago.</PRE>
1606 <H3><A name="sonicwall">Sonicwall</A></H3>
1607 <PRE>
1608 Subject: Re: FreeS/WAN and SonicWall
1609      Date: Mon, 5 Feb 2001
1610      From: &quot;Dilan Arumainathan&quot; &lt;dilan_a@impark.com&gt;
1611
1612 ***************************************************
1613 I know I HAVE TO write the mini-howto - but here is the beginning
1614 ***************************************************
1615
1616 Here is my Sonicwall configuration for my working connection:
1617
1618 conn testauto
1619         left=x.x.x.x
1620         leftnexthop=x.x.x.x
1621         right=y.y.y.y
1622         rightnexthop=y.y.y.y
1623         rightsubnet=10.1.20.0/24
1624 #You need to set the Unique Firewall Identifier to the parameter that you
1625 #use as the rightid.
1626 <!--------IMPORTANT
1627         rightid=sw@sonicwall.com
1628         authby=secret
1629         auth=esp
1630         esp=3des-hmac-md5
1631         ikelifetime=6h
1632         keylife=5h
1633
1634 Your /etc/ipsec.secrets should be like this:
1635 x.x.x.x y.y.y.y sw@sonicwall.com : PSK "opensesame"
1636
1637 On the Sonicwall create a new connection:
1638
1639 Name: testauto
1640 IPSec Gateway address: 0.0.0.0
1641 SA life time: 18000
1642 Encryption Method: Strong Encrypt and Authenticate( EPS 3DES HMAC MD5)
1643 Shared Secret: opensesame
1644 </pre-->
1645
1646
1647 </PRE>
1648 <H3><A name="radguard">Radguard</A></H3>
1649  Here are some mailing list comments from FreeS/WAN tech support person
1650 Claudia Schmeing on this:
1651 <PRE>
1652 It certainly has been possible to interop between Radguard VPN gateways and
1653 past Linux FreeS/WAN versions, as is evidenced by
1654 http://www.opus1.com/vpn/atl99display.html, as well as my own interop results
1655 from San Diego this year. There have been no major changes since SD that
1656 I would foresee affecting this.
1657
1658 The Radguard team said that their VPN gateway will not respond to a peer
1659 request with PFS (Perfect Forward Secrecy) on, but it *will* successfully
1660 establish such a connection with Linux FreeS/WAN when Radguard is the
1661 initiator. Since PFS is a desirable feature in terms of cryptographic
1662 security, this asymmetry may frustrate efforts to provide a connection that
1663 is both as reliable as secure as possible.
1664
1665 While it's not clear that rekeying will present a problem, I suspect that
1666 some fine tuning of the key life parameters may be needed. Unfortunately
1667 I was unable to do additional tests on this topic.
1668
1669 Due to the PFS issue, when trying to maintain a connection with PFS,
1670 you may need to set the rekeying times shorter on the radguard side,
1671 in order to ensure that it is always the initiator.
1672 </PRE>
1673 <H3><A name="winclient">Windows clients</A></H3>
1674 <P> Quite a number of client programs for IPSEC on Windows are
1675 available. Many of them are listed in this piece of list mail:</P>
1676 <PRE>
1677  Subject: Re: Searching Windows95/98 and NT4.0 Clients for FreeS/WAN
1678     From: Claudia Schmeing &lt;claudia@coldstream.ca&gt;
1679     Date: Wed, 12 Jul 2000
1680
1681 F-Secure VPN+
1682 -------------
1683 for Win 95, 98 and NT 4.0
1684 http://www.datafellows.com/products/vpnplus
1685
1686
1687 Checkpoint SecureRemote VPN-1 4.1
1688 ---------------------------------
1689 for Win 95, 98 and NT
1690 http://www.checkpoint.com/techsupport/freedownloads.html
1691
1692
1693 Raptor Firewall, Raptor MobileNT 5.0
1694 -------------------------------------
1695 Mobile NT is a &quot;Client&quot;* for Win 95, 98 (except SE), First Edition Windows NT
1696 up to Service Pack 4. It ships with DES; triple DES may be available as an
1697 add-on depending on your location.
1698
1699 Firewall is for Win NT 4.0 or Win 2000.
1700 http://www.axent.com
1701
1702
1703 IRE SafeNet SoftPK
1704 ------------------
1705 a &quot;Client&quot; for Win 95, 98 and NT 4.0 *
1706 http://www.ire.com
1707
1708
1709 Xedia's AccessPoint QVPN &quot;Client&quot; or &quot;Builder&quot;
1710 ----------------------------------------------
1711 &quot;Builder&quot; is for NT
1712 &quot;Client&quot; is for Win 98 *
1713 http://www.xedia.com
1714
1715 * &quot;Client&quot; in this context indicates software that does not support a subnet
1716 behind its end of the connection.
1717 </PRE>
1718 <P> That mail omits the <A href="#pgpnet">PGPnet client</A> because the
1719 user asking the question already knew of it. The <A href="#sentinel">
1720 SSH Sentinel</A> client, released since the above message, is another
1721 possibility. Both of those have members of the vendor's staff active on
1722 our mailing list, an excellent sign for both interoperability and
1723 support.</P>
1724 <P> We also know of some Windows IPSEC clients not mentioned above: </P>
1725 <UL>
1726 <LI><A href="http://www.lucent.com/ins/products/ipsec/">Lucent</A></LI>
1727 <LI><A href="http://www.ashleylaurent.com/">Ashleylaurent</A></LI>
1728 </UL>
1729 <P> No doubt there are others we don't know of. </P>
1730 <H3><A name="NTdomain">NT domains vs. tunnels</A></H3>
1731  There has been some mailing list discussion of making NT domains work
1732 across FreeS/WAN tunnels.
1733 <P> Robert Cotran asked: </P>
1734 <PRE>
1735 &gt; I have a VPN setup between two subnets (192.168.1.x and 192.168.2.x).  I
1736 &gt; would like to be able to join the NT domain on 192.168.1.x from the
1737 &gt; 192.168.2.x subnet.  Is this possible?  Do I have to forward specific ports
1738 &gt; to do this?  I've already set up WINS entries for all the machines, so
1739 &gt; accessing computers by their NetBIOS names works perfectly.  Please let me
1740 &gt; know about this domain thing.  Thanks!
1741 </PRE>
1742  Dilan Arumainathan answered:
1743 <PRE>
1744 All you need to do is to:
1745
1746 1. Enable NetBIOS over TCP.
1747 2. Create a &quot;lmhosts&quot; file and enter the address of a BDC or a PDC like
1748     192.168.1.[x]  [Your PDC/BDC servername] #PRE #DOM:[Your Domain Name]
1749     eg. 192.168.1.1 MYOWNPDC #PRE #DOM:DENSI-NT
1750
1751 3. Reboot if necessary.
1752 </PRE>
1753  and Sebastien Pfieffer provided a slightly different answer:
1754 <PRE>
1755 For a trust relationship to work between NT domains in different
1756 (sub)nets all domain controllers of the 1st domain have to know about
1757 all controllers of the other domain.
1758 Either you use the described LMHOSTS entry for every domain controller
1759 of both domains or consider setting up WINS service(s).
1760 </PRE>
1761  We suspect that in some cases it may be more complex than that. See
1762 the discussion of <A href="#lin2k">Linux services and Windows 2000</A>
1763  below and the <A href="#otherpub">Interop HowTo</A> documents listed
1764 above.
1765 <H3><A name="win2k">Windows 2000</A></H3>
1766 <P> Windows 2000 ships with an IPSEC implementation built in. There may
1767 be  restrictions. We have had mailing list reports that only the server
1768 version  will act as a gateway, working with a subnet behind it, and
1769 other versions  offer only &quot;client&quot; functionality, with no subnet. We
1770 are unclear on  details.</P>
1771 <P>Some versions of Windows 2000 ship with only weak encryption. You
1772 need to  upgrade them with the strong encryption pack, available either
1773 via the  Windows 2000 update service or from Microsoft's web site.</P>
1774 <P>Windows 2000 IPSEC sometimes exhibits remarkably odd behaviour. It
1775 will  allow you to configure it for 3DES only, then ignore your
1776 settings and fall  back to single DES in some circumstances. Microsoft
1777 have said they will fix  this. See this <A href="http://www.wired.com/news/technology/0,1282,36336,00.html">
1778 Wired  article</A>.</P>
1779 <H4><A name="lin2k">Other Linux services related to Win 2000</A></H4>
1780 <P> Windows 2000 also uses a number of other security mechanisms which
1781 have Linux equivalents. To integrate well with Windows 2000, you may
1782 need to look at several open source projects other than FreeS/WAN:</P>
1783 <UL>
1784 <LI>Windows 2000 builds L2TP tunnels over (some of?) its IPSEC
1785  connections. There is a Linux <A href="http://www.marko.net/l2tp/">
1786 L2TP  Daemon</A>.</LI>
1787 <LI>Kerberos authentication is used in Windows 2000.
1788 <UL>
1789 <LI><A href="http://web.mit.edu/network/kerberos-form.html">MIT
1790  Kerberos site</A></LI>
1791 <LI><A href="http://consult.stanford.edu/afsinfo/kerberos.shtml">
1792 introductory  document</A></LI>
1793 <LI>Kerberos <A href="http://alycia.dementia.org/kerberos.html"> links
1794  page</A></LI>
1795 </UL>
1796 </LI>
1797 <P> The Windows 2000 Kerberos implementation includes proprietary
1798 modifications. This is a security worry since it is by no means clear
1799 that the modified version remains  secure. It also creates
1800 interoperation problems. Microsoft have released documentation on their
1801 modifications, but only under a license that hampers attempts either to
1802 audit their code for security flaws or to build other implementations
1803 that interoperate with it.</P>
1804 <LI><A href="http://www.samba.org/">Samba</A> is a Linux implementation
1805 of  the Windows SMB protocol, allowing disk sharing and other network
1806  services</LI>
1807 <LI><A href="http://tipxd.sourceforge.net/">tipxd</A>, the Tunelling
1808 IPX Daemon,  encapsulates IPX for transport over IP. </LI>
1809 </UL>
1810  Here is a mailing list message, from FreeS/WAN team tech support
1811 person Claudia Schmeing, discussing Windows 2000 and L2TP:
1812 <PRE>
1813 You write,
1814
1815 &gt; I want some information about IPsec with L2TP.
1816 &gt; I'm going to build the IPsec tunnel on the L2TP tunnel.
1817 &gt; Is it strange?
1818 &gt; Is there any case like this already implemented?
1819
1820 It's used, but rarely. In many cases, IPSec alone is sufficient.
1821
1822 In this thread, Timo Teras reports that he configured the L2TP/IPSec
1823 hybrid with Win2k. He gives some pointers.
1824 http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00545.html
1825
1826 See also John P. Eisenmenger's report on his own experiences at:
1827 http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00195.html
1828 </PRE>
1829 <H4><A name="interop.win2k">FreeS/WAN-to-Win2000 interop</A></H4>
1830 <P> As for IPSEC interoperation between Windows 2000 and FreeS/WAN,
1831 there are several web sites listed under <A href="#otherpub">Interop
1832 HowTo</A> documents above.</P>
1833 <P>Here is a discussion from the mailing list:</P>
1834 <PRE>From: &quot;Jean-Francois Nadeau&quot; &lt;jna@microflex.ca&gt;
1835 Subject: Win2000 IPsec  interop. in tunnel mode
1836 Date: Tue, 29 Feb 2000
1837
1838 This was a pain.... but it worked. ;)
1839
1840 Win2000 Server against Freeswan 1.1 in tunnel mode is a success.
1841
1842 My Setup
1843
1844 Freeswan :
1845 Kernel 2.2.12 running Freeswan 1.1
1846 Using 3DES-MD5 and PreShared Keys.
1847
1848 Win2000
1849 M$ Win2000 Advanced server patched for 3DES
1850
1851
1852 Here's the setup for the Win2000 Server.
1853
1854 Open an MMC with the IPsec Security policy editor snap-in.
1855 Create a new IP Security Policy.
1856 Create 2 IP SECURITY RULES. One for inbound traffic and one for outbound trafic (see below)
1857 Create 2 IP FILTERS. One for inbound traffic and one for outbound trafic (see below)
1858 Assign the inbound IP SECURITY RULE to the inbound IP FILTERS, same for outbound.
1859 Select both IP SECURITY RULES.
1860 Select your IP Security Policy, right click and ASSIGN.
1861
1862
1863 We need an example to clarify that !@#! logic :
1864
1865 In freeswan :
1866
1867 Conn Interop_Testing
1868 Left=1.2.3.4
1869 Leftsubnet=10.0.0.0/8
1870 Right=9.8.7.6
1871 Rightsubnet=192.168.0.0/24
1872
1873
1874 In Win2000
1875
1876 IP Security Policy : Interop_Testing
1877
1878 **********
1879 1st IP Security rule : Left_to_Right
1880         IP Filter  List : Left_to_Right
1881                 Source Address = 1.2.3.4
1882                 Destination Address = A specific Subnet = 192.168.0.0 255.255.255.0
1883         Filter Action : Request Security
1884         Connections type : All connections
1885         Tunnel Settings : Endpoint = 9.8.7.6
1886         Authentication Method = PreSharedKey=yourkey
1887 ***********
1888
1889 **********
1890 2nd IP Security rule : Right_to_Left
1891         IP Filter  List : Right_to_Left
1892                 Source Address = 9.8.7.6
1893                 Destination Address = A specific Subnet = 10.0.0.0 255.0.0.0
1894         Filter Action : Request Security
1895         Connections type : All connections
1896         Tunnel Settings : Endpoint = 1.2.3.4
1897         Authentication Method = PreSharedKey=yourkey
1898 ***********
1899
1900
1901 HINTS :
1902
1903 Do not use mirroring in your IP filters.
1904 Move your main proposal to the top (in my case 3DES-MD5)
1905 Enable PFS.
1906
1907 It worked... but a RoadWarrior configuration doesnt seems to be
1908 possible here (must specify both Endpoints and 0.0.0.0 is not acceptable).
1909
1910
1911 Jean-Francois Nadeau
1912 Microlfex.
1913 </PRE>
1914 <P> The RoadWarrior problem has since been solved. RSA authentication
1915 has been added to FreeS/WAN since the above message was posted. </P>
1916 <HR>
1917 <A HREF="toc.html">Contents</a>
1918 <A HREF="compat.html">Previous</a>
1919 <A HREF="politics.html">Next</a>
1920 </BODY>
1921 </HTML>