freeswan/doc/src/faq.html

   1 <html>
   2 <head>
   3   <meta http-equiv="Content-Type" content="text/html">
   4   <title>FreeS/WAN FAQ</title>
   5   <meta name="keywords" content="Linux, IPsec, VPN, security, FreeSWAN, FAQ">
   6   <!--
   7
   8   Written by Sandy Harris for the Linux FreeS/WAN project
   9   Freely distributable under the GNU General Public License
  10
  11   More information at www.freeswan.org
  12   Feedback to users@lists.freeswan.org
  13
  14   CVS information:
  15   RCS ID:          $Id: faq.html,v 1.83 2002/03/26 16:42:42 sandy Exp $
  16   Last changed:    $Date: 2002/03/26 16:42:42 $
  17   Revision number: $Revision: 1.83 $
  18
  19   CVS revision numbers do not correspond to FreeS/WAN release numbers.
  20   -->
  21 </head>
  22
  23 <body>
  24 <h1>FreeS/WAN FAQ</h1>
  25
  26 <p>This is a collection of questions and answers, mostly taken from the
  27 FreeS/WAN <a href="mail.html">mailing list</a>. See the project <a
  28 href="http://www.freeswan.org/">web site</a> for more information. All the
  29 FreeS/WAN documentation is online there.</p>
  30
  31 <p>Contributions to the FAQ are welcome. Please send them to the project <a
  32 href="mail.html">mailing list</a>.</p>
  33 <hr>
  34
  35 <h2><a name="questions">Index of FAQ questions</a></h2>
  36 <ul>
  37   <li><a href="#whatzit">What is FreeS/WAN?</a></li>
  38   <li><a href="#problems">How do I report a problem or seek help?</a></li>
  39   <li><a href="#generic">Can I get ...</a>
  40     <ul>
  41       <li><a href="#lemme_out">... an off-the-shelf system that includes
  42         FreeS/WAN?</a></li>
  43       <li><a href="#contractor">... contractors or staff who know
  44         FreeS/WAN?</a></li>
  45       <li><a href="#commercial">... commercial support?</a></li>
  46     </ul>
  47   </li>
  48   <li><a href="#release">Release questions</a>
  49     <ul>
  50       <li><a href="#rel.current">What is the current release?</a></li>
  51       <li><a href="#relwhen">When is the next release?</a></li>
  52       <li><a href="#rel.bugs">Are there known bugs in the current
  53       release?</a></li>
  54     </ul>
  55   </li>
  56   <li><a href="mod_cons">Modifications and contributions</a>
  57     <ul>
  58       <li><a href="#modify.faq">Can I modify FreeS/WAN to ...?</a></li>
  59       <li><a href="#contrib.faq">Can I contribute to the project?</a></li>
  60       <li><a href="#ddoc.faq">Is there detailed design documentation?</a></li>
  61     </ul>
  62   </li>
  63   <li><a href="#interact">Will FreeS/WAN work in my environment?</a>
  64     <ul>
  65       <li><a href="#interop.faq">Can FreeS/WAN talk to ... ?</a></li>
  66       <li><a href="#old_to_new">Can different FreeS/WAN versions talk to each
  67         other?</a></li>
  68       <li><a href="#faq.bandwidth">Is there a limit on throughput?</a></li>
  69       <li><a href="#faq.number">Is there a limit on number of
  70       connections?</a></li>
  71       <li><a href="#faq.speed">Is a ... fast enough to handle FreeS/WAN with
  72         my loads?</a></li>
  73     </ul>
  74   </li>
  75   <li><a href="#work_on">Will FreeS/WAN work on ...</a>
  76     <ul>
  77       <li><a href="#versions">... my version of Linux?</a></li>
  78       <li><a href="#nonIntel.faq">... non-Intel CPUs?</a></li>
  79       <li><a href="#multi.faq">... multiprocessors?</a></li>
  80       <li><a href="#k.old">... an older kernel?</a></li>
  81       <li><a href="#k.versions">... the latest kernel version?</a></li>
  82       <li><a href="#interface.faq">... unusal network hardware?</a></li>
  83     </ul>
  84   </li>
  85   <li><a href="#features.faq">Does FreeS/WAN support ...</a>
  86     <ul>
  87       <li><a href="#VPN.faq">... site-to-site VPN applications</a></li>
  88       <li><a href="#warrior.faq">... remote users connecting to a LAN</a></li>
  89       <li><a href="#road.shared.possible">... remote users using shared
  90         secret authentication?</a></li>
  91       <li><a href="#wireless.faq">... wireless networks</a></li>
  92       <li><a href="#PKIcert">... X.509 or other PKI certificates?</a></li>
  93       <li><a href="#Radius">... user authentication (Radius, SecureID,
  94         ...)?</a></li>
  95       <li><a href="#virtID">... assigning a "virtual identity" to a remote
  96         system?</a></li>
  97       <li><a href="#noDES.faq">... single DES encryption?</a></li>
  98       <li><a href="#AES.faq">... AES encryption?</a></li>
  99       <li><a href="#other.cipher">... other encryption algorithms?</a></li>
 100     </ul>
 101   </li>
 102   <li><a href="#canI">Can I ...</a>
 103     <ul>
 104       <li><a href="#reload">... reload connection info without
 105       restarting?</a></li>
 106       <li><a href="#masq.faq">... use several masqueraded subnets?</a></li>
 107       <li><a href="#dup_route">... use subnets masqueraded to the same
 108         addresses?</a></li>
 109       <li><a href="#road.masq">... assign a road warrior an address on my net
 110         (a virtual identity)?</a></li>
 111       <li><a href="#road.many">... support many road warriors with one
 112         gateway?</a></li>
 113       <li><a href="#road.PSK">... have many road warriors using shared secret
 114         authentication?</a></li>
 115       <li><a href="#QoS">... use Quality of Service routing with
 116         FreeS/WAN?</a></li>
 117       <li><a href="#deadtunnel">... recognise dead tunnels and shut them
 118         down?</a></li>
 119       <li><a href="#demanddial">... build IPsec tunnels over a demand-dialed
 120         link?</a></li>
 121       <li><a href="#GRE">... build GRE tunnels over IPsec?</a></li>
 122     </ul>
 123   </li>
 124   <li><a href="#setup.faq">Life's little mysteries</a>
 125     <ul>
 126       <li><a href="#cantping">I cannot ping ....</a></li>
 127       <li><a href="#forever">It takes forever to ...</a></li>
 128       <li><a href="#route">I send packets to the tunnel with route(8) but
 129         they vanish</a></li>
 130       <li><a href="#down_route">When a tunnel goes down, packets
 131       vanish</a></li>
 132       <li><a href="#firewall_ate">The firewall ate my packets!</a></li>
 133       <li><a href="#dropconn">Dropped connections</a></li>
 134       <li><a href="#tcpdump.faq">TCPdump on the gateway shows strange
 135         things</a></li>
 136       <li><a href="#no_trace">Traceroute does not show anything between the
 137         gateways</a></li>
 138     </ul>
 139   </li>
 140   <li><a href="#man4debug">Testing in stages (or .... works but ...
 141     doesn't)</a>
 142     <ul>
 143       <li><a href="#nomanual">Manually keyed connections don't work</a></li>
 144       <li><a href="#spi_error">One manual connection works, but second one
 145         fails</a></li>
 146       <li><a href="#man_no_auto">Manual connections work, but automatic
 147         keying doesn't</a></li>
 148       <li><a href="#nocomp">IPsec works, but connections using compression
 149         fail</a></li>
 150       <li><a href="#pmtu.broken">Small packets work, but large transfers
 151         fail</a></li>
 152       <li><a href="#subsub">Subnet-to-subnet works, but tests from the
 153         gateways don't</a></li>
 154     </ul>
 155   </li>
 156   <li><a href="#compile.faq">Compilation problems</a>
 157     <ul>
 158       <li><a href="#gmp.h_missing">gmp.h: No such file or directory</a></li>
 159       <li><a href="#noVM">... virtual memory exhausted</a></li>
 160     </ul>
 161   </li>
 162   <li><a href="#error">Interpreting error messages</a>
 163     <ul>
 164       <li><a href="#route-client">route-client (or host) exited with status
 165         7</a></li>
 166       <li><a href="#unreachable">SIOCADDRT:Network is unreachable</a></li>
 167       <li><a href="#modprobe">ipsec_setup: modprobe: Can't locate
 168         moduleipsec</a></li>
 169       <li><a href="#noKLIPS">ipsec_setup: Fatal error, kernel appears to lack
 170         KLIPS</a></li>
 171       <li><a href="#noDNS">ipsec_setup: ... failure to fetch key for ... from
 172         DNS</a></li>
 173       <li><a href="#dup_address">ipsec_setup: ... interfaces ... and ...
 174         share address ...</a></li>
 175       <li><a href="#kflags">ipsec_setup: Cannot adjust kernel flags</a></li>
 176       <li><a href="#message_num">Message numbers (MI3, QR1, et cetera) in
 177         Pluto messages</a></li>
 178       <li><a href="#conn_name">Connection names in Pluto error
 179       messages</a></li>
 180       <li><a href="#cantorient">Pluto: ... can't orient connection</a></li>
 181       <li><a href="#no.interface">... we have no ipsecN interface for either
 182         end of this connection</a></li>
 183       <li><a href="#noconn">Pluto: ... no connection is known</a></li>
 184       <li><a href="#nosuit">Pluto: ... no suitable connection ...</a></li>
 185       <li><a href="#noconn.auth">Pluto: ... no connection has been
 186         authorized</a></li>
 187       <li><a href="#noDESsupport">Pluto: ... OAKLEY_DES_CBC is not
 188         supported.</a></li>
 189       <li><a href="#notransform">Pluto: ... no acceptable transform</a></li>
 190       <li><a href="#rsasigkey">rsasigkey dumps core</a></li>
 191       <li><a href="#sig4">!Pluto failure!: ... exited with ... signal
 192       4</a></li>
 193       <li><a href="#econnrefused">ECONNREFUSED error message</a></li>
 194       <li><a href="#no_eroute">klips_debug: ... no eroute!</a></li>
 195       <li><a href="#SAused">... trouble writing to /dev/ipsec ... SA already
 196         in use</a></li>
 197       <li><a href="#ignore">... ignoring ... payload</a></li>
 198     </ul>
 199   </li>
 200   <li><a href="#spam">Why don't you restrict the mailing lists to reduce
 201     spam?</a></li>
 202 </ul>
 203 <hr>
 204
 205 <h2><a name="whatzit">What is FreeS/WAN?</a></h2>
 206
 207 <p>FreeS/WAN is a Linux implementation of the <a
 208 href="glossary.html#IPSEC">IPsec</a> protocols, providing security services
 209 at the IP (Internet Protocol) level of the network.</p>
 210
 211 <p>For more detail, see our <a href="intro.html">introduction</a> document or
 212 the FreeS/WAN project <a href="http://www.freeswan.org/">web site</a>.</p>
 213
 214 <p>To start setting it up, go to our <a href="quickstart.html">quickstart
 215 guide</a>.</p>
 216
 217 <p>Our <a href="web.html">web links</a> document has information on <a
 218 href="web.html#implement">IPsec for other systems</a>.</p>
 219
 220 <h2><a name="problems">How do I report a problem or seek help?</a></h2>
 221
 222 <p>See our <a href="trouble.html">troubleshooting</a> document. It may guide
 223 you to a solution. If not, see its <a href="trouble.html#prob.report">problem
 224 reporting</a> section.</p>
 225
 226 <p>Basically, what it says is <strong>give us the output from <var>ipsec
 227 barf</var> from both gateways</strong>. Without full information, we cannot
 228 diagnose a problem. However, <var>ipsec barf</var> produces a lot of output.
 229 If at all possible, <strong>please make barfs accessible via the web or
 230 FTP</strong> rather than sending enormous mail messages.</p>
 231
 232 <p><strong>Use the <a href="mail.html">users mailing list</a> for problem
 233 reports</strong>, rather than mailing developers directly.</p>
 234 <ul>
 235   <li>This gives you access to more expertise, including users who may have
 236     encountered and solved the same problems.</li>
 237   <li>It is more likely to get a quick response. Developers may get behind on
 238     email, or even ignore it entirely for a while, but a list message (given
 239     a reasonable Subject: line) is certain to be read by a fair number of
 240     people within hours.</li>
 241   <li>It may also be important because of <a
 242     href="politics.html#exlaw">cryptography export laws</a>. A US citizen who
 243     provides technical assistance to foreign cryptographic work might be
 244     charged under the arms export regulations. Such a charge would be easier
 245     to defend if the discussion took place on a public mailing list than if
 246     it were done in private mail.</li>
 247 </ul>
 248
 249 <p>For problems involving interoperation with another IPsec implementation,
 250 try our  <a href="interop.html">interoperation document</a>. If that does not
 251 help, try the <a href="mail.html">mailing lis</a>t. In this area, the users
 252 often know more than the developers.</p>
 253
 254 <p>Support beyond what the mailing list can provide is also available. See
 255 the next several questions.</p>
 256
 257 <p>See also these essays on <a
 258 href="http://tuxedo.org/~esr/faqs/smart-questions.html">How To Ask Questions
 259 The Smart Way</a> and <a
 260 href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How to Report
 261 Bugs Effectively</a>.</p>
 262
 263 <h2><a name="generic">Can I get ...</a></h2>
 264
 265 <h3><a name="lemme_out" ">Can I get an off-the-shelf system that includes
 266 FreeS/WAN?</a></h3>
 267
 268 <p>There are a number of Linux distributions or firewall products which
 269 include FreeS/WAN. See this <a href="intro.html#products">list</a>. Using one
 270 of these, chosen to match your requirements and budget, may save you
 271 considerable time and effort.</p>
 272
 273 <p>If you don't know your requirements, start by reading Schneier's <a
 274 href="biblio.html#secrets">Secrets and Lies</a>. That gives the best overview
 275 of security issues I have seen. Then consider hiring a consultant (see next
 276 question) to help define your requirements.</p>
 277
 278 <h3><a name="consultant">Can I hire consultants or staff who know
 279 FreeS/WAN?</a></h3>
 280
 281 <p>If you want the help of a contractor, or to hire staff with FreeS/WAN
 282 expertise, you could:</p>
 283 <ul>
 284   <li>check availability in your area through your local Linux User Group (<a
 285     href="http://lugww.counter.li.org/">LUG Index</a>)</li>
 286   <li>try asking on our <a href="mail.html">mailing list</a></li>
 287 </ul>
 288
 289 <p>For companies offerring support, see the next question.</p>
 290
 291 <h3><a name="commercial">Can I get commercial support?</a></h3>
 292
 293 <p>Many of the distributions or firewall products which include FreeS/WAN
 294 (see this <a href="intro.html#products">list</a>) come with commercial
 295 support or have it available as an option.</p>
 296
 297 <p>Various companies specialize in commercial support of open source
 298 software. Our project leader was a founder of the first such company, Cygnus
 299 Support. It has since been bought by <a
 300 href="http://www.redhat.com">Redhat</a>. Another such firm is <a
 301 href="http://www.linuxcare.com">Linuxcare</a>.</p>
 302
 303 <h2><a name="release">Release questions</a></h2>
 304
 305 <h3><a name="rel.current">What is the current release?</a></h3>
 306
 307 <p>The current release is the highest-numbered tarball on our <a
 308 href="ftp://ftp.xs4all.nl/pub/crypto/freeswan">distribution site</a>. Almost
 309 always, any of <a href="intro.html#mirrors">the mirrors</a> will have the
 310 same file, though perhaps not for a day or so after a release.</p>
 311
 312 <p>Unfortunately, the web site is not always updated as quickly as it should
 313 be. At time of writing, for example, 1.96 has been on the FTP site for about
 314 two weeks, but the web site still lists 1.95 as current, and the 1.96
 315 documentation is not yet on the web site.</p>
 316
 317 <p>We are working on fixing this, but it is complicated with our team in
 318 North America, the site in Europe and everyone involved having other tasks as
 319 well.</p>
 320
 321 <h3><a name="relwhen">When is the next release?</a></h3>
 322
 323 <p>We try to do a release in the first week of every month except January and
 324 August. We might adjust this a week either way because people are away at
 325 conferences or whatever.</p>
 326
 327 <p>If pre-release tests fail and the fix appears complex, or more generally
 328 if the code does not appear stable when a release is scheduled, we will just
 329 skip that release. This appears a better strategy than rushing complex work
 330 to produce a late release.</p>
 331
 332 <p>For serious bugs, we may bring out an extra bug-fix release. These get
 333 numbers in the normal release series.  For example, there was a bug found in
 334 FreeS/WAN 1.6, so we did another release less than two weeks later. The
 335 bug-fix release was called 1.7, not something like 1.6a or 1.6.1.</p>
 336
 337 <h3><a name="rel.bugs">Are there known bugs in the current release?</a></h3>
 338
 339 <p>Any problems we are aware of at the time of a release are documented in
 340 the <a href="../BUGS">BUGS</a> file for that release. You should also look at
 341 the <a href="../CHANGES">CHANGES</a> file.</p>
 342
 343 <p>Bugs discovered after a release are discussed on the <a
 344 href="mail.html">mailing lists</a>. The easiest way to check for any problems
 345 in the current code would be to peruse Claudia's weekly summaries on the
 346 briefs list, <a href="http://lists.freeswan.org/pipermail/briefs">archived
 347 here</a>.</p>
 348
 349 <h2><a name="mod_cons">Modifications and contributions</a></h2>
 350
 351 <h3><a name="modify.faq">Can I modify FreeS/WAN to ...?</a></h3>
 352
 353 <p>You are free to modify FreeS/WAN in any way. See the discussion of <a
 354 href="intro.html#licensing">licensing</a> in our introduction document.</p>
 355
 356 <p>Before investing much energy in any such project, we suggest that you</p>
 357 <ul>
 358   <li>check the list of <a href="web.html#patch">existing patches</a></li>
 359   <li>post something about your project to the <a href="mail.html">design
 360     mailing list</a></li>
 361 </ul>
 362
 363 <p>This may prevent duplicated effort, or lead to interesting
 364 collaborations.</p>
 365
 366 <h3><a name="contrib.faq">Can I contribute to the project?</a></h3>
 367 In general, we welcome contributions from the community. Various contributed
 368 patches, either to fix bugs or to add features, have been incorporated into
 369 our distribution. Other patches, not yet included in the distribution, are
 370 listed in our <a href="web.html#patch">web links</a> section.
 371
 372 <p>Users have also contributed heavily to documentation, both by creating
 373 their own <a href="intro.html#howto">HowTos</a> and by posting things on the
 374 <a href="mail.html">mailing lists</a> which I have quoted in these HTML
 375 docs.</p>
 376
 377 <p>There are, however, some caveats.</p>
 378
 379 <p>FreeS/WAN is being implemented in Canada, by Canadians, largely to ensure
 380 that is it is entirely free of export restrictions. See this <a
 381 href="politics.html#status">discussion</a>. We <strong>cannot accept code
 382 contributions from US residents or citizens</strong>, not even one-line bugs
 383 fixes. The reasons for this were recently discussed extensively on the
 384 mailing list, in a thread starting <a
 385 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00111.html">here</a>.</p>
 386
 387 <p>Not all contributions are of interest to us. The project has a set of
 388 fairly ambitious and quite specific goals, described in our <a
 389 href="intro.html#goals">introduction</a>. Contributions that lead toward
 390 these goals are likely to be welcomed enthusiastically. Other contributions
 391 may be seen as lower priority, or even as a distraction.</p>
 392
 393 <p>Discussion of possible contributions takes place on the <a
 394 href="mail.html">design mailing list</a>.</p>
 395
 396 <h3><a name="ddoc.faq">Is there detailed design documentation?</a></h3>
 397 There are:
 398 <ul>
 399   <li><a href="rfc.html">RFCs</a> specifying the protocols we implement</li>
 400   <li><a href="manpages.html">man pages</a> for our utilities, library
 401     functions and file formats</li>
 402   <li>comments in the source code</li>
 403   <li><a href="index.html">HTML documentation</a> written primarily for
 404   users</li>
 405   <li>archived discussions from the <a href="mail.html">mailing lists</a></li>
 406   <li>other papers mentioned in our <a
 407     href="intro.html#applied">introduction</a></li>
 408 </ul>
 409
 410 <p>The only formal design documents are a few papers in the last category
 411 above. All the other categories, however, have things to say about design as
 412 well.</p>
 413
 414 <h2><a name="interact">Will FreeS/WAN work in my environment?</a></h2>
 415
 416 <h3><a name="interop.faq">Can FreeS/WAN talk to ...?</a></h3>
 417
 418 <p>The IPsec protocols are designed to support interoperation. In theory, any
 419 two IPsec implementations should be able to talk to each other. In practice,
 420 it is considerably more complex. We have a whole <a
 421 href="interop.html">interoperation document</a> devoted to this problem.</p>
 422
 423 <p>An important part of that document is links to the many <a
 424 href="interop.html#otherpub">user-written HowTos</a> on interoperation
 425 between FreeS/WAN and various other implementations. Often the users know
 426 more than the developers about these issues (and almost always more than me
 427 :-), so these documents may be your best resource.</p>
 428
 429 <h3><a name="old_to_new">Can different FreeS/WAN versions talk to each
 430 other?</a></h3>
 431
 432 <p>Linux FreeS/WAN can interoperate with many IPsec implementations,
 433 including earlier versions of Linux FreeS/WAN itself.</p>
 434
 435 <p>In a few cases, there are some complications. See our <a
 436 href="interop.html#oldswan">interoperation</a> document for details.</p>
 437
 438 <h3><a name="faq.bandwidth">Is there a limit on throughput?</a></h3>
 439
 440 <p>There is no hard limit, but see below.</p>
 441
 442 <h3><a name="faq.number">Is there a limit on number of tunnels?</a></h3>
 443
 444 <p>There is no hard limit, but see next question.</p>
 445
 446 <h3><a name="faq.speed">Is a ... fast enough to handle FreeS/WAN with my
 447 loads?</a></h3>
 448
 449 <p>A quick summary:</p>
 450 <dl>
 451   <dt>Even a limited machine can be useful</dt>
 452     <dd>A 486 can handle a T1, ADSL or cable link, though the machine may be
 453       breathing hard.</dd>
 454   <dt>A mid-range PC (say 800 MHz with good network cards) can do a lot of
 455   IPsec</dt>
 456     <dd>With up to roughly 50 tunnels and aggregate bandwidth of 20 Megabits
 457       per second, it willl have cycles left over for other tasks.</dd>
 458   <dt>There are limits</dt>
 459     <dd>Even a high end CPU will not come close to handling a fully loaded
 460       100 Mbit/second Ethernet link.
 461       <p>Beyond about 50 tunnels it needs careful management.</p>
 462     </dd>
 463 </dl>
 464
 465 <p>See our <a href="performance.html">FreeS/WAN performance</a> document for
 466 details.</p>
 467
 468 <h2><a name="work_on">Will FreeS/WAN work on ... ?</a></h2>
 469
 470 <h3><a name="versions">Will FreeS/WAN run on my version of Linux?</a></h3>
 471
 472 <p>We build and test on Redhat distributions, but FreeS/WAN runs just fine on
 473 several other distributions, sometimes with minor fiddles to adapt to the
 474 local environment. Details are in our <a
 475 href="compat.html#otherdist">compatibility</a> document. Also, some
 476 distributions or products come with <a href="intro.html#products">FreeS/WAN
 477 included</a>.</p>
 478
 479 <h3><a name="nonIntel.faq">Will FreeS/WAN run on non-Intel CPUs?</a></h3>
 480
 481 <p>FreeS/WAN is <strong>intended to run on all CPUs Linux supports</strong>.
 482 We know of it being used in production on x86, ARM, Alpha and MIPS. It has
 483 also had successful tests on PPC and SPARC, though we don't know of actual
 484 use there. Details are in our <a href="compat.html#CPUs">compatibility</a>
 485 document.</p>
 486
 487 <h3><a name="multi.faq">Will FreeS/WAN run on multiprocessors?</a></h3>
 488
 489 <p>FreeS/WAN is designed to work on any SMP architecture Linux supports, and
 490 has been tested successfully on at least dual processor Intel architecture
 491 machines. Details are in our <a
 492 href="compat.html#multiprocessor">compatibility</a> document.</p>
 493
 494 <h3><a name="k.old">Will FreeS/WAN work on an older kernel?</a></h3>
 495
 496 <p>It might, but we strongly recommend using a recent 2.2 or 2.4 series
 497 kernel. Sometimes the newer versions include security fixes which can be
 498 quite important on a gateway.</p>
 499
 500 <p>Also, we use recent kernels for development and testing, so those are
 501 better tested and, if you do encounter a problem, more easily supported. If
 502 something breaks applying recent FreeS/WAN patches to an older kernel, then
 503 "update your kernel" is almost certain to be the first thing we suggest. It
 504 may be the only suggestion we have.</p>
 505
 506 <p>The precise kernel versions supported by a particular FreeS/WAN release
 507 are given in the <a href="XX">README</a> file of that release.</p>
 508
 509 <p>See the following question for more on kernels.</p>
 510
 511 <h3><a name="k.versions">Will FreeS/WAN run on the latest kernel
 512 version?</a></h3>
 513
 514 <p>Sometimes yes, but quite often, no.</p>
 515
 516 <p>Kernel versions supported are given in the <a href="../README">README</a>
 517 file of each FreeS/WAN release. Typically, they are whatever production
 518 kernels were current at the time of our release (or shortly before; we might
 519 release for kernel <var>n</var> just as Linus releases <var>n+1</var>). Often
 520 FreeS/WAN will work on slightly later kernels as well, but of course this
 521 cannot be guaranteed.</p>
 522
 523 <p>For example, FreeS/WAN 1.91 was released for kernels 2.2.19 or 2.4.5, the
 524 current kernels at the time. It also worked on 2.4.6, 2.4.7 and 2.4.8, but
 525 2.4.9 had changes that caused compilation errors if it was patched with
 526 FreeS/WAN 1.91.</p>
 527
 528 <p>When such changes appear, we put a fix in the FreeS/WAN snapshots, and
 529 distribute it with our next release. However, this is not a high priority for
 530 us, and it may take anything from a few days to several weeks for such a
 531 problem to find its way to the top of our kernel programmer's To-Do list. In
 532 the meanwhile, you have two choices:</p>
 533 <ul>
 534   <li>either stick with a slightly older kernel, even if it is not the latest
 535     and greatest. This is recommended for production systems; new versions
 536     may have new bugs.</li>
 537   <li>or fix the problem yourself and send us a patch, via the <a
 538     href="mail.html">Users mailing list</a>.</li>
 539 </ul>
 540
 541 <p>We don't even try to keep up with kernel changes outside the main 2.2 and
 542 2.4 branches, such as the 2.4.x-ac patched versions from Alan Cox or the 2.5
 543 series of development kernels. We'd rather work on developing the FreeS/WAN
 544 code than on chasing these moving targets. We are, however, happy to get
 545 patches for problems discovered there.</p>
 546
 547 <p>See also the <a href="install.html#choosek">Choosing a kernel</a> section
 548 of our installation document.</p>
 549
 550 <h3><a name="interface.faq">Will FreeS/WAN work on unusual network
 551 hardware?</a></h3>
 552
 553 <p>IPsec is designed to work over any network that IP works over, and
 554 FreeS/WAN is intended to work over any network interface hardware that Linux
 555 supports.</p>
 556
 557 <p>If you have working IP on some unusual interface -- perhaps Arcnet, Token
 558 Ring, ATM or Gigabit Ethernet -- then IPsec should "just work".</p>
 559
 560 <p>That said, practice is sometimes less tractable than theory. Our testing
 561 is done almost entirely on:</p>
 562 <ul>
 563   <li>10 or 100 Mbit Ethernet</li>
 564   <li>ADSL or cable connections, with and without PPPoE</li>
 565   <li>IEEE 802.11 wireless LANs (see <a href="#wireless.faq">below</a>)</li>
 566 </ul>
 567
 568 <p>If you have some other interface, especially an uncommon one, it is
 569 entirely possible you will get bitten either by a FreeS/WAN bug which our
 570 testing did not turn up, or by a bug in the driver that shows up only with
 571 our loads.</p>
 572
 573 <p>If IP works on your interface and FreeS/WAN doesn't, seek help on the <a
 574 href="mail.html">mailing lists</a>.</p>
 575
 576 <p>Another FAQ section describes <a href="#pmtu.broken">MTU problems</a>.
 577 These are a possibility for some interfaces.</p>
 578
 579 <h2><a name="features.faq">Does FreeS/WAN support ...</a></h2>
 580
 581 <p>For a discussion of which parts of the IPsec specifications FreeS/WAN does
 582 and does not implement, see our <a href="compat.html#spec">compatibility</a>
 583 document.</p>
 584
 585 <p>For information on some often-requested features, see below.</p>
 586
 587 <h3><a name="VPN.faq">Does FreeS/WAN support site-to-site VPN
 588 applications</a></h3>
 589
 590 <p>Yes, FreeS/WAN can be used to build site-to-site <a
 591 href="glossary.html#VPN">Virtual Private Networks</a>.</p>
 592
 593 <p>This application is <a href="intro.html#makeVPN">discussed</a> in our
 594 introduction and an <a href="quickstart.html#net2net">example</a> given in
 595 our FreeS/WAN quickstart document.</p>
 596
 597 <h3><a name="warrior.faq">Does FreeS/WAN support remote users connecting to a
 598 LAN?</a></h3>
 599
 600 <p>Yes, FreeS/WAN can be used to connect remote users. In the documentation,
 601 we refer to them as "Road Warriors".</p>
 602
 603 <p>This application is <a href="intro.html#road.intro">discussed</a> in our
 604 introduction and an <a href="quickstart.html#roadies">example</a> given in
 605 our FreeS/WAN quickstart document.</p>
 606
 607 <p>Road warriors using Windows or Macintosh may need an <a
 608 href="interop.html#winclient">IPsec client</a> program for their machines.</p>
 609
 610 <h3><a name="road.shared.possible">Does FreeS/WAN support remote users using
 611 shared secret authentication?</a></h3>
 612
 613 <p><strong>Yes, but</strong> there are severe restrictions, so <strong>we
 614 strongly recommend using </strong><a
 615 href="glossary.html#RSA"><strong>RSA</strong></a><strong> keys for
 616 </strong><a
 617 href="glossary.html#authentication"><strong>authentication</strong></a><strong>
 618 instead</strong>.</p>
 619
 620 <p>See this <a href="#road.PSK">FAQ question</a>.</p>
 621
 622 <h3><a name="wireless.faq">Does FreeS/WAN support wireless networks?</a></h3>
 623
 624 <p>Yes, it is a common practice to use IPsec over wireless networks because
 625 their built-in encryption, <a href="glossary.html#WEP">WEP</a>, is
 626 insecure.</p>
 627
 628 <p>There is some <a href="adv_config.html#wireless.config">discussion</a> in
 629 our advanced configuration document.</p>
 630
 631 <h3><a name="PKIcert">Does FreeS/WAN support X.509 or other PKI
 632 certificates?</a></h3>
 633
 634 <p>FreeS/WAN, as distributed, does not currently support use of <a
 635 href="glossary.html#x509">X.509</a> or other <a
 636 href="glossary.html#PKI">PKI</a> certificates for authentication of gateways.
 637 We are concentrating on moving toward authentication via <a
 638 href="glossary.html#SDNS">Secure DNS</a> and <a
 639 href="glossary.html#carpediem">opportunistic encryption</a>; X.509 support is
 640 not (or at least not yet) on the priority list.</p>
 641
 642 <p>On the other hand, it is a priority for some users and user-contributed
 643 patches to add X.509 certificate support to FreeS/WAN have been available for
 644 some time. From mailing list reports, they seem to be quite widely used and
 645 to work well.</p>
 646
 647 <p>See the <a href="web.html#patch">patches</a> section of our web references
 648 document for details.</p>
 649
 650 <h3><a name="Radius">Does FreeS/WAN support user authentication (Radius,
 651 SecureID, ...)?</a></h3>
 652
 653 <p>Not yet. So far, there is no standard way to authenticate users for IPsec,
 654 though there is a very active IETF <a
 655 href="http://www.ietf.org/html.charters/ipsra-charter.html">working group</a>
 656 looking at the problem, and several vendors have implemented various things
 657 already.</p>
 658
 659 <p>In the absence of a standard, user authentication has not been a priority
 660 for the FreeS/WAN team, and is unlikely to become one. This would be a good
 661 project for a volunteer, perhaps a staff member or contractor at some company
 662 that needs the feature. Certainly our team would co-operate with such an
 663 effort; we just don't have time to do it.</p>
 664
 665 <p>The <a href="web.html#patch">patches</a> section of our web links document
 666 has links to some user work on this.</p>
 667
 668 <p>Of course, there are various ways to avoid any requirement for user
 669 authentication in IPsec. Consider the situation where road warriors build
 670 IPsec tunnels to your office net and you are considering requiring user
 671 authentication during tunnel negotiation. Alternatives include:</p>
 672 <ul>
 673   <li>If you can trust the road warrior machines, then set them up so that
 674     only authorised users can create tunnels. If your road warriors use
 675     laptops, consider the possibility of theft.</li>
 676   <li>If the tunnel only provides access to particular servers and you can
 677     trust those servers, then set the servers up to require user
 678     authentication.</li>
 679 </ul>
 680
 681 <p>If either of those is trustworthy, it is not clear that you need user
 682 authentication in IPsec.</p>
 683
 684 <h3><a name="virtID">Does FreeS/WAN support assigning a "virtual identity" to
 685 a remote system?</a></h3>
 686
 687 <p>Some IPsec implementations allow you to make the source address on packets
 688 sent by a Road Warrior machine be something other than the address of its
 689 interface to the Internet. This is sometimes described as assigning a virtual
 690 identity to that machine.</p>
 691
 692 <p>FreeS/WAN does not directly support this, but it can be done. See this <a
 693 href="#road.masq">FAQ question</a>.</p>
 694
 695 <h3><a name="noDES.faq">Does FreeS/WAN support single DES encryption?</a></h3>
 696
 697 <p><strong>No</strong>, single DES is not used either at the <a
 698 href="glossary.html#IKE">IKE</a> level for negotiating connections or at the
 699 <a href="glossary.html#IPsec">IPsec</a> level for actually building them.</p>
 700
 701 <p>Single DES is <a href="politics.html#desnotsecure">insecure</a>. As we see
 702 it, it is more important to deliver real security than to comply with a
 703 standard which has been subverted into allowing use of inadequate methods.
 704 See this <a href="politics.html#weak">discussion</a>.</p>
 705
 706 <p>If you want to interoperate with an IPsec implementation which offers only
 707 DES, see our <a href="interop.html#noDES">interoperation</a> document.</p>
 708
 709 <h3><a name="AES.faq">Does FreeS/WAN support AES encryption?</a></h3>
 710
 711 <p><a href="glossary.html#AES">AES</a> is a new US government <a
 712 href="glossary.html#block">block cipher</a> standard to replace the obsolete
 713 <a href="glossary.html#DES">DES</a>.</p>
 714
 715 <p>At time of writing (March 2002), the FreeS/WAN distribution does not yet
 716 support AES but user-written <a href="web.html#patch">patches</a> are
 717 available to add it. Our kernel programmer is working on integrating those
 718 patches into the distribution, and there is active discussion of this on the
 719 design mailimg list.</p>
 720
 721 <h3><a name="other.cipher">Does FreeS/WAN support other encryption
 722 algorithms?</a></h3>
 723
 724 <p>Currently <a href="glossary.html#3DES">triple DES</a> is the only cipher
 725 supported. AES will almost certainly be added (see previous question), and it
 726 is likely that in the process we will also add the other two AES finalists
 727 with open licensing, Twofish and Serpent.</p>
 728
 729 <p>We are extremely reluctant to add other ciphers. This would make both use
 730 and maintenance of FreeS/WAN more complex without providing any clear
 731 benefit. Complexity is emphatically not desirable in a security product.</p>
 732
 733 <p>Various users have written patches to add other ciphers. We provide <a
 734 href="web.html#patch">links</a> to these.</p>
 735
 736 <h2><a name="canI">Can I ...</a></h2>
 737
 738 <h3><a name="reload">Can I reload connection info without restarting?</a></h3>
 739
 740 <p>Yes, you can do this. Here are the details, in a mailing list message from
 741 Pluto programmer Hugh Redelmeier:</p>
 742 <pre>| How can I reload config's without restarting all of pluto and klips?  I am using
 743 | FreeSWAN -&gt; PGPNet in a medium sized production environment, and would like to be
 744 | able to add new connections ( i am using include config/* ) without dropping current
 745 | SA's.
 746 |
 747 | Can this be done?
 748 |
 749 | If not, are there plans to add this kind of feature?
 750
 751         ipsec auto --add whatever
 752 This will look in the usual place (/etc/ipsec.conf) for a conn named
 753 whatever and add it.
 754
 755 If you added new secrets, you need to do
 756         ipsec auto --rereadsecrets
 757 before Pluto needs to know those secrets.
 758
 759 | I have looked (perhaps not thoroughly enough tho) to see how to do this:
 760
 761 There may be more bits to look for, depending on what you are trying
 762 to do.</pre>
 763
 764 <p>Another useful command here is <nobr><var>ipsec auto --replace
 765 &lt;conn_name&gt;</var></nobr>which re-reads data for a named connection.</p>
 766
 767 <h3><a name="masq.faq">Can I use several masqueraded subnets?</a></h3>
 768
 769 <p>Yes. This is done all the time. See the discussion in our <a
 770 href="config.html#route_or_not">setup</a> document. The only restriction is
 771 that the subnets on the two ends must not overlap. See the next question.</p>
 772
 773 <p>Here is a mailing list message on the topic. The user incorrectly thinks
 774 you need a 2.4 kernel for this -- actually various people have been doing it
 775 on 2.0 and 2.2 for quite some time -- but he has it right for 2.4.</p>
 776 <pre>Subject: Double NAT and freeswan working :)
 777    Date: Sun, 11 Mar 2001
 778    From: Paul Wouters &lt;paul@xtdnet.nl&gt;
 779
 780 Just to share my pleasure, and make an entry for people who are searching
 781 the net on how to do this. Here's the very simple solution to have a double
 782 NAT'ed network working with freeswan. (Not sure if this is old news, but I'm
 783 not on the list (too much spam) and I didn't read this in any HOWTO/FAQ/doc
 784 on the freeswan site yet (Sandy, put it in! :)
 785
 786 10.0.0.0/24 --- 10.0.0.1 a.b.c.d  ---- a.b.c.e {internet} ----+
 787                                                               |
 788 10.0.1.0/24 --- 10.0.1.1 f.g.h.i  ---- f.g.h.j {internet} ----+
 789
 790 the goal is to have the first network do a VPN to the second one, yet also
 791 have NAT in place for connections not destinated for the other side of the
 792 NAT. Here the two Linux security gateways have one real IP number (cable
 793 modem, dialup, whatever.
 794
 795 The problem with NAT is you don't want packets from 10.*.*.* to 10.*.*.*
 796 to be NAT'ed. While with Linux 2.2, you can't, with Linux 2.4 you can.
 797
 798 (This has been tested and works for 2.4.2 with Freeswan snapshot2001mar8b)
 799
 800 relevant parts of /etc/ipsec.conf:
 801
 802         left=f.g.h.i
 803         leftsubnet=10.0.1.0/24
 804         leftnexthop=f.g.h.j
 805         leftfirewall=yes
 806         leftid=@firewall.netone.nl
 807         leftrsasigkey=0x0........
 808         right=a.b.c.d
 809         rightsubnet=10.0.0.0/24
 810         rightnexthop=a.b.c.e
 811         rightfirewall=yes
 812         rightid=@firewall.nettwo.nl
 813         rightrsasigkey=0x0......
 814         # To authorize this connection, but not actually start it, at startup,
 815         # uncomment this.
 816         auto=add
 817
 818 and now the real trick. Setup the NAT correctly on both sites:
 819
 820 iptables -t nat -F
 821 iptables -t nat -A POSTROUTING -o eth0 -d \! 10.0.0.0/8 -j MASQUERADE
 822
 823 This tells the NAT code to only do NAT for packets with destination other then
 824 10.* networks. note the backslash to mask the exclamation mark to protect it
 825 against the shell.
 826
 827 Happy painting :)
 828
 829 Paul</pre>
 830
 831 <h3><a name="dup_route">Can I use subnets masqueraded to the same
 832 addresses?</a></h3>
 833
 834 <p><strong>No.</strong> The notion that IP addresses are unique is one of the
 835 fundamental principles of the IP protocol. Messing with it is exceedingly
 836 perilous.</p>
 837
 838 <p>Fairly often a situation comes up where a company has several branches,
 839 all using the same <a href="glossary.html#non-routable">non-routable
 840 addresses</a>, perhaps 192.168.0.0/24. This works fine as long as those nets
 841 are kept distinct. The <a href="glossary.html#masq">IP masquerading</a> on
 842 their firewalls ensures that packets reaching the Internet carry the firewall
 843 address, not the private address.</p>
 844
 845 <p>This can break down when IPsec enters the picture. FreeS/WAN builds a
 846 tunnel that pokes through both masquerades and delivers packets from
 847 <var>leftsubnet</var> to <var>rightsubnet</var> and vice versa. For this to
 848 work, the two subnets <em>must</em> be distinct.</p>
 849
 850 <p>There are several solutions to this problem.</p>
 851
 852 <p>Usually, you <strong>re-number the subnets</strong>. Perhaps the Vancouver
 853 office becomes 192.168.101.0/24, Calgary 192.168.102.0/24 and so on.
 854 FreeS/WAN can happily handle this. With, for example
 855 <var>leftsubnet=192.168.101.0/24</var> and
 856 <var>rightsubnet=192.168.102.0/24</var> in a connection description, any
 857 machine in Calgary can talk to any machine in Vancouver. If you want to be
 858 more restrictive and use something like
 859 <var>leftsubnet=192.168.101.128/25</var> and
 860 <var>rightsubnet=192.168.102.240/28</var> so only certain machines on each
 861 end have access to the tunnel, that's fine too.</p>
 862
 863 <p>You could also <strong>split the subnet</strong> into smaller ones, for
 864 example using <var>192.168.1.0/25</var> in Vancouver and
 865 <var>rightsubnet=192.168.0.128/25</var> in Calgary.</p>
 866
 867 <p>Alternately, you can just <strong>give up routing</strong> directly to
 868 machines on the subnets. Omit the <var>leftsubnet</var> and
 869 <var>rightsubnet</var> parameters from your connection descriptions. Your
 870 IPsec tunnels will then run between the public interfaces of the two
 871 firewalls. Packets will be masqueraded both before they are put into tunnels
 872 and after they emerge. Your Vancouver client machines will see only one
 873 Calgary machine, the firewall.</p>
 874
 875 <h3><a name="road.masq">Can I assign a road warrior an address on my net (a
 876 virtual identity)?</a></h3>
 877
 878 <p>Often it would be convenient to be able to give a Road Warrior an IP
 879 address which appears to be on the local network. Some IPsec implementations
 880 have support for this, sometimes calling the feature "virtual identity".</p>
 881
 882 <p>At time of writing (Feb 2002) FreeS/WAN does not support this, and we have
 883 no definite plans to add it. The difficulty is that is not yet a standard
 884 mechanism for it. There is an Internet Draft for a method of doing it using
 885 <a href="#DHCP">DHCP</a> which looks promising. FreeS/WAN may support that in
 886 a future release.</p>
 887
 888 <p>In the meanwhile, you can do it yourself using the Linux iproute2(8)
 889 facilities. Details are in <a
 890 href="http://www.quintillion.com/moat/ipsec+routing/iproute2.html">this
 891 paper</a>.</p>
 892
 893 <p>Another method has also been discussed on the mailing list.:</p>
 894 <ul>
 895   <li>You can use a variant of the <a
 896     href="adv_config.html#extruded.config">extruded subnet</a> procedure.</li>
 897   <li>You have to avoid having the road warrior's assigned address within the
 898     range you actually use at home base. See previous question.</li>
 899   <li>On the other hand, you want the roadwarrior's address to be within the
 900     range that <em>seems</em> to be on your network.</li>
 901 </ul>
 902
 903 <p>For example, you might have:</p>
 904 <dl>
 905   <dt>leftsubnet=a.b.c.0/25</dt>
 906     <dd>head office network</dd>
 907   <dt>rightsubnet=a.b.c.129/32</dt>
 908     <dd>extruded to a road warrior. Note that this is not in a.b.c.0/25</dd>
 909   <dt>a.b.c.0/24</dt>
 910     <dd>whole network, including both the above</dd>
 911 </dl>
 912
 913 <p>You then set up routing so that the office machines use the IPsec gateway
 914 as their route to a.b.c.128/25. The leftsubnet parameter tells the road
 915 warriors to use tunnels to reach a.b.c.0/25, so you should have two-way
 916 communication. Depending or your network and applications, there may be some
 917 additional work to do on DNS or Windows configuration</p>
 918
 919 <h3><a name="road.many">Can I support many road warriors with one
 920 gateway?</a></h3>
 921
 922 <p>Yes. This is easily done, using</p>
 923 <dl>
 924   <dt>either RSA authentication</dt>
 925     <dd>standard in the FreeS/WAN distribution</dd>
 926   <dt>or X.509 certificates</dt>
 927     <dd>requires <a href="web.html#patch">patches</a> to FreeS/WAN</dd>
 928 </dl>
 929
 930 <p>In either case, each Road Warrior must have a different key or
 931 certificate.</p>
 932
 933 <p>This cannot be made to work using pre-shared key authentication; see the
 934 <a href="#road.PSK">next question</a> for details.</p>
 935
 936 <p>If you expect to have more than a few dozen Road Warriors connecting
 937 simultaneously, you may need a fairly powerful gateway machine. See our
 938 document on <a href="performance.html">FreeS/WAN performance</a>.</p>
 939
 940 <h3><a name="road.PSK">Can I have many road warriors using shared secret
 941 authentication?</a></h3>
 942
 943 <p><strong>No</strong>. There is no way to do this securely, and there is no
 944 way to fix the problem.</p>
 945
 946 <p>You can have multiple Road Warriors using shared secret authentication
 947 <strong>only if they all use the same secret</strong>. This creates
 948 problems:</p>
 949 <ul>
 950   <li>If you have many users, it becomes almost certain the secret will
 951   leak</li>
 952   <li>The secret becomes quite valuable to an attacker</li>
 953   <li>All users authenticate the same way, so the gateway cannot tell them
 954     apart for logging or access control purposes</li>
 955   <li>Changing the secret is difficult. You have to securely notify all
 956   users.</li>
 957   <li>If you find out the secret has been compromised, you can change it, but
 958     then what? None of your users can connect without the new secret. How
 959     will you notify them all, quickly and securely, without using the
 960   VPN?</li>
 961 </ul>
 962
 963 <p>This is a designed-in limitation of the <a
 964 href="glossary.html#IKE">IKE</a> key negotiation protocol, not a problem with
 965 our implementation.</p>
 966
 967 <p>When using shared secrets, the protocol requires that the responding
 968 gateway be able to determine which secret to use at a time when all it knows
 969 about the initiator is an IP address. This works fine if you know the
 970 initiator's address in advance and can use it to look up the appropiriate
 971 secret. However, it fails for Road Warriors since the gateway cannot know
 972 their IP addresses in advance.</p>
 973
 974 <p><strong>We very strongly recommend that you avoid using shared secret
 975 authentication for multiple Road Warriors.</strong> Use RSA authentication
 976 instead.</p>
 977
 978 <p>With RSA signatures (or certificates) the protocol is slightly different.
 979 The initiator provides an identifier early in the exchange and the responder
 980 can use that identifier to look up the correct key or certificate. See <a
 981 href="#road.many">above</a>.</p>
 982
 983 <h3><a name="QoS">Can I use Quality of Service routing with
 984 FreeS/WAN?</a></h3>
 985
 986 <p>From project technical lead Henry Spencer:</p>
 987 <pre>&gt; Do QoS add to FreeS/WAN?
 988 &gt; For example integrating DiffServ and FreeS/WAN?
 989
 990 With a current version of FreeS/WAN, you will have to add hidetos=no to
 991 the config-setup section of your configuration file.  By default, the TOS
 992 field of tunnel packets is zeroed; with hidetos=no, it is copied from the
 993 packet inside.  (This is a modest security hole, which is why it is no
 994 longer the default.)
 995
 996 DiffServ does not interact well with tunneling in general.  Ways of
 997 improving this are being studied.</pre>
 998
 999 <p>Copying the <a href="glossary.html#TOS">TOS</a> (type of service)
1000 information from the encapsulated packet to the outer header reveals the TOS
1001 information to an eavesdropper. This does not tell him much, but it might be
1002 of use in <a href="glossary.html#traffic">traffic analysis</a>. Since we do
1003 not have to give it to him, our default is not to.</p>
1004
1005 <p>See <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> for more on
1006 the <var>hidetos=</var> parameter.</p>
1007
1008 <h3><a name="deadtunnel">Can I recognise dead tunnels and shut them
1009 down?</a></h3>
1010
1011 <p>There is no general mechanism to do this is in the IPsec protocols.</p>
1012
1013 <p>From time to time, there is discussion on the IETF Working Group <a
1014 href="mail.html#ietf">mailing list</a> of adding a "keep-alive" mechanism
1015 (which some say should be called "make-dead"), but it is a fairly complex
1016 problem and no consensus has been reached on whether or how it should be
1017 done.</p>
1018
1019 <p>The protocol does have optional <a href="#ignore">delete-SA</a> messages
1020 which one side can send when it closes a connection in hopes this will cause
1021 the other side to do the same. FreeS/WAN does not currently support these. In
1022 any case, they would not solve the problem since:</p>
1023 <ul>
1024   <li>a gateway that crashes or hangs would not send the messages</li>
1025   <li>the sender is not required to send them</li>
1026   <li>they are not authenticated, so any receiver that trusts them leaves
1027     itself open to a <a href="glossary.html#DOS">denial of service</a>
1028   attack</li>
1029   <li>the receiver is not required to do anything about them</li>
1030   <li>the receiver cannot acknowledge them; the protocol provides no
1031     mechanism for that</li>
1032   <li>since they are not acknowledged, the sender cannot rely on them</li>
1033 </ul>
1034
1035 <p>However, connections do have limited lifetimes and you can control how
1036 many attempts your gateway makes to rekey before giving up. For example, you
1037 can set:</p>
1038 <pre>conn default
1039         keyingtries=3
1040         keylife=30m</pre>
1041
1042 <p>With these settings old connections will be cleaned up. Within 30 minutes
1043 of the other end dying, rekeying will be attempted. If it succeeds, the new
1044 connection replaces the old one. If it fails, no new connection is created.
1045 Either way, the old connection is taken down when its lifetime expires.</p>
1046
1047 <p>Here is a mailing list message on the topic from FreeS/WAN tech support
1048 person Claudia Schmeing:</p>
1049 <pre>You ask how to determine whether a tunnel is redundant:
1050
1051 &gt; Can anybody explain the best way to determine this. Esp when a RW has
1052 &gt; disconnected? I thought 'ipsec auto --status' might be one way.
1053
1054 If a tunnel goes down from one end, Linux FreeS/WAN on the
1055 other end has no way of knowing this until it attempts to rekey.
1056 Once it tries to rekey and fails, it will 'know' that the tunnel is
1057 down.
1058
1059 Because it doesn't have a way of knowing the state until this point,
1060 it will also not be able to tell you the state via ipsec auto --status.
1061
1062 &gt; However, comparing output from a working tunnel with that of one that
1063 &gt; was closed
1064 &gt; did not show clearly show tunnel status.
1065
1066 If your tunnel is down but not 'unrouted' (see man ipsec_auto), you
1067 should not be able to ping the opposite side of the tunnel. You can
1068 use this as an indicator of tunnel status.
1069
1070 On a related note, you may be interested to know that as of 1.7,
1071 redundant tunnels caused by RW disconnections are likely to be
1072 less of a pain. From doc/CHANGES:
1073
1074     There is a new configuration parameter, uniqueids, to control a new Pluto
1075     option:  when a new connection is negotiated with the same ID as an old
1076     one, the old one is deleted immediately.  This should help eliminate
1077     dangling Road Warrior connections when the same Road Warrior reconnects.
1078     It thus requires that IDs not be shared by hosts (a previously legal but
1079     probably useless capability).  NOTE WELL:  the sample ipsec.conf now has
1080     uniqueids=yes in its config-setup section.
1081
1082
1083 Cheers,
1084
1085 Claudia</pre>
1086
1087 <h3><a name="demanddial">Can I build IPsec tunnels over a demand-dialed
1088 link?</a></h3>
1089
1090 <p>This is possible, but not easy. FreeS/WAN technical lead Henry Spencer
1091 wrote:</p>
1092 <pre>&gt; 5. If the ISDN link goes down in between and is reestablished, the SAs
1093 &gt; are still up but the eroute are deleted and the IPsec interface shows
1094 &gt; garbage (with ifconfig)
1095 &gt; 6. Only restarting IPsec will bring the VPN back online.
1096
1097 This one is awkward to solve.  If the real interface that the IPsec
1098 interface is mounted on goes down, it takes most of the IPsec machinery
1099 down with it, and a restart is the only good way to recover.
1100
1101 The only really clean fix, right now, is to split the machines in two:
1102
1103 1. A minimal machine serves as the network router, and only it is aware
1104 that the link goes up and down.
1105
1106 2. The IPsec is done on a separate gateway machine, which thinks it has
1107 a permanent network connection, via the router.
1108
1109 This is clumsy but it does work.  Trying to do both functions within a
1110 single machine is tricky.  There is a software package (diald) which will
1111 give the illusion of a permanent connection for demand-dialed modem
1112 connections; I don't know whether it's usable for ISDN, or whether it can
1113 be made to cooperate properly with FreeS/WAN.
1114
1115 Doing a restart each time the interface comes up *does* work, although it
1116 is a bit painful.  I did that with PPP when I was running on a modem link;
1117 it wasn't hard to arrange the PPP scripts to bring IPsec up and down at
1118 the right times.  (I'd meant to investigate diald but never found time.)
1119
1120 In principle you don't need to do a complete restart on reconnect, but you
1121 do have to rebuild some things, and we have no nice clean way of doing
1122 only the necessary parts.</pre>
1123
1124 <p>In the same thread, one user commented:</p>
1125 <pre>Subject: Re: linux-ipsec: IPsec and Dial Up Connections
1126    Date: Wed, 22 Nov 2000
1127    From: Andy Bradford &lt;andyb@calderasystems.com&gt;
1128
1129 On Wed, 22 Nov 2000 19:47:11 +0100, Philip Reetz wrote:
1130
1131 &gt; Are there any ideas what might be the cause of the problem and any way
1132 &gt; to work around it.
1133 &gt; Any help is highly appreciated.
1134
1135 On my laptop, when using ppp there is a ip-up script in /etc/ppp that
1136 will be executed each time that the ppp interface is brought up.
1137 Likewise there is an ip-down script that is called when it is taken
1138 down.  You might consider custimzing those to stop and start FreeS/Wan
1139 with each connection.  I believe that ISDN uses the same files, though
1140 I could be wrong---there should be something similar though.</pre>
1141
1142 <h3><a name="GRE">Can I build GRE tunnels over IPsec?</a></h3>
1143
1144 <p>This is possible in theory, but we are short on practical details. If you
1145 do this, please let us know via the <a href="mail.html">mailing lists</a>.</p>
1146
1147 <p>There is a <a
1148 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00209.html">list
1149 message</a> with links to relevant resources.</p>
1150
1151 <h2><a name="setup.faq">Life's little mysteries</a></h2>
1152
1153 <p>FreeS/WAN is a fairly complex product. (Neither the networks it runs on
1154 nor the protocols it uses are simple, so it could hardly be otherwise.) It
1155 therefore sometimes exhibits behaviour which can be somewhat confusing, or
1156 has problems which are not easy to diagnose. This section tries to explain
1157 those problems.</p>
1158
1159 <p>Setup and configuration of FreeS/WAN are covered in other documentation
1160 sections:</p>
1161 <ul>
1162   <li><a href="quickstart.html">basic setup and configuration</a></li>
1163   <li><a href="adv_config.html">advanced configuration</a></li>
1164   <li><a href="trouble.html">Troubleshooting</a></li>
1165 </ul>
1166
1167 <p>However, we also list some of the commonest problems here.</p>
1168
1169 <h3><a name="cantping">I cannot ping ....</a></h3>
1170
1171 <p>This question is dealt with in the advanced configuration section under
1172 the heading <a href="adv_config.html#multitunnel">multiple tunnels</a>.</p>
1173
1174 <p>The standard subnet-to-subnet tunnel protects traffic <strong>only between
1175 the subnets</strong>. To test it, you must use pings that go from one subnet
1176 to the other.</p>
1177
1178 <p>For example, suppose you have:</p>
1179 <pre>      subnet a.b.c.0/24
1180              |
1181       eth1 = a.b.c.1
1182          gate1
1183       eth0 = 1.2.3.4
1184              |
1185
1186        ~ internet ~
1187
1188              |
1189       eth0 = 4.3.2.1
1190          gate2
1191       eth1 = x.y.z.1
1192               |
1193        subnet x.y.z.0/24</pre>
1194
1195 <p>and the connection description:</p>
1196 <pre>conn abc-xyz
1197      left=1.2.3.4
1198      leftsubnet=a.b.c.0/24
1199      right=4.3.2.1
1200      rightsubnet=x.y.z.0/24</pre>
1201
1202 <p>You can test this connection description only by sending a ping that will
1203 actually go through the tunnel. Assuming you have machines at addresses
1204 a.b.c.2 and x.y.z.2, pings you might consider trying are:</p>
1205 <dl>
1206   <dt>ping from x.y.z.2 to a.b.c.2 or vice versa</dt>
1207     <dd>Succeeds if tunnel is working. This is the <strong>only valid test of
1208       the tunnel</strong>.</dd>
1209   <dt>ping from gate2 to a.b.c.2 or vice versa</dt>
1210     <dd><strong>Does not use tunnel</strong>. gate2 is not on protected
1211       subnet.</dd>
1212   <dt>ping from gate1 to x.y.z.2 or vice versa</dt>
1213     <dd><strong>Does not use tunnel</strong>. gate1 is not on protected
1214       subnet.</dd>
1215   <dt>ping from gate1 to gate2 or vice versa</dt>
1216     <dd><strong>Does not use tunnel</strong>. Neither gate is on a protected
1217       subnet.</dd>
1218 </dl>
1219
1220 <p>Only the first of these is a useful test of this tunnel. The others do not
1221 use the tunnel. Depending on other details of your setup and routing,
1222 they:</p>
1223 <ul>
1224   <li>either fail, telling you nothing about the tunnel</li>
1225   <li>or succeed, telling you nothing about the tunnel since these packets
1226     use some other route</li>
1227 </ul>
1228
1229 <p>In some cases, you may be able to get around this. For the example network
1230 above, you could use:</p>
1231 <pre>        ping -I a.b.c.1 x.y.z.1</pre>
1232
1233 <p>Both the adresses given are within protected subnets, so this should go
1234 through the tunnel.</p>
1235
1236 <p>If required, you can build additional tunnels so that all the machines
1237 involved can talk to all the others. See <a
1238 href="adv_config.html#multitunnel">multiple tunnels</a> in the advanced
1239 configuration document for details.</p>
1240
1241 <h3><a name="forever">It takes forever to ...</a></h3>
1242
1243 <p>Users fairly often report various problems involving long delays,
1244 sometimes on tunnel setup and sometimes on operations done through the
1245 tunnel, occasionally on simple things like ping or more often on more complex
1246 operations like doing NFS or Samba through the tunnel.</p>
1247
1248 <p>Almost always, these turn out to involve failure of a DNS lookup. The
1249 timeouts waiting for DNS are typically set long so that you won't time out
1250 when a query involves multiple lookups or long paths. Genuine failures
1251 therefore produce long delays before they are detected.</p>
1252
1253 <p>A mailing list message from project technical lead Henry Spencer:</p>
1254 <pre>&gt; ... when i run /etc/rc.d/init.d/ipsec start, i get:
1255 &gt; ipsec_setup: Starting FreeS/WAN IPsec 1.5...
1256 &gt; and it just sits there, doesn't give back my bash prompt.
1257
1258 Almost certainly, the problem is that you're using DNS names in your
1259 ipsec.conf, but DNS lookups are not working for some reason.  You will
1260 get your prompt back... eventually.  But the DNS timeouts are long.
1261 Doing something about this is on our list, but it is not easy.</pre>
1262
1263 <p>In the meanwhile, we recommend that connection descriptions in <a
1264 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> use numeric IP addresses
1265 rather than names which will require a DNS lookup.</p>
1266
1267 <p>Names that do not require a lookup are fine. For example:</p>
1268 <ul>
1269   <li>a road warrior might use the identity
1270     <var>rightid=@lancelot.example.org</var></li>
1271   <li>the gateway might use <var>leftid=@camelot.example.org</var></li>
1272 </ul>
1273
1274 <p>These are fine. The @ sign prevents any DNS lookup. However, do not
1275 attempt to give the gateway address as <var>left=camelot.example.org</var>.
1276 That requires a lookup.</p>
1277
1278 <p>A post from one user after solving a problem with long delays:</p>
1279 <pre>Subject: Final Answer to Delay!!!
1280    Date: Mon, 19 Feb 2001
1281    From: "Felippe Solutions" &lt;felippe@solutionstecnologia.com.br&gt;
1282
1283 Sorry people, but seems like the Delay problem had nothing to do with
1284 freeswan.
1285
1286 The problem was DNS as some people sad from the beginning, but not the way
1287 they thought it was happening. Samba, ssh, telnet and other apps try to
1288 reverse lookup addresses when you use IP numbers (Stupid that ahh).
1289
1290 I could ping very fast because I always ping with "-n" option, but I don't
1291 know the option on the other apps to stop reverse addressing so I don't use
1292 it.</pre>
1293
1294 <p>This post is fairly typical. These problems are often tricky and
1295 frustrating to diagnose, and most turn out to be DNS-related.</p>
1296
1297 <p>One suggestion for diagnosis: test with both names and addresses if
1298 possible. For example, try all of:</p>
1299 <ul>
1300   <li>ping <var>address</var></li>
1301   <li>ping -n <var>address</var></li>
1302   <li>ping <var>name</var></li>
1303 </ul>
1304
1305 <p>If these behave differently, the problem must be DNS-related since the
1306 three commands do exactly the same thing except for DNS lookups.</p>
1307
1308 <h3><a name="route">I send packets to the tunnel with route(8) but they
1309 vanish</a></h3>
1310
1311 <p>IPsec connections are designed to carry only packets travelling between
1312 pre-defined connection endpoints. As project technical lead Henry Spencer put
1313 it:</p>
1314
1315 <blockquote>
1316   IPsec tunnels are not just virtual wires; they are virtual wires with
1317   built-in access controls.  Negotiation of an IPsec tunnel includes
1318   negotiation of access rights for it, which don't include packets to/from
1319   other IP addresses.  (The protocols themselves are quite inflexible about
1320   this, so there are limits to what we can do about it.)</blockquote>
1321
1322 <p>For fairly obvious security reasons, and to comply with the IPsec RFCs, <a
1323 href="glossary.html#KLIPS">KLIPS</a> drops any packets it receives that are
1324 not allowed on the tunnels currently defined. So if you send it packets with
1325 <var>route(8)</var>, and suitable tunnels are not defined, the packets
1326 vanish. Whether this is reported in the logs depends on the setting of
1327 <var>klipsdebug</var> in your <a
1328 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> file.</p>
1329
1330 <p>To rescue vanishing packets, you must ensure that suitable tunnels for
1331 them exist, by editing the connection descriptions in <a
1332 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>. For example, supposing
1333 you have a simple setup:</p>
1334 <pre>         leftsubnet -- leftgateway === internet === roadwarrior</pre>
1335
1336 <p>If you want to give the roadwarrior access to some resource that is
1337 located behind the left gateway but is not in the currently defined left
1338 subnet, then the usual procedure is to define an additional tunnel for those
1339 packets by creating a new connection description.</p>
1340
1341 <p>In some cases, it may be easier to alter an existing connection
1342 description, enlarging the definition of <var>leftsubnet</var>. For example,
1343 instead of two connection descriptions with 192.168.8.0/24 and 192.168.9.0/24
1344 as their <var>leftsubnet</var> parameters, you can use a single description
1345 with 192.168.8.0/23.</p>
1346
1347 <p>If you have multiple endpoints on each side, you need to ensure that there
1348 is a route for each pair of endpoints. See this <a
1349 href="adv_config.html#multitunnel">example</a>.</p>
1350
1351 <h3><a name="down_route">When a tunnel goes down, packets vanish</a></h3>
1352
1353 <p>This is a special case of the vanishing packet problem described in the
1354 previous question. Whenever KLIPS sees packets for which it does not have a
1355 tunnel, it drops them.</p>
1356
1357 <p>When a tunnel goes away, either because negotiations with the other
1358 gateway failed or because you gave an <var>ipsec auto --down</var> command,
1359 the route to its other end is left pointing into KLIPS, and KLIPS will drop
1360 packets it has no tunnel for.</p>
1361
1362 <p>This is a documented design decision, not a bug. FreeS/WAN must not
1363 automatically adjust things to send packets via another route. The other
1364 route might be insecure.</p>
1365
1366 <p>Of course, re-routing may be necessary in many cases. In those cases, you
1367 have to do it manually or via scripts. We provide the <var>ipsec auto
1368 --unroute</var> command for these cases.</p>
1369
1370 <p>From <a href="manpage.d/ipsec_auto.8.html">ipsec_auto(8)</a>:</p>
1371
1372 <blockquote>
1373   Normally,  pluto  establishes  a  route to the destination specified for a
1374   connection as part of the --up  operation. However,  the  route and only
1375   the route can be established with the --route operation.  Until and  unless
1376   an  actual connection  is established, this discards any packets sent
1377   there, which may be preferable to having them  sent elsewhere based  on  a
1378   more  general  route (e.g., a default route).</blockquote>
1379
1380 <blockquote>
1381   Normally, pluto's route to a destination remains in  place when  a  --down
1382   operation  is used to take the connection down (or if connection setup, or
1383   later automatic rekeying, fails).   This permits establishing a new
1384   connection (perhaps using a different specification; the route is altered
1385   as necessary) without having a ``window'' in which packets might go
1386   elsewhere based on a more general route.  Such  a route can be removed
1387   using the --unroute operation (and is implicitly removed by
1388 --delete).</blockquote>
1389
1390 <p>See also this mailing list <a
1391 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00523.html">message</a>.</p>
1392
1393 <h3><a name="firewall_ate">The firewall ate my packets!</a></h3>
1394
1395 <p>If firewalls filter out:</p>
1396 <ul>
1397   <li>either the UDP port 500 packets used in IKE negotiations</li>
1398   <li>or the ESP and AH (protocols 50 and 51) packets used to implement the
1399     IPsec tunnel</li>
1400 </ul>
1401
1402 <p>then IPsec cannot work. The first thing to check if packets seem to be
1403 vanishing is the firewall rules on the two gateway machines and any other
1404 machines along the path that you have access to.</p>
1405
1406 <p>For details, see our document on <a href="firewall.html">firewalls</a>.</p>
1407
1408 <p>Some advice from technical lead Henry Spencer on diagnosing such
1409 problems:</p>
1410 <pre>&gt; &gt; Packets vanishing between the hardware interface and the ipsecN interface
1411 &gt; &gt; is usually the result of firewalls not being configured to let them in...
1412 &gt;
1413 &gt; Thanks for the suggestion. If only it were that simple! My ipchains startup
1414 &gt; script does take care of that, but just in case I manually inserted rules
1415 &gt; accepting everything from london on dublin. No difference.
1416
1417 The other thing to check is whether the "RX packets dropped" count on the
1418 ipsecN interface (run "ifconfig ipsecN", for N=1 or whatever, to see the
1419 counts) is rising.  If so, then there's some sort of configuration mismatch
1420 between the two ends, and IPsec itself is rejecting them.  If none of the
1421 ipsecN counts is rising, then the packets are never reaching the IPsec
1422 machinery, and the problem is almost certainly in firewalls etc.</pre>
1423
1424 <h3><a name="dropconn">Dropped connections</a></h3>
1425
1426 <p>Networks being what they are, IPsec connections can be broken for any
1427 number of reasons, ranging from hardware failures to various software
1428 problems such as the path MTU problems discussed <a
1429 href="#pmtu.broken">elsewhere in the FAQ</a>. Fortunately, various diagnostic
1430 tools exist that help you sort out many of the possible problems.</p>
1431
1432 <p>There is one situation, however, where FreeS/WAN (using default settings)
1433 may destroy a connection for no readily apparent reason. This occurs when
1434 things are <strong>misconfigured</strong> so that <strong>two
1435 tunnels</strong> from the same gateway expect <strong>the same subnet on the
1436 far end</strong>.</p>
1437
1438 <p>In this situation, the first tunnel comes up fine and works until the
1439 second is established. At that point, because of the way we track connections
1440 internally, the first tunnel ceases to exist as far as this gateway is
1441 concerned. Of course the far end does not know that, and a storm of error
1442 messages appears on both systems as it tries to use the tunnel.</p>
1443
1444 <p>If the far end gives up, goes back to square one and negotiates a new
1445 tunnel, then that wipes out the second tunnel and ...</p>
1446
1447 <p>The solution is simple. <strong>Do not build multiple conn descriptions
1448 with the same remote subnet</strong>.</p>
1449
1450 <p>This is actually intended to be a feature, rather than a bug. Consider the
1451 situation where a single remote system goes down, then comes back up and
1452 reconnects to the gateway. It is useful to have the gateway tear down the old
1453 tunnel and recover resources when the reconnection is made. It recognises
1454 that situation by checking the remote subnet for each tunnel it builds and
1455 discarding duplicates. This works fine as long as you don't configure
1456 multiple tunnels with the same remote subnet.</p>
1457
1458 <p>If this behaviour is inconvenient for you, you can disable it by setting
1459 <var>uniqueids=no</var> in <a
1460 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p>
1461
1462 <h3><a name="tcpdump.faq">TCPdump on the gateway shows strange things</a></h3>
1463
1464 <p>Attempting to look at IPsec packets by running monitoring tools on the
1465 IPsec gateway machine can produce silly results. That machine is mangling the
1466 packets for IPsec, and possibly for firewall or NAT purposes as well. If the
1467 internals of the machine's IP stack are not what the monitoring tool expects,
1468 then the tool can misinterpret them and produce nonsense output.</p>
1469
1470 <p>See our <a href="testing.html#tcpdump.test">testing</a> document for more
1471 detail.</p>
1472
1473 <h3><a name="no_trace">Traceroute does not show anything between the
1474 gateways</a></h3>
1475
1476 <p>As far as traceroute can see, the two gateways are one hop apart; the data
1477 packet goes directly from one to the other through the tunnel. Of course the
1478 outer packets that implement the tunnel pass through whatever lies between
1479 the gateways, but those packets are built and dismantled by the gateways.
1480 Traceroute does not see them and cannot report anything about their path.</p>
1481
1482 <p>Here is a mailing list message with more detail.</p>
1483 <pre>Date: Mon, 14 May 2001
1484 To: linux-ipsec@freeswan.org
1485 From: "John S. Denker" &lt;jsd@research.att.com&lt;
1486 Subject: Re: traceroute: one virtual hop
1487
1488 At 02:20 PM 5/14/01 -0400, Claudia Schmeing wrote:
1489 &gt;
1490 &gt;&gt; &gt; A bonus question: traceroute in subnet to subnet enviroment looks like:
1491 &gt;&gt; &gt;
1492 &gt;&gt; &gt; traceroute to andris.dmz (172.20.24.10), 30 hops max, 38 byte packets
1493 &gt;&gt; &gt; 1  drama (172.20.1.1)  0.716 ms  0.942 ms  0.434 ms
1494 &gt;&gt; &gt; 2  * * *
1495 &gt;&gt; &gt; 3  andris.dmz (172.20.24.10)  73.576 ms  78.858 ms  79.434 ms
1496 &gt;&gt; &gt;
1497 &gt;&gt; &gt; Why aren't there the other hosts which take part in the delivery during
1498 &gt;    * * * ?
1499 &gt;
1500 &gt;If there is an ipsec tunnel between GateA and Gate B, this tunnel forms a
1501 &gt;'virtual wire'.  When it is tunneled, the original packet becomes an inner
1502 &gt;packet, and new ESP and/or AH headers are added to create an outer packet
1503 &gt;around it. You can see an example of how this is done for AH at
1504 &gt;doc/ipsec.html#AH . For ESP it is similar.
1505 &gt;
1506 &gt;Think about the packet's path from the inner packet's perspective.
1507 &gt;It leaves the subnet, goes into the tunnel, and re-emerges in the second
1508 &gt;subnet. This perspective is also the only one available to the
1509 &gt;'traceroute' command when the IPSec tunnel is up.
1510
1511 Claudia got this exactly right.  Let me just expand on a couple of points:
1512
1513 *) GateB is exactly one (virtual) hop away from GateA.  This is how it
1514 would be if there were a physically private wire from A to B.  The
1515 virtually private connection should work the same, and it does.
1516
1517 *) While the information is in transit from GateA to GateB, the hop count
1518 of the outer header (the "envelope") is being decremented.  The hop count
1519 of the inner header (the "contents" of the envelope) is not decremented and
1520 should not be decremented.  The hop count of the outer header is not
1521 derived from and should not be derived from the hop count of the inner header.
1522
1523 Indeed, even if the packets did time out in transit along the tunnel, there
1524 would be no way for traceroute to find out what happened.  Just as
1525 information cannot leak _out_ of the tunnel to the outside, information
1526 cannot leak _into_ the tunnel from outside, and this includes ICMP messages
1527 from routers along the path.
1528
1529 There are some cases where one might wish for information about what is
1530 happening at the IP layer (below the tunnel layer) -- but the protocol
1531 makes no provision for this.  This raises all sorts of conceptual issues.
1532 AFAIK nobody has ever cared enough to really figure out what _should_
1533 happen, let alone implement it and standardize it.
1534
1535 *) I consider the "* * *" to be a slight bug.  One might wish for it to be
1536 replaced by "GateB GateB GateB".  It has to do with treating host-to-subnet
1537 traffic different from subnet-to-subnet traffic (and other gory details).
1538 I fervently hope KLIPS2 will make this problem go away.
1539
1540 *) If you want to ask questions about the link from GateA to GateB at the
1541 IP level (below the tunnel level), you have to ssh to GateA and launch a
1542 traceroute from there.</pre>
1543
1544 <h2><a name="man4debug">Testing in stages</a></h2>
1545
1546 <p>It is often useful in debugging to test things one at a time:</p>
1547 <ul>
1548   <li>disable IPsec entirely, for example by turning it off with
1549     chkconfig(8), and make sure routing works</li>
1550   <li>Once that works, try a manually keyed connection. This does not require
1551     key negotiation between Pluto and the key daemon on the other end.</li>
1552   <li>Once that works, try automatically keyed connections</li>
1553   <li>Once IPsec works, add packet compression</li>
1554   <li>Once everything seems to work, try stress tests with large transfers,
1555     many connections, frequent re-keying, ...</li>
1556 </ul>
1557
1558 <p>FreeS/WAN releases are tested for all of these, so you can be reasonably
1559 certain they <em>can</em> do them all. Of course, that does not mean they
1560 <em>will</em> on the first try, especially if you have some unusual
1561 configuration.</p>
1562
1563 <p>The rest of this section gives information on diagnosing the problem when
1564 each of the above steps fails.</p>
1565
1566 <h3><a name="nomanual">Manually keyed connections don't work</a></h3>
1567
1568 <p>Suspect one of:</p>
1569 <ul>
1570   <li>mis-configuration of IPsec system in the /etc/ipsec.conf file<br>
1571     common errors are incorrect interface or next hop information</li>
1572   <li>mis-configuration of manual connection in the /etc/ipsec.conf file</li>
1573   <li>routing problems causing IPsec packets to be lost</li>
1574   <li>bugs in KLIPS</li>
1575   <li>mismatch between the transforms we support and those another IPsec
1576     implementation offers.</li>
1577 </ul>
1578
1579 <h3><a name="spi_error">One manual connection works, but second one
1580 fails</a></h3>
1581
1582 <p>This is a fairly common problem when attempting to configure multiple
1583 manually keyed connections from a single gateway.</p>
1584
1585 <p>Each connection must be identified by a unique <a
1586 href="glossary.html#SPI">SPI</a> value. For automatic connections, these
1587 values are assigned automatically. For manual connections, you must set them
1588 with <var>spi=</var> statements in <a
1589 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p>
1590
1591 <p>Each manual connection must have a unique SPI value in the range 0x100 to
1592 0x999. Two or more with the same value will fail. For details, see our doc
1593 section <a href="adv_config.html#prodman">Using manual keying in
1594 production</a> and the man page <a
1595 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p>
1596
1597 <h3><a name="man_no_auto">Manual connections work, but automatic keying
1598 doesn't</a></h3>
1599
1600 <p>The most common reason for this behaviour is a firewall dropping the UDP
1601 port 500 packets used in key negotiation.</p>
1602
1603 <p>Other possibilities:</p>
1604 <ul>
1605   <li>mis-configuration of auto connection in the /etc/ipsec.conf file.
1606     <p>One common configuration error is forgetting that you need
1607     <var>auto=add</var> to load the connection description on the receiving
1608     end so it recognises the connection when the other end asks for it.</p>
1609   </li>
1610   <li>error in shared secret in /etc/ipsec.secrets</li>
1611   <li>one gateway lacks a route to the other so Pluto's UDP packets are
1612   lost</li>
1613   <li>bugs in Pluto</li>
1614   <li>incompatibilities between Pluto's <a href="glossary.html#IKE">IKE</a>
1615     implementation and the IKE at the other end of the tunnel.
1616     <p>Some possibile problems are discussed in out <a
1617     href="interop.html#interop.problem">interoperation</a> document.</p>
1618   </li>
1619 </ul>
1620
1621 <h3><a name="nocomp">IPsec works, but connections using compression
1622 fail</a></h3>
1623
1624 <p>When we first added compression, we saw some problems:</p>
1625 <ul>
1626   <li>compatibility issues with other implementations. We followed the RFCs
1627     and omitted some extra material that many compression libraries add by
1628     default. Some other implementations left the extras in</li>
1629   <li>bugs in assembler compression routines on non-Intel CPUs. The
1630     workaround is to use C code instead of possibly problematic
1631   assembler.</li>
1632 </ul>
1633
1634 <p>We have not seen either problem in some time (at least six months as I
1635 write in March 2002), but if you have some unusual configuration then you may
1636 see them.</p>
1637
1638 <h3><a name="pmtu.broken">Small packets work, but large transfers
1639 fail</a></h3>
1640
1641 <p>If tests with ping(1) and a small packet size succeed, but tests or
1642 transfers with larger packet sizes fail, suspect problems with packet
1643 fragmentation and perhaps <a href="glossary.html#pathMTU">path MTU
1644 discovery</a>.</p>
1645
1646 <p>Our <a href="trouble.html#bigpacket">troubleshooting document</a> covers
1647 these problems. Information on the underlying mechanism is in our <a
1648 href="background.html#MTU.trouble">background</a> document.</p>
1649
1650 <h3><a name="subsub">Subnet-to-subnet works, but tests from the gateways
1651 don't</a></h3>
1652
1653 <p>This is described under <a href="#cantping">I cannot ping...</a> above.</p>
1654
1655 <h2><a name="compile.faq">Compilation problems</a></h2>
1656
1657 <h3><a name="gmp.h_missing">gmp.h: No such file or directory</a></h3>
1658
1659 <p>Pluto needs the GMP (<strong>G</strong>NU</p>
1660
1661 <p><strong>M</strong>ulti-<strong>P</strong>recision) library for the large
1662 integer calculations it uses in <a href="glossary.html#public">public key</a>
1663 cryptography. This error message indicates a failure to find the library. You
1664 must install it before Pluto will compile.</p>
1665
1666 <p>The GMP library is included in most Linux distributions. Typically, there
1667 are two RPMs, libgmp and libgmp-devel, You need to <em>install both</em>,
1668 either from your distribution CDs or from your vendor's web site.</p>
1669
1670 <p>On Debian, a mailing list message reports that the command to give is
1671 <nobr><var>apt-get install gmp2</var></nobr>.</p>
1672
1673 <p>For more information and the latest version, see the <a
1674 href="http://www.swox.com/gmp/">GMP home page</a>.</p>
1675
1676 <h3><a name="noVM">... virtual memory exhausted</a></h3>
1677
1678 <p>We have had several reports of this message appearing, all on SPARC Linux.
1679 Here is a mailing message on a solution:</p>
1680 <pre>&gt; ipsec_sha1.c: In function `SHA1Transform':
1681 &gt; ipsec_sha1.c:95: virtual memory exhausted
1682
1683 I'm seeing exactly the same problem on an Ultra with 256MB ram and 500
1684 MB swap.  Except I am compiling version 1.5 and its Red Hat 6.2.
1685
1686 I can get around this by using -O instead of -O2 for the optimization
1687 level.  So it is probably a bug in the optimizer on the sparc complier.
1688 I'll try and chase this down on the sparc lists.</pre>
1689
1690 <h2><a name="error">Interpreting error messages</a></h2>
1691
1692 <h3><a name="route-client">route-client (or host) exited with status
1693 7</a></h3>
1694
1695 <p>Here is a discussion of this error from FreeS/WAN "listress" (mailing list
1696 tech support person) Claudia Schmeing. The "FAQ on the network unreachable
1697 error" which she refers to is the next question below.</p>
1698 <pre>&gt; I reached the point where the two boxes (both on dial-up connections, but
1699 &gt; treated as static IPs by getting the IP and editing ipsec.conf after the
1700 &gt; connection is established) to the point where they exchange some info, but I
1701 &gt; get an error like "route-client command exited with status 7 \n internal
1702 &gt; error".
1703 &gt; Where can I find a description of this error?
1704
1705 In general, if the FAQ doesn't cover it, you can search the mailing list
1706 archives - I like to use
1707 http://www.sandelman.ottawa.on.ca/linux-ipsec/
1708 but you can see doc/mail.html for different archive formats.
1709
1710
1711 Your error comes from the _updown script, which performs some
1712 routing and firewall functions to help Linux FreeS/WAN. More info
1713 is available at doc/firewall.html and man ipsec.conf. Its routing
1714 is integral to the health of Linux FreeS/WAN; it also provides facility
1715 to insert custom firewall rules to be executed when you create or destroy
1716 a connection.
1717
1718 Yours is, of course, a routing error. You can be fairly sure the routing
1719 machinery is saying "network is unreachable". There's a FAQ on the
1720 "network is unreachable" error, but more information is available now; read on.
1721
1722 If your _updown script is recent (for example if it shipped with
1723 Linux FreeS/WAN 1.91), you will see another debugging line in your logs
1724 that looks something like this:
1725
1726 &gt; output: /usr/local/lib/ipsec/_updown: `route add -net 128.174.253.83
1727 &gt; netmask 255.255.255.255 dev ipsec0 gw 66.92.93.161' failed
1728
1729 This is, of course, the system route command that exited with status 7,
1730 (ie. failed). Man route for details. Seeing the command typed out yields
1731 more information. If your _updown script is older, you may wish to update
1732 it to show the command explicitly.
1733
1734 Three parameters fed to the route command: net, netmask and gw [gateway]
1735 are derived from things you've put in ipsec.conf.
1736
1737 Net and netmask are derived from the peer's IP and mask. In more detail:
1738
1739 You may see a routing error when routing to a client (ie. subnet), or
1740 to a host (IPSec gateway or freestanding host; a box that does IPSec for
1741 itself). In _updown, the "route-client" section  is responsible to set up
1742 the route for IPSec'd (usually, read 'tunneled') packets headed to a
1743 peer subnet. Similarly, route-host routes IPSec'd packets to a peer host
1744 or IPSec gateway.
1745
1746 When routing to a 'client', net and netmask are ipsec.conf's left- or
1747 rightsubnet (whichever is not local). Similarly, when routing to a
1748 'host' the net is left or right. Host netmask is always /32, indicating a
1749 single machine.
1750
1751 Gw is nexthop's value. Again, the value in question is left- or rightnexthop,
1752 whichever is local. Where left/right or left-/rightnexthop has the special
1753 value %defaultroute (described in man ipsec.conf), gw will automagically get
1754 the value of the next hop on the default route.
1755
1756 Q: "What's a nexthop and why do I need one?"
1757
1758 A: 'nexthop' is a routing kluge; its value is the next hop away
1759    from the machine that's doing IPSec, and toward your IPSec peer.
1760    You need it to get the processed packets out of the local system and
1761    onto the wire. While we often route other packets through the machine
1762    that's now doing IPSec, and are done with it, this does not suffice here.
1763    After packets are processed with IPSec, this machine needs to know where
1764    they go next. Of course using the 'IPSec gateway' as their routing gateway
1765    would cause an infinite loop! [To visualize this, see the packet flow
1766    diagram at doc/firewall.html.] To avoid this, we route packets through
1767    the next hop down their projected path.
1768
1769 Now that you know the background, consider:
1770 1. Did you test routing between the gateways in the absence of Linux
1771    FreeS/WAN, as recommended? You need to ensure the two machines that
1772    will be running Linux FreeS/WAN can route to one another before trying to
1773    make a secure connection.
1774 2. Is there anything obviously wrong with the sense of your route command?
1775
1776 Normally, this problem is caused by an incorrect local nexthop parameter.
1777 Check out the use of %defaultroute, described in man ipsec.conf. This is
1778 a simple way to set nexthop for most people. To figure nexthop out by hand,
1779 traceroute in-the-clear to your IPSec peer. Nexthop is the traceroute's
1780 first hop after your IPSec gateway.</pre>
1781
1782 <h3><a name="unreachable">SIOCADDRT:Network is unreachable</a></h3>
1783
1784 <p>This message is not from FreeS/WAN, but from the Linux IP stack itself.
1785 That stack is seeing packets it has no route for, either because your routing
1786 was broken before FreeS/WAN started or because FreeS/WAN's changes broke
1787 it.</p>
1788
1789 <p>Here is a message from Claudia suggesting ways to diagnose and fix such
1790 problems:</p>
1791 <pre>You write,
1792 &gt; I have correctly installed freeswan-1.8 on RH7.0 kernel 2.2.17, but when
1793 &gt; I setup a VPN connection with the other machine(RH5.2 Kernel 2.0.36
1794 &gt; freeswan-1.0, it works well.) it told me that
1795 &gt; "SIOCADDRT:Network is unreachable"!  But the network connection is no
1796 &gt; problem.
1797
1798 Often this error is the result of a misconfiguration.
1799
1800 Be sure that you can route successfully in the absence of Linux
1801 FreeS/WAN. (You say this is no problem, so proceed to the next step.)
1802
1803 Use a custom copy of the default updownscript. Do not change the route
1804 commands, but add a diagnostic message revealing the exact text of the
1805 route command. Is there a problem with the sense of the route command
1806 that you can see? If so, then re-examine those ipsec.conf settings
1807 that are being sent to the route command.
1808
1809 You may wish to use the ipsec auto --route and --unroute commands to
1810 troubleshoot the problem. See man ipsec_auto for details.</pre>
1811
1812 <p>Since the above message was written, we have modified the updown script to
1813 provide a better diagnostic for this problem. Check
1814 <var>/var/log/messages</var>.</p>
1815
1816 <p>See also the FAQ question <a href="#route-client">route-client (or host)
1817 exited with status 7</a>.</p>
1818
1819 <h3><a name="modprobe">ipsec_setup: modprobe: Can't locate module
1820 ipsec</a></h3>
1821
1822 <h3><a name="noKLIPS">ipsec_setup: Fatal error, kernel appears to lack
1823 KLIPS</a></h3>
1824
1825 <p>These messages indicate an installation failure. The kernel you are
1826 running does not contain the <a href="glossary.html#KLIPS">KLIPS (kernel
1827 IPsec)</a> code.</p>
1828
1829 <p>Note that the "modprobe: Can't locate module ipsec" message appears even
1830 if you are not using modules. If there is no KLIPS in your kernel, FreeS/WAN
1831 tries to load it as a module. If that fails, you get this message.</p>
1832
1833 <p>Commands you can quickly try are:</p>
1834 <dl>
1835   <dt><var>uname -a</var></dt>
1836     <dd>to get details, including compilation date and time, of the currently
1837       running kernel</dd>
1838   <dt><var>ls /</var></dt>
1839   <dt><var>ls /boot</var></dt>
1840     <dd>to ensure a new kernel is where it should be. If kernel compilation
1841       puts it in <var>/</var> but <var>lilo</var> wants it in
1842       <var>/boot</var>, then you should uncomment the
1843       <var>INSTALL_PATH=/boot</var> line in the kernel
1844     <var>Makefile</var>.</dd>
1845   <dt><var>more /etc/lilo.conf</var></dt>
1846     <dd>to see that <var>lilo</var> has correct information</dd>
1847   <dt><var>lilo</var></dt>
1848     <dd>to ensure that information in <var>/etc/lilo.conf</var> has been
1849       transferred to the boot sector</dd>
1850 </dl>
1851
1852 <p>If those don't find the problem, you have to go back and check through the
1853 <a href="install.html">install</a> procedure to see what was missed.</p>
1854
1855 <p>Here is one of Claudia's messages on the topic:</p>
1856 <pre>&gt; I tried to install freeswan 1.8 on my mandrake 7.2 test box. ...
1857
1858 &gt; It does show version and some output for whack.
1859
1860 Yes, because the Pluto (daemon) part of ipsec is installed correctly, but
1861 as we see below the kernel portion is not.
1862
1863 &gt; However, I get the following from /var/log/messages:
1864 &gt;
1865 &gt; Mar 11 22:11:55 pavillion ipsec_setup: Starting FreeS/WAN IPsec 1.8...
1866 &gt; Mar 11 22:12:02 pavillion ipsec_setup: modprobe: Can't locate module ipsec
1867 &gt; Mar 11 22:12:02 pavillion ipsec_setup: Fatal error, kernel appears to lack
1868 &gt; KLIPS.
1869
1870 This is your problem. You have not successfully installed a kernel with
1871 IPSec machinery in it.
1872
1873 Did you build Linux FreeS/WAN as a module? If so, you need to ensure that
1874 your new module has been installed in the directory where your kernel
1875 loader normally finds your modules. If not, you need to ensure
1876 that the new IPSec-enabled kernel is being loaded correctly.
1877
1878 See also doc/install.html, and INSTALL in the distro.</pre>
1879
1880 <h3><a name="noDNS">ipsec_setup: ... failure to fetch key for ... from
1881 DNS</a></h3>
1882
1883 <p>Quoting Henry:</p>
1884 <pre>Note that by default, FreeS/WAN is now set up to
1885      (a) authenticate with RSA keys, and
1886      (b) fetch the public key of the far end from DNS.
1887 Explicit attention to  ipsec.conf will be needed if you want
1888 to do something different.</pre>
1889
1890 <p>and Claudia, responding to the same user:</p>
1891 <pre>You write,
1892
1893 &gt;       My current setup in ipsec.conf is leftrsasigkey=%dns I have
1894 &gt; commented this and authby=rsasig out. I am able to get ipsec running,
1895 &gt; but what I find is that the documentation only specifies for %dns are
1896 &gt; there any other values that can be placed in this variable other than
1897 &gt; %dns and the key? I am also assuming that this is where I would place
1898 &gt; my public key for the left and right side as well is this correct?
1899
1900 Valid values for authby= are rsasig and secret, which entail authentication
1901 by RSA signature or by shared secret, respectively. Because you have
1902 commented authby=rsasig out, you are using the default value of authby=secret.
1903
1904 When using RSA signatures, there are two ways to get the public key for the
1905 IPSec peer: either copy it directly into *rsasigkey= in ipsec.conf, or
1906 fetch it from dns. The magic value %dns for *rsasigkey parameters says to
1907 try to fetch the peer's key from dns.
1908
1909 For any parameters, you may find their significance and special values in
1910 man ipsec.conf. If you are setting up keys or secrets, be sure also to
1911 reference man ipsec.secrets.</pre>
1912
1913 <h3><a name="dup_address">ipsec_setup: ... interfaces ... and ... share
1914 address ...</a></h3>
1915
1916 <p>This is a fatal error. FreeS/WAN cannot cope with two or more interfaces
1917 using the same IP address. You must re-configure to avoid this.</p>
1918
1919 <p>A mailing list message on the topic from Pluto developer Hugh
1920 Redelmeier:</p>
1921 <pre>| I'm trying to get freeswan working between two machine where one has a ppp
1922 | interface.
1923 | I've already suceeded with  two machines with ethernet ports but  the ppp
1924 | interface is causing me problems.
1925 |  basically when I run ipsec start  i get
1926 | ipsec_setup: Starting FreeS/WAN IPsec 1.7...
1927 | ipsec_setup: 003 IP interfaces ppp1 and ppp0 share address 192.168.0.10!
1928 | ipsec_setup: 003 IP interfaces ppp1 and ppp2 share address 192.168.0.10!
1929 | ipsec_setup: 003 IP interfaces ppp0 and ppp2 share address 192.168.0.10!
1930 | ipsec_setup: 003 no public interfaces found
1931 |
1932 | followed by lots of cannot work out interface for connection messages
1933 |
1934 | now I can specify the interface in ipsec.conf to be ppp0 , but this does
1935 | not affect the above behaviour. A quick look in server.c indicates that the
1936 | interfaces value  is not used but some sort of raw detect happens.
1937 |
1938 | I guess I could prevent the formation of the extra ppp interfaces or
1939 | allocate them different ip but I'd  rather not. if at all possible. Any
1940 | suggestions please.
1941
1942 Pluto won't touch an interface that shares an IP address with another.
1943 This will eventually change, but it probably won't happen soon.
1944
1945 For now, you will have to give the ppp1 and ppp2 different addresses.</pre>
1946
1947 <h3><a name="kflags">ipsec_setup: Cannot adjust kernel flags</a></h3>
1948
1949 <p>A mailing list message form technical lead Henry Spencer:</p>
1950 <pre>&gt; When FreeS/WAN IPsec 1.7 is starting on my 2.0.38 Linux kernel the following
1951 &gt; error message is generated:
1952 &gt; ipsec_setup: Cannot adjust kernel flags, no /proc/sys/net/ipsec directory!
1953 &gt; What is supposed to create this directory and how can I fix this problem?
1954
1955 I think that directory is a 2.2ism, although I'm not certain (I don't have
1956 a 2.0.xx system handy any more for testing).  Without it, some of the
1957 ipsec.conf config-setup flags won't work, but otherwise things should
1958 function. </pre>
1959
1960 <p>You also need to enable the <var>/proc</var> filesystem in your kernel
1961 configuration for these operations to work.</p>
1962
1963 <h3><a name="message_num">Message numbers (MI3, QR1, et cetera) in Pluto
1964 messages</a></h3>
1965
1966 <p>Pluto messages often indicate  where Pluto is in the IKE protocols. The
1967 letters indicate <strong>M</strong>ain mode or <strong>Q</strong>uick mode
1968 and <strong>I</strong>nitiator or <strong>R</strong>esponder. The numerals
1969 are message sequence numbers. For more detail, see our <a
1970 href="ipsec.html#sequence">IPsec section</a>.</p>
1971
1972 <h3><a name="conn_name">Connection names in Pluto error messages</a></h3>
1973
1974 <p>From Pluto programmer Hugh Redelmeier:</p>
1975 <pre>| Jan 17 16:21:10 remus Pluto[13631]: "jumble" #1: responding to Main Mode from Road Warrior 130.205.82.46
1976 | Jan 17 16:21:11 remus Pluto[13631]: "jumble" #1: no suitable connection for peer @banshee.wittsend.com
1977 |
1978 |     The connection "jumble" has nothing to do with the incoming
1979 | connection requests, which were meant for the connection "banshee".
1980
1981 You are right.  The message tells you which Connection Pluto is
1982 currently using, which need not be the right one.  It need not be the
1983 right one now for the negotiation to eventually succeed!  This is
1984 described in ipsec_pluto(8) in the section "Road Warrior Support".
1985
1986 There are two times when Pluto will consider switching Connections for
1987 a state object.  Both are in response to receiving ID payloads (one in
1988 Phase 1 / Main Mode and one in Phase 2 / Quick Mode).  The second is
1989 not unique to Road Warriors.  In fact, neither is the first any more
1990 (two connections for the same pair of hosts could differ in Phase 1 ID
1991 payload; probably nobody else has tried this).</pre>
1992
1993 <h3><a name="cantorient">Pluto: ... can't orient connection</a></h3>
1994
1995 <p>Older versions of FreeS/WAN used this message. The same error now gives
1996 the "we have no ipsecN ..." error described just below.</p>
1997
1998 <h3><a name="no.interface">... we have no ipsecN interface for either end of
1999 this connection</a></h3>
2000
2001 <p>Each Pluto needs to know whether it is running on the machine which the
2002 connection description calls <var>left</var> or on <var>right</var>. It
2003 figures that out by:</p>
2004 <ul>
2005   <li>looking at the interfaces given in <var>interfaces=</var> lines in the
2006     <var>config setup</var> section</li>
2007   <li>discovering the IP addresses for those interfaces</li>
2008   <li>searching for a match between those addresses and the ones given in
2009     <var>left=</var> or <var>right=</var> lines.</li>
2010 </ul>
2011
2012 <p>Normally a match is found. Then Pluto knows where it is and can set up
2013 other things (for example, if it is <var>left</var>) using parameters such as
2014 <var>leftsubnet</var> and <var>leftnexthop</var>, and sending its outgoing
2015 packets to <var>right</var>.</p>
2016
2017 <p>If no match is found, it emits the above error message.</p>
2018
2019 <h3><a name="noconn">Pluto: ... no connection is known</a></h3>
2020
2021 <p>This error message occurs when a remote system attempts to negotiate a
2022 connection and Pluto does not have a connection description that matches what
2023 the remote system has requested. The most common cause is a configuration
2024 error on one end or the other.</p>
2025
2026 <p>Parameters involved in this match are <var>left</var>, <var>right</var>,
2027 <var>leftsubnet</var> and <var>rightsubnet</var>.</p>
2028
2029 <p><strong>The match must be exact</strong>. For example, if your left subnet
2030 is a.b.c.0/24 then neither a single machine in that net nor a smaller subnet
2031 such as a.b.c.64/26 will be considered a match.</p>
2032
2033 <p>The message can also occur when an appropriate description exists but
2034 Pluto has not loaded it. Use an <var>auto=add</var> statement in the
2035 connection description, or an <var>ipsec auto --add &lt;conn_name&gt;</var>
2036 command, to correct this.</p>
2037
2038 <p>An explanation from the Pluto developer:</p>
2039 <pre>| Jul 12 15:00:22 sohar58 Pluto[574]: "corp_road" #2: cannot respond to IPsec
2040 | SA request because no connection is known for
2041 | 216.112.83.112/32===216.112.83.112...216.67.25.118
2042
2043 This is the first message from the Pluto log showing a problem.  It
2044 means that PGPnet is trying to negotiate a set of SAs with this
2045 topology:
2046
2047 216.112.83.112/32===216.112.83.112...216.67.25.118
2048 ^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^   ^^^^^^^^^^^^^
2049 client on our side  our host         PGPnet host, no client
2050
2051 None of the conns you showed look like this.
2052
2053 Use
2054         ipsec auto --status
2055 to see a snapshot of what connections are in pluto, what
2056 negotiations are going on, and what SAs are established.
2057
2058 The leftsubnet= (client) in your conn is 216.112.83.64/26.  It must
2059 exactly match what pluto is looking for, and it does not.</pre>
2060
2061 <h3><a name="nosuit">Pluto: ... no suitable connection ...</a></h3>
2062
2063 <p>This is similar to the <a href="#noconn">no connection known</a> error,
2064 but occurs at a different point in Pluto processing.</p>
2065
2066 <p>Here is one of Claudia's messages explaining the problem:</p>
2067 <pre>You write,
2068
2069 &gt; What could be the reason of the following error?
2070 &gt; "no suitable connection for peer '@xforce'"
2071
2072 When a connection is initiated by the peer, Pluto must choose which entry in
2073 the conf file best matches the incoming connection. A preliminary choice is
2074 made on the basis of source and destination IPs, since that information is
2075 available at that time.
2076
2077 A payload containing an ID arrives later in the negotiation. Based on this
2078 id and the *id= parameters, Pluto refines its conn selection. ...
2079
2080 The message "no suitable connection" indicates that in this refining step,
2081 Pluto does not find a connection that matches that ID.
2082
2083 Please see "Selecting a connection when responding" in man ipsec_pluto for
2084 more details.</pre>
2085
2086 <p>See also <a href="#conn_name">Connection names in Pluto error
2087 messages</a>.</p>
2088
2089 <h3><a name="noconn.auth">Pluto: ... no connection has been
2090 authorized</a></h3>
2091
2092 <p>Here is one of Claudia's messages discussing this problem:</p>
2093 <pre>You write,
2094
2095 &gt;  May 22 10:46:31 debian Pluto[25834]: packet from x.y.z.p:10014:
2096 &gt;  initial Main Mode message from x.y.z.p:10014
2097                             but no connection has been authorized
2098
2099 This error occurs early in the connection negotiation process,
2100 at the first step of IKE negotiation (Main Mode), which is itself the
2101 first of two negotiation phases involved in creating an IPSec connection.
2102
2103 Here, Linux FreeS/WAN receives a packet from a potential peer, which
2104 requests that they begin discussing a connection.
2105
2106 The "no connection has been authorized" means that there is no connection
2107 description in Linux FreeS/WAN's internal database that can be used to
2108 link your ipsec interface with that peer.
2109
2110 "But of course I configured that connection!"
2111
2112 It may be that the appropriate connection description exists in ipsec.conf
2113 but has not been added to the database with ipsec auto --add myconn or the
2114 auto=add method. Or, the connection description may be misconfigured.
2115
2116 The only parameters that are relevant in this decision are left= and right= .
2117 Local and remote ports are also taken into account -- we see that the port
2118 is printed in the message above -- but there is no way to control these
2119 in ipsec.conf.
2120
2121
2122 Failure at "no connection has been authorized" is similar to the
2123 "no connection is known for..." error in the FAQ, and the "no suitable
2124 connection" error described in the snapshot's FAQ. In all three cases,
2125 Linux FreeS/WAN is trying to match parameters received in the
2126 negotiation with the connection description in the local config file.
2127
2128 As it receives more information, its matches take more parameters into
2129 account, and become more precise:  first the pair of potential peers,
2130 then the peer IDs, then the endpoints (including any subnets).
2131
2132 The "no suitable connection for peer *" occurs toward the end of IKE
2133 (Main Mode) negotiation, when the IDs are matched.
2134
2135 "no connection is known for a/b===c...d" is seen at the beginning of IPSec
2136 (Quick Mode, phase 2) negotiation, when the connections are matched using
2137 left, right, and any information about the subnets.</pre>
2138
2139 <h3><a name="noDESsupport">Pluto: ... OAKLEY_DES_CBC is not
2140 supported.</a></h3>
2141
2142 <p>This message occurs when the other system attempts to negotiate a
2143 connection using <a href="glossary.html#DES">single DES</a>, which we do not
2144 support because it is <a href="politics.html#desnotsecure">insecure</a>.</p>
2145
2146 <p>Our interoperation document has suggestions for <a
2147 href="interop.html#noDES">how to deal with</a> systems that attempt to use
2148 single DES.</p>
2149
2150 <h3><a name="notransform">Pluto: ... no acceptable transform</a></h3>
2151
2152 <p>This message means that the other gateway has made a proposal for
2153 connection parameters, but nothing they proposed is acceptable to Pluto.
2154 Possible causes include:</p>
2155 <ul>
2156   <li>misconfiguration on either end</li>
2157   <li>policy incompatibilities, for example we require encrypted connections
2158     but they are trying to create one with just authentication</li>
2159   <li>interoperation problems, for example they offer only single DES and
2160     FreeS/WAN does not support that. See <a
2161     href="interop.html#interop.problem">discussion</a> in our interoperation
2162     document.</li>
2163 </ul>
2164
2165 <p>A more detailed explanation, from Pluto programmer Hugh Redelmeier:</p>
2166 <pre>Background:
2167
2168 When one IKE system (for example, Pluto) is negotiating with another
2169 to create an SA, the Initiator proposes a bunch of choices and the
2170 Responder replies with one that it has selected.
2171
2172 The structure of the choices is fairly complicated.  An SA payload
2173 contains a list of lists of "Proposals".  The outer list is a set of
2174 choices: the selection must be from one element of this list.
2175
2176 Each of these elements is a list of Proposals.  A selection must be
2177 made from each of the elements of the inner list.  In other words,
2178 *all* of them apply (that is how, for example, both AH and ESP can
2179 apply at once).
2180
2181 Within each of these Proposals is a list of Transforms.  For each
2182 Proposal selected, one Transform must be selected (in other words,
2183 each Proposal provides a choice of Transforms).
2184
2185 Each Transform is made up of a list of Attributes describing, well,
2186 attributes.  Such as lifetime of the SA.  Such as algorithm to be
2187 used.  All the Attributes apply to a Transform.
2188
2189 You will have noticed a pattern here: layers alternate between being
2190 disjunctions ("or") and conjunctions ("and").
2191
2192 For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
2193 cut back.  There must be exactly one Proposal.  So this degenerates to
2194 a list of Transforms, one of which must be chosen.
2195
2196 In your case, no proposal was considered acceptable to Pluto (the
2197 Responder).  So negotiation ceased.  Pluto logs the reason it rejects
2198 each Transform.  So look back in the log to see what is going wrong.</pre>
2199
2200 <h3><a name="rsasigkey">rsasigkey dumps core</a></h3>
2201 A comment on this error from Henry:
2202 <pre>On Fri, 29 Jun 2001, Rodrigo Gruppelli wrote:
2203 &gt; ...Well, it seem that there's
2204 &gt; another problem with it. When I try to generate a pair of RSA keys,
2205 &gt; rsasigkey cores dump...
2206
2207 *That* is a neon sign flashing "GMP LIBRARY IS BROKEN".  Rsasigkey calls
2208 GMP a lot, and our own library a little bit, and that's very nearly all it
2209 does.  Barring bugs in its code or our library -- which have happened, but
2210 not very often -- a problem in rsasigkey is a problem in GMP.</pre>
2211
2212 <p>See the next question for how to deal with GMP errors.</p>
2213
2214 <h3><a name="sig4">!Pluto failure!: ... exited with ... signal 4</a></h3>
2215
2216 <p>Pluto has died. Signal 4 is SIGILL, illegal instruction.</p>
2217
2218 <p>The most likely cause is that your <a href="glossary.html#GMP">GMP</a>
2219 (GNU multi-precision) library is compiled for a different processor than what
2220 you are running on. Pluto uses that library for its public key
2221 calculations.</p>
2222
2223 <p>Try getting the GMP sources and recompile for your processor type. Most
2224 Linux distributions will include this source, or you can download it from the
2225 <a href="http://www.swox.com/gmp/">GMP home page</a>.</p>
2226
2227 <h3><a name="econnrefused">ECONNREFUSED error message</a></h3>
2228
2229 <p>From John Denker, on the mailing list:</p>
2230 <pre>1)  The log message
2231   some IKE message we sent has been rejected with
2232   ECONNREFUSED (kernel supplied no details)
2233 is much more suitable than the previous version.  Thanks.
2234
2235 2) Minor suggestion for further improvement: it might be worth mentioning
2236 that the command
2237   tcpdump -i eth1 icmp[0] != 8 and icmp[0] != 0
2238 is useful for tracking down the details in question.  We shouldn't expect
2239 all IPsec users to figure that out on their own.  The log message might
2240 even provide a hint as to where to look in the docs.</pre>
2241
2242 <p>Reply From Pluto developer Hugh Redelmeier</p>
2243 <pre>Good idea.
2244
2245 I've added a bit pluto(8)'s BUGS section along these lines.
2246 I didn't have the heart to lengthen this message.</pre>
2247
2248 <h3><a name="no_eroute">klips_debug: ... no eroute!</a></h3>
2249
2250 <p>This message means <a href="glossary.html#KLIPS">KLIPS</a> has received a
2251 packet for which no IPsec tunnel has been defined.</p>
2252
2253 <p>Here is a more detailed duscussion from the team's tech support person
2254 Claudia Schmeing, responding to a query on the mailing list:</p>
2255 <pre>&gt; Why ipsec reports no eroute! ???? IP Masq... is disabled.
2256
2257 In general, more information is required so that people on the list may
2258 give you informed input. See doc/prob.report.</pre>
2259
2260 <p>The document she refers to has since been replaced by a <a
2261 href="trouble.html#prob.report">section</a> of the troubleshooting
2262 document.</p>
2263 <pre>However, I can make some general comments on this type of error.
2264
2265 This error usually looks something like this (clipped from an archived
2266 message):
2267
2268 &gt; ttl:64 proto:1 chk:45459 saddr:192.168.1.2 daddr:192.168.100.1
2269 &gt; ... klips_debug:ipsec_findroute: 192.168.1.2-&gt;192.168.100.1
2270 &gt; ... klips_debug:rj_match: * See if we match exactly as a host destination
2271 &gt; ... klips_debug:rj_match: ** try to match a leaf, t=0xc1a260b0
2272 &gt; ... klips_debug:rj_match: *** start searching up the tree, t=0xc1a260b0
2273 &gt; ... klips_debug:rj_match: **** t=0xc1a260c8
2274 &gt; ... klips_debug:rj_match: **** t=0xc1fe5960
2275 &gt; ... klips_debug:rj_match: ***** not found.
2276 &gt; ... klips_debug:ipsec_tunnel_start_xmit: Original head/tailroom: 2, 28
2277 &gt; ... klips_debug:ipsec_tunnel_start_xmit: no eroute!: ts=47.3030, dropping.
2278
2279
2280 What does this mean?
2281 - --------------------
2282
2283 "eroute" stands for "extended route", and is a special type of route
2284 internal to Linux FreeS/WAN. For more information about this type of route,
2285 see the section of man ipsec_auto on ipsec auto --route.
2286
2287 "no eroute!" here means, roughly, that Linux FreeS/WAN cannot find an
2288 appropriate tunnel that should have delivered this packet. Linux
2289 FreeS/WAN therefore drops the packet, with the message "no eroute! ...
2290 dropping", on the assumption that this packet is not a legitimate
2291 transmission through a properly constructed tunnel.
2292
2293
2294 How does this situation come about?
2295 - -----------------------------------
2296
2297 Linux FreeS/WAN has a number of connection descriptions defined in
2298 ipsec.conf. These must be successfully brought "up" to form actual tunnels.
2299 (see doc/setup.html's step 15, man ipsec.conf and man ipsec_auto
2300 for details).
2301
2302 Such connections are often specific to the endpoints' IPs. However, in
2303 some cases they may be more general, for example in the case of
2304 Road Warriors where left or right is the special value %any.
2305
2306 When Linux FreeS/WAN receives a packet, it verifies that the packet has
2307 come through a legitimate channel, by checking that there is an
2308 appropriate tunnel through which this packet might legitimately have
2309 arrived. This is the process we see above.
2310
2311 First, it checks for an eroute that exactly matches the packet. In the
2312 example above, we see it checking for a route that begins at 192.168.1.2
2313 and ends at 192.168.100.1. This search favours the most specific match that
2314 would apply to the route between these IPs. So, if there is a connection
2315 description exactly matching these IPs, the search will end there. If not,
2316 the code will search for a more general description matching the IPs.
2317 If there is no match, either specific or general, the packet will be
2318 dropped, as we see, above.
2319
2320 Unless you are working with Road Warriors, only the first, specific part
2321 of the matching process is likely to be relevant to you.
2322
2323
2324 "But I defined the tunnel, and it came up, why do I have this error?"
2325 - ---------------------------------------------------------------------
2326
2327 One of the most common causes of this error is failure to specify enough
2328 connection descriptions to cover all needed tunnels between any two
2329 gateways and their respective subnets. As you have noticed, troubleshooting
2330 this error may be complicated by the use of IP Masq. However, this error is
2331 not limited to cases where IP Masq is used.
2332
2333 See doc/configuration.html#multitunnel for a detailed example of the
2334 solution to this type of problem.</pre>
2335
2336 <p>The documentation section she refers to is now <a
2337 href="adv_config.html#multitunnel">here</a>.</p>
2338
2339 <h3><a name="SAused">... trouble writing to /dev/ipsec ... SA already in
2340 use</a></h3>
2341
2342 <p>This error message occurs when two manual connections are set up with the
2343 same SPI value. </p>
2344
2345 <p>See the FAQ for <a href="#spi_error">One manual connection works, but
2346 second one fails</a>.</p>
2347
2348 <h3><a name="ignore">... ignoring ... payload</a></h3>
2349
2350 <p>This message is harmless. The IKE protocol provides for a number of
2351 optional messages types:</p>
2352 <ul>
2353   <li>delete SA</li>
2354   <li>initial contact</li>
2355   <li>vendor ID</li>
2356   <li>...</li>
2357 </ul>
2358
2359 <p>An implementation is never required to send these, but they are allowed
2360 to. The receiver is not required to do anything with them. FreeS/WAN ignores
2361 them, but notifies you via the logs.</p>
2362
2363 <p>For the "ignoring delete SA Payload" message, see also our discussion of
2364 cleaning up <a href="#deadtunnel">dead tunnels</a>.</p>
2365
2366 <h2><a name="spam">Why don't you restrict the mailing lists to reduce
2367 spam?</a></h2>
2368
2369 <p>As a matter of policy, some of our <a href="mail.html">mailing lists</a>
2370 need to be open to non-subscribers. Project management feel strongly that
2371 maintaining this openness is more important than blocking spam.</p>
2372 <ul>
2373   <li>Users should be able to get help or report bugs without
2374   subscribing.</li>
2375   <li>Even a user who is subscribed may not have access to his or her
2376     subscribed account when he or she needs help, miles from home base in the
2377     middle of setting up a client's gateway.</li>
2378   <li>There is arguably a legal requirement for this policy. A US resident or
2379     citizen could be charged under munitions export laws for providing
2380     technical assistance to a foreign cryptographic project. Such a charge
2381     would be more easily defended if the discussion takes place in public, on
2382     an open list.</li>
2383 </ul>
2384
2385 <p>This has been discussed several times at some length on the list. See the
2386 <a href="mail.html#archive">list archives</a>. Bringing the topic up again is
2387 unlikely to be useful. Please don't. Or at the very least, please don't
2388 without reading the archives and being certain that whatever you are about to
2389 suggest has not yet been discussed.</p>
2390
2391 <p>Project technical lead Henry Spencer summarised one discussion:</p>
2392
2393 <blockquote>
2394   For the third and last time:  this list *will* *not* do address-based
2395   filtering.  This is a policy decision, not an implementation problem. The
2396   decision is final, and is not open to discussion.  This needs to be
2397   communicated better to people, and steps are being taken to do
2398 that.</blockquote>
2399
2400 <p>Adding this FAQ section is one of the steps he refers to.</p>
2401
2402 <p>You have various options other than just putting up with the spam,
2403 filtering it yourself, or unsubscribing:</p>
2404 <ul>
2405   <li>subscribe only to one or both of our lists with restricted posting
2406     rules:
2407     <ul>
2408       <li><a
2409         href="mailto:briefs@lists.freeswan.org?body=subscribe">briefs</a>,
2410         weekly list summaries</li>
2411       <li><a
2412         href="mailto:announce@lists.freeswan.org?body=subscribe">announce</a>,
2413         project-related announcements</li>
2414     </ul>
2415   </li>
2416   <li>read the other lists via the <a
2417   href="mail.html#archive">archives</a></li>
2418 </ul>
2419
2420 <p>A number of tools are available to filter mail.</p>
2421 <ul>
2422   <li>Many mail readers include some filtering capability.</li>
2423   <li>Many Linux distributions include <a
2424     href="http://www.procmail.org/">procmail(8)</a> for server-side
2425   filtering.</li>
2426   <li>The <a href="http://www.spambouncer.org/">Spam Bouncer</a> is a set of
2427     procmail(8) filters designed to combat spam.</li>
2428   <li>Roaring Penguin have a <a
2429     href="http://www.roaringpenguin.com/mimedefang/">MIME defanger</a> that
2430     removes potentially dangerous attachments.</li>
2431 </ul>
2432
2433 <p>If you use your ISP's mail server rather than running your own, consider
2434 suggesting to the ISP that they tag suspected spam as <a
2435 href="http://www.msen.com/1997/spam.html#SUSPECTED">this ISP</a> does. They
2436 could just refuse mail from dubious sources, but that is tricky and runs some
2437 risk of losing valuable mail or senselessly annoying senders and their
2438 admins. However, they can safely tag and deliver dubious mail. The tags can
2439 greatly assist your filtering.</p>
2440
2441 <p>For information on tracking down spammers, see these <a
2442 href="http://www.rahul.net/falk/#howtos">HowTos</a>, or the <a
2443 href="http://www.sputum.com/index2.html">Sputum</a> site. Sputum have a Linux
2444 anti-spam screensaver available for download.</p>
2445
2446 <p>Here is a more detailed message from Henry:</p>
2447 <pre>On Mon, 15 Jan 2001, Jay Vaughan wrote:
2448 &gt; I know I'm flogging a dead horse here, but I'm curious as to the reasons for
2449 &gt; an aversion for a subscriber-only mailing list?
2450
2451 Once again:  for legal reasons, it is important that discussions of these
2452 things be held in a public place -- the list -- and we do not want to
2453 force people to subscribe to the list just to ask one question, because
2454 that may be more than merely inconvenient for them.  There are also real
2455 difficulties with people who are temporarily forced to use alternate
2456 addresses; that is precisely the time when they may be most in need of
2457 help, yet a subscribers-only policy shuts them out.
2458
2459 These issues do not apply to most mailing lists, but for a list that is
2460 (necessarily) the primary user support route for a crypto package, they
2461 are very important.  This is *not* an ordinary mailing list; it has to
2462 function under awkward constraints that make various simplistic solutions
2463 inapplicable or undesirable.
2464
2465 &gt; We're *ALL* sick of hearing about list management problems, not just you
2466 &gt; old-timers, so why don't you DO SOMETHING EFFECTIVE ABOUT IT...
2467
2468 Because it's a lot harder than it looks, and many existing "solutions"
2469 have problems when examined closely.
2470
2471 &gt; A suggestion for you, based on 10 years of experience with management of my
2472 &gt; own mailing lists would be to use mailman, which includes pretty much every
2473 &gt; feature under the sun that you guys need and want, plus some.  The URL for
2474 &gt; mailman...
2475
2476 I assure you, we're aware of mailman.  Along with a whole bunch of others,
2477 including some you almost certainly have never heard of (I hadn't!).
2478
2479 &gt; As for the argument that the list shouldn't be configured to enforce
2480 &gt; subscription - I contend that it *SHOULD* AT LEAST require manual address
2481 &gt; verification in order for posts to be redirected.
2482
2483 You do realize, I hope, that interposing such a manual step might cause
2484 your government to decide that this is not truly a public forum, and thus
2485 you could go to jail if you don't get approval from them before mailing to
2486 it?  If you think this sounds irrational, your government is noted for
2487 making irrational decisions in this area; we can't assume that they will
2488 suddenly start being sensible.  See above about awkward constraints.  You
2489 may be willing to take the risk, but we can't, in good conscience, insist
2490 that all users with problems do so.
2491
2492                                                           Henry Spencer
2493                                                        henry@spsystems.net</pre>
2494
2495 <p>and a message on the topic from project leader John Gilmore:</p>
2496 <pre>Subject: Re: The linux-ipsec list's topic
2497    Date: Sat, 30 Dec 2000
2498    From: John Gilmore &lt;gnu@toad.com&gt;
2499
2500 I'll post this single message, once only, in this discussion, and then
2501 not burden the list with any further off-topic messages.  I encourage
2502 everyone on the list to restrain themself from posting ANY off-topic
2503 messages to the linux-ipsec list.
2504
2505 The topic of the linux-ipsec mailing list is the FreeS/WAN software.
2506
2507 I frequently see "discussions about spam on a list" overwhelm the
2508 volume of "actual spam" on a list. BOTH kinds of messages are
2509 off-topic messages.  Twenty anti-spam messages take just as long to
2510 detect and discard as twenty spam messages.
2511
2512 The Linux-ipsec list encourages on-topic messages from people who have
2513 not joined the list itself.  We will not censor messages to the list
2514 based on where they originate, or what return address they contain.
2515 In other words, non-subscribers ARE allowed to post, and this will not
2516 change.  My own valid contributions have been rejected out-of-hand by
2517 too many other mailing lists for me to want to impose that censorship
2518 on anybody else's contributions.  And every day I see the damage that
2519 anti-spam zeal is causing in many other ways; that zeal is far more
2520 damaging to the culture of the Internet than the nuisance of spam.
2521
2522 In general, it is the responsibility of recipients to filter,
2523 prioritize, or otherwise manage the handling of email that comes to
2524 them.  It is not the responsibility of the rest of the Internet
2525 community to refrain from sending messages to recipients that they
2526 might not want to see.  If your software infrastructure for managing
2527 your incoming email is insufficient, then improve it.  If you think
2528 the signal-to-noise ratio on linux-ipsec is too poor, then please
2529 unsubscribe.  But don't further increase the noise by posting to the
2530 linux-ipsec list about those topics.
2531
2532         John Gilmore
2533         founder &amp; sponsor, FreeS/WAN project</pre>
2534 </body>
2535 </html>