diff options
Diffstat (limited to 'doc/src/faq.html')
| -rw-r--r-- | doc/src/faq.html | 2770 |
1 files changed, 2770 insertions, 0 deletions
diff --git a/doc/src/faq.html b/doc/src/faq.html new file mode 100644 index 000000000..f62fc1c88 --- /dev/null +++ b/doc/src/faq.html @@ -0,0 +1,2770 @@ +<html> +<head> + <meta http-equiv="Content-Type" content="text/html"> + <title>FreeS/WAN FAQ</title> + <meta name="keywords" content="Linux, IPsec, VPN, security, FreeSWAN, FAQ"> + <!-- + + Written by Sandy Harris for the Linux FreeS/WAN project + Freely distributable under the GNU General Public License + + More information at www.freeswan.org + Feedback to users@lists.freeswan.org + + CVS information: + RCS ID: $Id: faq.html,v 1.1 2004/03/15 20:35:24 as Exp $ + Last changed: $Date: 2004/03/15 20:35:24 $ + Revision number: $Revision: 1.1 $ + + CVS revision numbers do not correspond to FreeS/WAN release numbers. + --> +</head> + +<body> +<h1>FreeS/WAN FAQ</h1> + +<p>This is a collection of questions and answers, mostly taken from the +FreeS/WAN <a href="mail.html">mailing list</a>. See the project <a +href="http://www.freeswan.org/">web site</a> for more information. All the +FreeS/WAN documentation is online there.</p> + +<p>Contributions to the FAQ are welcome. Please send them to the project <a +href="mail.html">mailing list</a>.</p> +<hr> + +<h2><a name="questions">Index of FAQ questions</a></h2> +<ul> + <li><a href="#whatzit">What is FreeS/WAN?</a></li> + <li><a href="#problems">How do I report a problem or seek help?</a></li> + <li><a href="#generic">Can I get ...</a> + <ul> + <li><a href="#lemme_out">... an off-the-shelf system that includes + FreeS/WAN?</a></li> + <li><a href="#contractor">... contractors or staff who know + FreeS/WAN?</a></li> + <li><a href="#commercial">... commercial support?</a></li> + </ul> + </li> + <li><a href="#release">Release questions</a> + <ul> + <li><a href="#rel.current">What is the current release?</a></li> + <li><a href="#relwhen">When is the next release?</a></li> + <li><a href="#rel.bugs">Are there known bugs in the current + release?</a></li> + </ul> + </li> + <li><a href="mod_cons">Modifications and contributions</a> + <ul> + <li><a href="#modify.faq">Can I modify FreeS/WAN to ...?</a></li> + <li><a href="#contrib.faq">Can I contribute to the project?</a></li> + <li><a href="#ddoc.faq">Is there detailed design documentation?</a></li> + </ul> + </li> + <li><a href="#interact">Will FreeS/WAN work in my environment?</a> + <ul> + <li><a href="#interop.faq">Can FreeS/WAN talk to ... ?</a></li> + <li><a href="#old_to_new">Can different FreeS/WAN versions talk to each + other?</a></li> + <li><a href="#faq.bandwidth">Is there a limit on throughput?</a></li> + <li><a href="#faq.number">Is there a limit on number of + connections?</a></li> + <li><a href="#faq.speed">Is a ... fast enough to handle FreeS/WAN with + my loads?</a></li> + </ul> + </li> + <li><a href="#work_on">Will FreeS/WAN work on ...</a> + <ul> + <li><a href="#versions">... my version of Linux?</a></li> + <li><a href="#nonIntel.faq">... non-Intel CPUs?</a></li> + <li><a href="#multi.faq">... multiprocessors?</a></li> + <li><a href="#k.old">... an older kernel?</a></li> + <li><a href="#k.versions">... the latest kernel version?</a></li> + <li><a href="#interface.faq">... unusual network hardware?</a></li> + <li><a href="#vlan">... a VLAN (802.1q) network?</a></li> + </ul> + </li> + <li><a href="#features.faq">Does FreeS/WAN support ...</a> + <ul> + <li><a href="#VPN.faq">... site-to-site VPN applications</a></li> + <li><a href="#warrior.faq">... remote users connecting to a LAN</a></li> + <li><a href="#road.shared.possible">... remote users using shared + secret authentication?</a></li> + <li><a href="#wireless.faq">... wireless networks</a></li> + <li><a href="#PKIcert">... X.509 or other PKI certificates?</a></li> + <li><a href="#Radius">... user authentication (Radius, SecureID, + Smart Card ...)?</a></li> + <li><a href="#NATtraversal">... NAT traversal</a></li> + <li><a href="#virtID">... assigning a "virtual identity" to a remote + system?</a></li> + <li><a href="#noDES.faq">... single DES encryption?</a></li> + <li><a href="#AES.faq">... AES encryption?</a></li> + <li><a href="#other.cipher">... other encryption algorithms?</a></li> + </ul> + </li> + <li><a href="#canI">Can I ...</a> + <ul> + <li><a href="#policy.preconfig">...use policy groups along with + explicitly configured connections?</a></li> + <li><a href="#policy.off">...turn off policy groups?</a></li> +<!-- + <li><a href="#policy.otherinterface">...use policy groups + on an interface other than <VAR>%defaultroute</VAR>?</a></li> +--> + <li><a href="#reload">... reload connection info without + restarting?</a></li> + <li><a href="#masq.faq">... use several masqueraded subnets?</a></li> + <li><a href="#dup_route">... use subnets masqueraded to the same + addresses?</a></li> + <li><a href="#road.masq">... assign a road warrior an address on my net + (a virtual identity)?</a></li> + <li><a href="#road.many">... support many road warriors with one + gateway?</a></li> + <li><a href="#road.PSK">... have many road warriors using shared secret + authentication?</a></li> + <li><a href="#QoS">... use Quality of Service routing with + FreeS/WAN?</a></li> + <li><a href="#deadtunnel">... recognise dead tunnels and shut them + down?</a></li> + <li><a href="#demanddial">... build IPsec tunnels over a demand-dialed + link?</a></li> + <li><a href="#GRE">... build GRE, L2TP or PPTP tunnels over IPsec?</a></li> + <li><a href="#NetBIOS">... use Network Neighborhood (Samba, NetBIOS) over IPsec?</a></li> + </ul> + </li> + <li><a href="#setup.faq">Life's little mysteries</a> + <ul> + <li><a href="#cantping">I cannot ping ....</a></li> + <li><a href="#forever">It takes forever to ...</a></li> + <li><a href="#route">I send packets to the tunnel with route(8) but + they vanish</a></li> + <li><a href="#down_route">When a tunnel goes down, packets + vanish</a></li> + <li><a href="#firewall_ate">The firewall ate my packets!</a></li> + <li><a href="#dropconn">Dropped connections</a></li> + <li><a href="#defaultroutegone">Disappearing %defaultroute</a></li> + <li><a href="#tcpdump.faq">TCPdump on the gateway shows strange + things</a></li> + <li><a href="#no_trace">Traceroute does not show anything between the + gateways</a></li> + </ul> + </li> + <li><a href="#man4debug">Testing in stages (or .... works but ... + doesn't)</a> + <ul> + <li><a href="#nomanual">Manually keyed connections don't work</a></li> + <li><a href="#spi_error">One manual connection works, but second one + fails</a></li> + <li><a href="#man_no_auto">Manual connections work, but automatic + keying doesn't</a></li> + <li><a href="#nocomp">IPsec works, but connections using compression + fail</a></li> + <li><a href="#pmtu.broken">Small packets work, but large transfers + fail</a></li> + <li><a href="#subsub">Subnet-to-subnet works, but tests from the + gateways don't</a></li> + </ul> + </li> + <li><a href="#compile.faq">Compilation problems</a> + <ul> + <li><a href="#gmp.h_missing">gmp.h: No such file or directory</a></li> + <li><a href="#noVM">... virtual memory exhausted</a></li> + </ul> + </li> + <li><a href="#error">Interpreting error messages</a> + <ul> + <li><a href="#route-client">route-client (or host) exited with status + 7</a></li> + <li><a href="#unreachable">SIOCADDRT:Network is unreachable</a></li> + <li><a href="#modprobe">ipsec_setup: modprobe: Can't locate + moduleipsec</a></li> + <li><a href="#noKLIPS">ipsec_setup: Fatal error, kernel appears to lack + KLIPS</a></li> + <li><a href="#noDNS">ipsec_setup: ... failure to fetch key for ... from + DNS</a></li> + <li><a href="#dup_address">ipsec_setup: ... interfaces ... and ... + share address ...</a></li> + <li><a href="#kflags">ipsec_setup: Cannot adjust kernel flags</a></li> + <li><a href="#message_num">Message numbers (MI3, QR1, et cetera) in + Pluto messages</a></li> + <li><a href="#conn_name">Connection names in Pluto error + messages</a></li> + <li><a href="#cantorient">Pluto: ... can't orient connection</a></li> + <li><a href="#no.interface">... we have no ipsecN interface for either + end of this connection</a></li> + <li><a href="#noconn">Pluto: ... no connection is known</a></li> + <li><a href="#nosuit">Pluto: ... no suitable connection ...</a></li> + <li><a href="#noconn.auth">Pluto: ... no connection has been + authorized</a></li> + <li><a href="#noDESsupport">Pluto: ... OAKLEY_DES_CBC is not + supported.</a></li> + <li><a href="#notransform">Pluto: ... no acceptable transform</a></li> + <li><a href="#rsasigkey">rsasigkey dumps core</a></li> + <li><a href="#sig4">!Pluto failure!: ... exited with ... signal + 4</a></li> + <li><a href="#econnrefused">ECONNREFUSED error message</a></li> + <li><a href="#no_eroute">klips_debug: ... no eroute!</a></li> + <li><a href="#SAused">... trouble writing to /dev/ipsec ... SA already + in use</a></li> + <li><a href="#ignore">... ignoring ... payload</a></li> + <li><a href="#unknown_rightcert">unknown parameter name "rightcert"</a></li> + </ul> + <li><a href="#spam">Why don't you restrict the mailing lists to reduce + spam?</a></li> +</ul> +<hr> + +<h2><a name="whatzit">What is FreeS/WAN?</a></h2> + +<p>FreeS/WAN is a Linux implementation of the <a +href="glossary.html#IPSEC">IPsec</a> protocols, providing security services +at the IP (Internet Protocol) level of the network.</p> + +<p>For more detail, see our <a href="intro.html">introduction</a> document or +the FreeS/WAN project <a href="http://www.freeswan.org/">web site</a>.</p> + +<p>To start setting it up, go to our <a href="quickstart.html">quickstart +guide</a>.</p> + +<p>Our <a href="web.html">web links</a> document has information on <a +href="web.html#implement">IPsec for other systems</a>.</p> + +<h2><a name="problems">How do I report a problem or seek help?</a></h2> + +<DL> +<DT>Read our <a href="trouble.html">troubleshooting</a> document.</DT> +<DD><p>It may guide you to a solution. If not, see its +<a href="trouble.html#prob.report">problem reporting</a> section.</p> + +<p>Basically, what it says is <strong>give us the output from <var>ipsec +barf</var> from both gateways</strong>. Without full information, we cannot +diagnose a problem. However, <var>ipsec barf</var> produces a lot of output. +If at all possible, <strong>please make barfs accessible via the web or +FTP</strong> rather than sending enormous mail messages.</p> +</DD> + +<DT><strong>Use the <a href="mail.html">users mailing list</a> for problem +reports</strong>, rather than mailing developers directly. +</DT> + +<DD> +<ul> + <li>This gives you access to more expertise, including users who may have + encountered and solved the same problems.</li> + <li>It is more likely to get a quick response. Developers may get behind on + email, or even ignore it entirely for a while, but a list message (given + a reasonable Subject: line) is certain to be read by a fair number of + people within hours.</li> + <li>It may also be important because of <a + href="politics.html#exlaw">cryptography export laws</a>. A US citizen who + provides technical assistance to foreign cryptographic work might be + charged under the arms export regulations. Such a charge would be easier + to defend if the discussion took place on a public mailing list than if + it were done in private mail.</li> +</ul> +</DD> + +<DT>Try irc.freenode.net#freeswan.</DT> + +<DD> +<p>FreeS/WAN developers, volunteers and users can often be found there. +Be patient and be +prepared to provide lots of information to support your question.</p> + +<p>If your question was really interesting, and you found an answer, +please share that with the class by posting to the +<a href="mail.html">users mailing list</a>. That way others with the +same problem can find your answer in the archives.</p> +</DD> + +<DT>Premium support is also available.</DT> +<DD> +<p>See the next several questions.</p> +</DD> +</DL> + +<h2><a name="generic">Can I get ...</a></h2> + +<h3><a name="lemme_out">Can I get an off-the-shelf system that includes +FreeS/WAN?</a></h3> + +<p>There are a number of Linux distributions or firewall products which +include FreeS/WAN. See this <a href="intro.html#products">list</a>. Using one +of these, chosen to match your requirements and budget, may save you +considerable time and effort.</p> + +<p>If you don't know your requirements, start by reading Schneier's <a +href="biblio.html#secrets">Secrets and Lies</a>. That gives the best overview +of security issues I have seen. Then consider hiring a consultant (see next +question) to help define your requirements.</p> + +<h3><a name="consultant">Can I hire consultants or staff who know +FreeS/WAN?</a></h3> + +<p>If you want the help of a contractor, or to hire staff with FreeS/WAN +expertise, you could:</p> +<ul> + <li>check availability in your area through your local Linux User Group (<a + href="http://lugww.counter.li.org/">LUG Index</a>)</li> + <li>try asking on our <a href="mail.html">mailing list</a></li> +</ul> + +<p>For companies offerring support, see the next question.</p> + +<h3><a name="commercial">Can I get commercial support?</a></h3> + +<p>Many of the distributions or firewall products which include FreeS/WAN +(see this <a href="intro.html#products">list</a>) come with commercial +support or have it available as an option.</p> + +<p>Various companies specialize in commercial support of open source +software. Our project leader was a founder of the first such company, Cygnus +Support. It has since been bought by <a +href="http://www.redhat.com">Redhat</a>. Another such firm is <a +href="http://www.linuxcare.com">Linuxcare</a>.</p> + +<h2><a name="release">Release questions</a></h2> + +<h3><a name="rel.current">What is the current release?</a></h3> + +<p>The current release is the highest-numbered tarball on our <a +href="ftp://ftp.xs4all.nl/pub/crypto/freeswan">distribution site</a>. Almost +always, any of <a href="intro.html#mirrors">the mirrors</a> will have the +same file, though perhaps not for a day or so after a release.</p> + +<p>Unfortunately, the web site is not always updated as quickly as it should +be.</p> + +<h3><a name="relwhen">When is the next release?</a></h3> + +<p>We try to do a release approximately every six to eight weeks. +</p> + +<p>If pre-release tests fail and the fix appears complex, or more generally +if the code does not appear stable when a release is scheduled, we will just +skip that release.</p> + +<p>For serious bugs, we may bring out an extra bug-fix release. These get +numbers in the normal release series. For example, there was a bug found in +FreeS/WAN 1.6, so we did another release less than two weeks later. The +bug-fix release was called 1.7.</p> + +<h3><a name="rel.bugs">Are there known bugs in the current release?</a></h3> + +<p>Any problems we are aware of at the time of a release are documented in +the <a href="../BUGS">BUGS</a> file for that release. You should also look at +the <a href="../CHANGES">CHANGES</a> file.</p> + +<p>Bugs discovered after a release are discussed on the <a +href="mail.html">mailing lists</a>. The easiest way to check for any problems +in the current code would be to peruse the +<a href="http://lists.freeswan.org/pipermail/briefs">List In Brief</a>.</p> + +<h2><a name="mod_cons">Modifications and contributions</a></h2> + +<h3><a name="modify.faq">Can I modify FreeS/WAN to ...?</a></h3> + +<p>You are free to modify FreeS/WAN in any way. See the discussion of <a +href="intro.html#licensing">licensing</a> in our introduction document.</p> + +<p>Before investing much energy in any such project, we suggest that you</p> +<ul> + <li>check the list of <a href="web.html#patch">existing patches</a></li> + <li>post something about your project to the <a href="mail.html">design + mailing list</a></li> +</ul> + +<p>This may prevent duplicated effort, or lead to interesting +collaborations.</p> + +<h3><a name="contrib.faq">Can I contribute to the project?</a></h3> +In general, we welcome contributions from the community. Various contributed +patches, either to fix bugs or to add features, have been incorporated into +our distribution. Other patches, not yet included in the distribution, are +listed in our <a href="web.html#patch">web links</a> section. + +<p>Users have also contributed heavily to documentation, both by creating +their own <a href="intro.html#howto">HowTos</a> and by posting things on the +<a href="mail.html">mailing lists</a> which I have quoted in these HTML +docs.</p> + +<p>There are, however, some caveats.</p> + +<p>FreeS/WAN is being implemented in Canada, by Canadians, largely to ensure +that is it is entirely free of export restrictions. See this <a +href="politics.html#status">discussion</a>. We <strong>cannot accept code +contributions from US residents or citizens</strong>, not even one-line bugs +fixes. The reasons for this were recently discussed extensively on the +mailing list, in a thread starting <a +href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00111.html">here</a>.</p> + +<p>Not all contributions are of interest to us. The project has a set of +fairly ambitious and quite specific goals, described in our <a +href="intro.html#goals">introduction</a>. Contributions that lead toward +these goals are likely to be welcomed enthusiastically. Other contributions +may be seen as lower priority, or even as a distraction.</p> + +<p>Discussion of possible contributions takes place on the <a +href="mail.html">design mailing list</a>.</p> + +<h3><a name="ddoc.faq">Is there detailed design documentation?</a></h3> +There are: +<ul> + <li><a href="rfc.html">RFCs</a> specifying the protocols we implement</li> + <li><a href="manpages.html">man pages</a> for our utilities, library + functions and file formats</li> + <li>comments in the source code</li> + <li><a href="index.html">HTML documentation</a> written primarily for + users</li> + <li>archived discussions from the <a href="mail.html">mailing lists</a></li> + <li>other papers mentioned in our <a + href="intro.html#applied">introduction</a></li> +</ul> + +<p>The only formal design documents are a few papers in the last category +above. All the other categories, however, have things to say about design as +well.</p> + +<h2><a name="interact">Will FreeS/WAN work in my environment?</a></h2> + +<h3><a name="interop.faq">Can FreeS/WAN talk to ...?</a></h3> + +<p>The IPsec protocols are designed to support interoperation. In theory, any +two IPsec implementations should be able to talk to each other. In practice, +it is considerably more complex. We have a whole <a +href="interop.html">interoperation document</a> devoted to this problem.</p> + +<p>An important part of that document is links to the many <a +href="interop.html#otherpub">user-written HowTos</a> on interoperation +between FreeS/WAN and various other implementations. Often the users know +more than the developers about these issues (and almost always more than me +:-), so these documents may be your best resource.</p> + +<h3><a name="old_to_new">Can different FreeS/WAN versions talk to each +other?</a></h3> + +<p>Linux FreeS/WAN can interoperate with many IPsec implementations, +including earlier versions of Linux FreeS/WAN itself.</p> + +<p>In a few cases, there are some complications. See our <a +href="interop.html#oldswan">interoperation</a> document for details.</p> + +<h3><a name="faq.bandwidth">Is there a limit on throughput?</a></h3> + +<p>There is no hard limit, but see below.</p> + +<h3><a name="faq.number">Is there a limit on number of tunnels?</a></h3> + +<p>There is no hard limit, but see next question.</p> + +<h3><a name="faq.speed">Is a ... fast enough to handle FreeS/WAN with my +loads?</a></h3> + +<p>A quick summary:</p> +<dl> + <dt>Even a limited machine can be useful</dt> + <dd>A 486 can handle a T1, ADSL or cable link, though the machine may be + breathing hard.</dd> + <dt>A mid-range PC (say 800 MHz with good network cards) can do a lot of + IPsec</dt> + <dd>With up to roughly 50 tunnels and aggregate bandwidth of 20 Megabits + per second, it willl have cycles left over for other tasks.</dd> + <dt>There are limits</dt> + <dd>Even a high end CPU will not come close to handling a fully loaded + 100 Mbit/second Ethernet link. + <p>Beyond about 50 tunnels it needs careful management.</p> + </dd> +</dl> + +<p>See our <a href="performance.html">FreeS/WAN performance</a> document for +details.</p> + +<h2><a name="work_on">Will FreeS/WAN work on ... ?</a></h2> + +<h3><a name="versions">Will FreeS/WAN run on my version of Linux?</a></h3> + +<p>We build and test on Redhat distributions, but FreeS/WAN runs just fine on +several other distributions, sometimes with minor fiddles to adapt to the +local environment. Details are in our <a +href="compat.html#otherdist">compatibility</a> document. Also, some +distributions or products come with <a href="intro.html#products">FreeS/WAN +included</a>.</p> + +<h3><a name="nonIntel.faq">Will FreeS/WAN run on non-Intel CPUs?</a></h3> + +<p>FreeS/WAN is <strong>intended to run on all CPUs Linux supports</strong>. +We know of it being used in production on x86, ARM, Alpha and MIPS. It has +also had successful tests on PPC and SPARC, though we don't know of actual +use there. Details are in our <a href="compat.html#CPUs">compatibility</a> +document.</p> + +<h3><a name="multi.faq">Will FreeS/WAN run on multiprocessors?</a></h3> + +<p>FreeS/WAN is designed to work on any SMP architecture Linux supports, and +has been tested successfully on at least dual processor Intel architecture +machines. Details are in our <a +href="compat.html#multiprocessor">compatibility</a> document.</p> + +<h3><a name="k.old">Will FreeS/WAN work on an older kernel?</a></h3> + +<p>It might, but we strongly recommend using a recent 2.2 or 2.4 series +kernel. Sometimes the newer versions include security fixes which can be +quite important on a gateway.</p> + +<p>Also, we use recent kernels for development and testing, so those are +better tested and, if you do encounter a problem, more easily supported. If +something breaks applying recent FreeS/WAN patches to an older kernel, then +"update your kernel" is almost certain to be the first thing we suggest. It +may be the only suggestion we have.</p> + +<p>The precise kernel versions supported by a particular FreeS/WAN release +are given in the <a href="XX">README</a> file of that release.</p> + +<p>See the following question for more on kernels.</p> + +<h3><a name="k.versions">Will FreeS/WAN run on the latest kernel +version?</a></h3> + +<p>Sometimes yes, but quite often, no.</p> + +<p>Kernel versions supported are given in the <a href="../README">README</a> +file of each FreeS/WAN release. Typically, they are whatever production +kernels were current at the time of our release (or shortly before; we might +release for kernel <var>n</var> just as Linus releases <var>n+1</var>). Often +FreeS/WAN will work on slightly later kernels as well, but of course this +cannot be guaranteed.</p> + +<p>For example, FreeS/WAN 1.91 was released for kernels 2.2.19 or 2.4.5, the +current kernels at the time. It also worked on 2.4.6, 2.4.7 and 2.4.8, but +2.4.9 had changes that caused compilation errors if it was patched with +FreeS/WAN 1.91.</p> + +<p>When such changes appear, we put a fix in the FreeS/WAN snapshots, and +distribute it with our next release. However, this is not a high priority for +us, and it may take anything from a few days to several weeks for such a +problem to find its way to the top of our kernel programmer's To-Do list. In +the meanwhile, you have two choices:</p> +<ul> + <li>either stick with a slightly older kernel, even if it is not the latest + and greatest. This is recommended for production systems; new versions + may have new bugs.</li> + <li>or fix the problem yourself and send us a patch, via the <a + href="mail.html">Users mailing list</a>.</li> +</ul> + +<p>We don't even try to keep up with kernel changes outside the main 2.2 and +2.4 branches, such as the 2.4.x-ac patched versions from Alan Cox or the 2.5 +series of development kernels. We'd rather work on developing the FreeS/WAN +code than on chasing these moving targets. We are, however, happy to get +patches for problems discovered there.</p> + +<p>See also the <a href="install.html#choosek">Choosing a kernel</a> section +of our installation document.</p> + +<h3><a name="interface.faq">Will FreeS/WAN work on unusual network +hardware?</a></h3> + +<p>IPsec is designed to work over any network that IP works over, and +FreeS/WAN is intended to work over any network interface hardware that Linux +supports.</p> + +<p>If you have working IP on some unusual interface -- perhaps Arcnet, Token +Ring, ATM or Gigabit Ethernet -- then IPsec should "just work".</p> + +<p>That said, practice is sometimes less tractable than theory. Our testing +is done almost entirely on:</p> +<ul> + <li>10 or 100 Mbit Ethernet</li> + <li>ADSL or cable connections, with and without PPPoE</li> + <li>IEEE 802.11 wireless LANs (see <a href="#wireless.faq">below</a>)</li> +</ul> + +<p>If you have some other interface, especially an uncommon one, it is +entirely possible you will get bitten either by a FreeS/WAN bug which our +testing did not turn up, or by a bug in the driver that shows up only with +our loads.</p> + +<p>If IP works on your interface and FreeS/WAN doesn't, seek help on the <a +href="mail.html">mailing lists</a>.</p> + +<p>Another FAQ section describes <a href="#pmtu.broken">MTU problems</a>. +These are a possibility for some interfaces.</p> + +<h3><a name="vlan">Will FreeS/WAN work on a VLAN (802.1q) network?</a></h3> + +<p> + Yes, FreeSwan works fine, though some network drivers have problems + with jumbo sized ethernet frames. If you used interfaces=%defaultroute + you do not need to change anything, but if you specified an interface + (eg eth0) then remember you must change that to reflect the VLAN + interface (eg eth0.2 for VLAN ID 2). +</p> +<p> + The "eepro100" module is known to be broken, use the e100 driver + for those cards instead (included in 2.4 as 'alternative driver' for + the Intel EtherExpressPro/100. +</p> +<p> + You do not need to change any MTU setting (those are workarounds + that are only needed for buggy drivers) +</p> + +<p><em>This FAQ contributed by Paul Wouters.</em></p> + +<h2><a name="features.faq">Does FreeS/WAN support ...</a></h2> + +<p>For a discussion of which parts of the IPsec specifications FreeS/WAN does +and does not implement, see our <a href="compat.html#spec">compatibility</a> +document.</p> + +<p>For information on some often-requested features, see below.</p> + +<h3><a name="VPN.faq"></a>Does FreeS/WAN support site-to-site VPN +(<A HREF="glossary.html#VPN">Virtual Private Network</A>) +applications?</h3> + +<p>Absolutely. See this FreeS/WAN-FreeS/WAN +<A HREF="config.html">configuration example</A>. +If only one site is using FreeS/WAN, there may be a relevant HOWTO on our +<A HREF="interop.html">interop page</A>. +</p> + +<h3><a name="warrior.faq">Does FreeS/WAN support remote users connecting to a +LAN?</a></h3> + +<p>Yes. We call the remote users "Road Warriors". Check out our +FreeS/WAN-FreeS/WAN +<A HREF="config.html#config.rw">Road Warrior Configuration Example</A>.</P> + +<p>If your Road Warrior is a Windows or Mac PC, you may need to +install an IPsec implementation on that machine. +Our <A HREF="interop.html">interop</A> page lists many available brands, +and features links to several HOWTOs. + + +<h3><a name="road.shared.possible">Does FreeS/WAN support remote users using +shared secret authentication?</a></h3> + +<p><strong>Yes, but</strong> there are severe restrictions, so <strong>we +strongly recommend using </strong><a +href="glossary.html#RSA"><strong>RSA</strong></a><strong> keys for +</strong> <a +href="glossary.html#authentication"><strong>authentication</strong></a> +<strong> +instead</strong>.</p> + +<p>See this <a href="#road.PSK">FAQ question</a>.</p> + +<h3><a name="wireless.faq">Does FreeS/WAN support wireless networks?</a></h3> + +<p>Yes, it is a common practice to use IPsec over wireless networks because +their built-in encryption, <a href="glossary.html#WEP">WEP</a>, is +insecure.</p> + +<p>There is some <a href="adv_config.html#wireless.config">discussion</a> in +our advanced configuration document. See also the +<A HREF="http://www.wavesec.org">WaveSEC site</A>.</p> + +<h3><a name="PKIcert">Does FreeS/WAN support X.509 or other PKI +certificates?</a></h3> + +<P>Vanilla FreeS/WAN does not support X.509, but Andreas Steffen +and others have provided a popular, well-supported X.509 patch.</P> + +<UL> +<LI><A HREF="http://www.strongsec.com/freeswan">patch</A> +</LI> +<LI><A HREF="http://www.freeswan.ca">Super FreeS/WAN</A> incorporates +this and other user-contributed patches. +</LI> +<LI> +Kai Martius' <A HREF="http://www.strongsec.com/freeswan/install.htm">X.509 +Installation and Configuration Guide</A> +</LI> +</UL> + +<P> +Linux FreeS/WAN features +<A HREF="quickstart.html">Opportunistic Encryption</A>, an alternative +Public Key Infrastructure based on Secure DNS. +</P> + +<h3><a name="Radius">Does FreeS/WAN support user authentication (Radius, +SecureID, Smart Card...)?</a></h3> + +<P>Andreas Steffen's <A HREF="http://www.strongsec.com/freeswan">X.509 patch</A> (v. 1.42+) supports Smart Cards. The patch +does not ship with vanilla FreeS/WAN, but will be incorporated into +<A HREF="http://www.freeswan.ca/">Super FreeS/WAN +2.01+</A>. The patch implements the PCKS#15 +Cryptographic Token Information Format Standard, using the OpenSC smartcard +library functions.</P> + +<P>Older news:</P> + +<P>A user-supported patch to FreeS/WAN 1.3, for smart card style +authentication, is available on +<A HREF="http://alcatraz.webcriminals.com/~bastiaan/ipsec">Bastiaan's site</A>. +It supports skeyid and ibutton. +This patch is not part of Super FreeS/WAN.</p> + +<p>For a while progress on this front was impeded by a lack of standard. +The IETF <a +href="http://www.ietf.org/html.charters/ipsra-charter.html">working group</a> +has now nearly completed its recommended solution to the problem; meanwhile +several vendors have implemented various things.</p> + +<!-- +<p>The <a href="web.html#patch">patches</a> section of our web links document +has links to some user work on this.</p> +--> + +<p>Of course, there are various ways to avoid any requirement for user +authentication in IPsec. Consider the situation where road warriors build +IPsec tunnels to your office net and you are considering requiring user +authentication during tunnel negotiation. Alternatives include:</p> +<ul> + <li>If you can trust the road warrior machines, then set them up so that + only authorised users can create tunnels. If your road warriors use + laptops, consider the possibility of theft.</li> + <li>If the tunnel only provides access to particular servers and you can + trust those servers, then set the servers up to require user + authentication.</li> +</ul> + +<p>If either of those is trustworthy, it is not clear that you need user +authentication in IPsec.</p> + + +<h3><a name="NATtraversal">Does FreeS/WAN support NAT traversal?</a></h3> + +<p>Vanilla FreeS/WAN does not, but thanks to Mathieu Lafon and +Arkoon Network Security, there's a patch to support this.</P> + +<UL> +<LI><A HREF="http://open-source.arkoon.net">patch and documentation</A> +</LI> +<LI><A HREF="http://www.freeswan.ca">Super FreeS/WAN</A> incorporates +this and other user-contributed patches. +</LI> +</UL> + +<P>The NAT traversal patch has some issues with PSKs, so you may wish to +authenticate with RSA keys, or X.509 (requires a patch which is also +included in Super FreeS/WAN). Doing the latter also has +advantages when dealing with large numbers of clients who may be behind NAT; +instead of having to make an individual Roadwarrior connection for each +virtual IP, you can use the "rightsubnetwithin" parameter to specify a range. +See +<A HREF="http://www.strongsec.com/freeswan/install.htm#section_4.4">these +<VAR>rightsubnetwithin</VAR> instructions</A>. +</P> + + +<h3><a name="virtID">Does FreeS/WAN support assigning a "virtual identity" to +a remote system?</a></h3> + +<p>Some IPsec implementations allow you to make the source address on packets +sent by a Road Warrior machine be something other than the address of its +interface to the Internet. This is sometimes described as assigning a virtual +identity to that machine.</p> + +<p>FreeS/WAN does not directly support this, but it can be done. See this <a +href="#road.masq">FAQ question</a>.</p> + +<h3><a name="noDES.faq">Does FreeS/WAN support single DES encryption?</a></h3> + +<p><strong>No</strong>, single DES is not used either at the <a +href="glossary.html#IKE">IKE</a> level for negotiating connections or at the +<a href="glossary.html#IPsec">IPsec</a> level for actually building them.</p> + +<p>Single DES is <a href="politics.html#desnotsecure">insecure</a>. As we see +it, it is more important to deliver real security than to comply with a +standard which has been subverted into allowing use of inadequate methods. +See this <a href="politics.html#weak">discussion</a>.</p> + +<p>If you want to interoperate with an IPsec implementation which offers only +DES, see our <a href="interop.html#noDES">interoperation</a> document.</p> + +<h3><a name="AES.faq">Does FreeS/WAN support AES encryption?</a></h3> + +<p><a href="glossary.html#AES">AES</a> is a new US government <a +href="glossary.html#block">block cipher</a> standard to replace the obsolete +<a href="glossary.html#DES">DES</a>.</p> + +<p>At time of writing (March 2002), the FreeS/WAN distribution does not yet +support AES but user-written <a href="web.html#patch">patches</a> are +available to add it. Our kernel programmer is working on integrating those +patches into the distribution, and there is active discussion of this on the +design mailimg list.</p> + +<h3><a name="other.cipher">Does FreeS/WAN support other encryption +algorithms?</a></h3> + +<p>Currently <a href="glossary.html#3DES">triple DES</a> is the only cipher +supported. AES will almost certainly be added (see previous question), and it +is likely that in the process we will also add the other two AES finalists +with open licensing, Twofish and Serpent.</p> + +<p>We are extremely reluctant to add other ciphers. This would make both use +and maintenance of FreeS/WAN more complex without providing any clear +benefit. Complexity is emphatically not desirable in a security product.</p> + +<p>Various users have written patches to add other ciphers. We provide <a +href="web.html#patch">links</a> to these.</p> + +<h2><a name="canI">Can I ...</a></h2> + + +<h3><a name="policy.preconfig">Can I use policy groups along with +explicitly configured connections?</a></h3> + +<p>Yes, you can, so long as you pay attention to the selection rule, +which can be summarized "the most specific +connection wins". We describe the rule in our +<A HREF="policygroups.html#policy.group.notes">policy groups</A> document, +and provide a more technical explanation in +<A HREF="manpage.d/ipsec.conf.5.html">man ipsec.conf</A>. +</p> + +<p>A good guideline: If you have a regular connection defined in +<VAR>ipsec.conf</VAR>, ensure that a subset of that connection +is not listed in a less restrictive policy group. Otherwise, +FreeS/WAN will use the subset, with its more specific source/destination +pair.</p> + +<p>Here's an example. Suppose you are the system administrator at 192.0.2.2. +You have this connection in ipsec.conf: +<VAR>ipsec.conf</VAR>: + +<PRE>conn net-to-net + left=192.0.2.2 # you are here + right=192.0.2.8 + rightsubnet=192.0.2.96/27 + .... +</PRE> + +<p>If you then place a host or net within <VAR>rightsubnet</VAR>, +(let's say 192.0.2.98) in <VAR>private-or-clear</VAR>, you may find +that 192.0.2.2 at times communicates in the +clear with 192.0.2.98. That's consistent with the rule, but may be +contrary to your expectations.</p> + +<p>On the other hand, it's safe to put a larger subnet in a less +restrictive policy group file. If <VAR>private-or-clear</VAR> +contains 192.0.2.0/24, then the more specific <VAR>net-to-net</VAR> +connection is used for any communication to 192.0.2.96/27. The +more general policy applies only to communication with hosts or subnets in +192.0.2.0/24 without a more specific policy or connection.</p> + + +<h3><a name="policy.off">Can I turn off policy groups?</a></h3> + +<p>Yes. Use <A HREF="policygroups.html#disable_policygroups">these +instructions</A>.</p> + +<!-- +<h3><a name="policy.otherinterface">Can I use policy groups + on an interface other than <VAR>%defaultroute</VAR>?</a></h3> + +<p>??<p> +--> + +<h3><a name="reload">Can I reload connection info without restarting?</a></h3> + +<p>Yes, you can do this. Here are the details, in a mailing list message from +Pluto programmer Hugh Redelmeier:</p> +<pre>| How can I reload config's without restarting all of pluto and klips? I am using +| FreeSWAN -> PGPNet in a medium sized production environment, and would like to be +| able to add new connections ( i am using include config/* ) without dropping current +| SA's. +| +| Can this be done? +| +| If not, are there plans to add this kind of feature? + + ipsec auto --add whatever +This will look in the usual place (/etc/ipsec.conf) for a conn named +whatever and add it. + +If you added new secrets, you need to do + ipsec auto --rereadsecrets +before Pluto needs to know those secrets. + +| I have looked (perhaps not thoroughly enough tho) to see how to do this: + +There may be more bits to look for, depending on what you are trying +to do.</pre> + +<p>Another useful command here is <var>ipsec auto --replace +<conn_name></var> which re-reads data for a named connection.</p> + +<h3><a name="masq.faq">Can I use several masqueraded subnets?</a></h3> + +<p>Yes. This is done all the time. See the discussion in our <a +href="config.html#route_or_not">setup</a> document. The only restriction is +that the subnets on the two ends must not overlap. See the next question.</p> + +<p>Here is a mailing list message on the topic. The user incorrectly thinks +you need a 2.4 kernel for this -- actually various people have been doing it +on 2.0 and 2.2 for quite some time -- but he has it right for 2.4.</p> +<pre>Subject: Double NAT and freeswan working :) + Date: Sun, 11 Mar 2001 + From: Paul Wouters <paul@xtdnet.nl> + +Just to share my pleasure, and make an entry for people who are searching +the net on how to do this. Here's the very simple solution to have a double +NAT'ed network working with freeswan. (Not sure if this is old news, but I'm +not on the list (too much spam) and I didn't read this in any HOWTO/FAQ/doc +on the freeswan site yet (Sandy, put it in! :) + +10.0.0.0/24 --- 10.0.0.1 a.b.c.d ---- a.b.c.e {internet} ----+ + | +10.0.1.0/24 --- 10.0.1.1 f.g.h.i ---- f.g.h.j {internet} ----+ + +the goal is to have the first network do a VPN to the second one, yet also +have NAT in place for connections not destinated for the other side of the +NAT. Here the two Linux security gateways have one real IP number (cable +modem, dialup, whatever. + +The problem with NAT is you don't want packets from 10.*.*.* to 10.*.*.* +to be NAT'ed. While with Linux 2.2, you can't, with Linux 2.4 you can. + +(This has been tested and works for 2.4.2 with Freeswan snapshot2001mar8b) + +relevant parts of /etc/ipsec.conf: + + left=f.g.h.i + leftsubnet=10.0.1.0/24 + leftnexthop=f.g.h.j + leftfirewall=yes + leftid=@firewall.netone.nl + leftrsasigkey=0x0........ + right=a.b.c.d + rightsubnet=10.0.0.0/24 + rightnexthop=a.b.c.e + rightfirewall=yes + rightid=@firewall.nettwo.nl + rightrsasigkey=0x0...... + # To authorize this connection, but not actually start it, at startup, + # uncomment this. + auto=add + +and now the real trick. Setup the NAT correctly on both sites: + +iptables -t nat -F +iptables -t nat -A POSTROUTING -o eth0 -d \! 10.0.0.0/8 -j MASQUERADE + +This tells the NAT code to only do NAT for packets with destination other then +10.* networks. note the backslash to mask the exclamation mark to protect it +against the shell. + +Happy painting :) + +Paul</pre> + +<h3><a name="dup_route">Can I use subnets masqueraded to the same +addresses?</a></h3> + +<p><strong>No.</strong> The notion that IP addresses are unique is one of the +fundamental principles of the IP protocol. Messing with it is exceedingly +perilous.</p> + +<p>Fairly often a situation comes up where a company has several branches, +all using the same <a href="glossary.html#non-routable">non-routable +addresses</a>, perhaps 192.168.0.0/24. This works fine as long as those nets +are kept distinct. The <a href="glossary.html#masq">IP masquerading</a> on +their firewalls ensures that packets reaching the Internet carry the firewall +address, not the private address.</p> + +<p>This can break down when IPsec enters the picture. FreeS/WAN builds a +tunnel that pokes through both masquerades and delivers packets from +<var>leftsubnet</var> to <var>rightsubnet</var> and vice versa. For this to +work, the two subnets <em>must</em> be distinct.</p> + +<p>There are several solutions to this problem.</p> + +<p>Usually, you <strong>re-number the subnets</strong>. Perhaps the Vancouver +office becomes 192.168.101.0/24, Calgary 192.168.102.0/24 and so on. +FreeS/WAN can happily handle this. With, for example +<var>leftsubnet=192.168.101.0/24</var> and +<var>rightsubnet=192.168.102.0/24</var> in a connection description, any +machine in Calgary can talk to any machine in Vancouver. If you want to be +more restrictive and use something like +<var>leftsubnet=192.168.101.128/25</var> and +<var>rightsubnet=192.168.102.240/28</var> so only certain machines on each +end have access to the tunnel, that's fine too.</p> + +<p>You could also <strong>split the subnet</strong> into smaller ones, for +example using <var>192.168.1.0/25</var> in Vancouver and +<var>rightsubnet=192.168.0.128/25</var> in Calgary.</p> + +<p>Alternately, you can just <strong>give up routing</strong> directly to +machines on the subnets. Omit the <var>leftsubnet</var> and +<var>rightsubnet</var> parameters from your connection descriptions. Your +IPsec tunnels will then run between the public interfaces of the two +firewalls. Packets will be masqueraded both before they are put into tunnels +and after they emerge. Your Vancouver client machines will see only one +Calgary machine, the firewall.</p> + +<h3><a name="road.masq">Can I assign a road warrior an address on my net (a +virtual identity)?</a></h3> + +<p>Often it would be convenient to be able to give a Road Warrior an IP +address which appears to be on the local network. Some IPsec implementations +have support for this, sometimes calling the feature "virtual identity".</p> + +<p>Currently (Sept 2002) FreeS/WAN does not support this, and we have +no definite plans to add it. The difficulty is that is not yet a standard +mechanism for it. There is an Internet Draft for a method of doing it using +<a href="#DHCP">DHCP</a> which looks promising. FreeS/WAN may support that in +a future release.</p> + +<p>In the meanwhile, you can do it yourself using the Linux iproute2(8) +facilities. Details are in <a +href="http://www.av8n.com/vpn/iproute2.htm">this +paper</a>.</p> + +<p>Another method has also been discussed on the mailing list.:</p> +<ul> + <li>You can use a variant of the <a + href="adv_config.html#extruded.config">extruded subnet</a> procedure.</li> + <li>You have to avoid having the road warrior's assigned address within the + range you actually use at home base. See previous question.</li> + <li>On the other hand, you want the roadwarrior's address to be within the + range that <em>seems</em> to be on your network.</li> +</ul> + +<p>For example, you might have:</p> +<dl> + <dt>leftsubnet=a.b.c.0/25</dt> + <dd>head office network</dd> + <dt>rightsubnet=a.b.c.129/32</dt> + <dd>extruded to a road warrior. Note that this is not in a.b.c.0/25</dd> + <dt>a.b.c.0/24</dt> + <dd>whole network, including both the above</dd> +</dl> + +<p>You then set up routing so that the office machines use the IPsec gateway +as their route to a.b.c.128/25. The leftsubnet parameter tells the road +warriors to use tunnels to reach a.b.c.0/25, so you should have two-way +communication. Depending or your network and applications, there may be some +additional work to do on DNS or Windows configuration</p> + +<h3><a name="road.many">Can I support many road warriors with one +gateway?</a></h3> + +<p>Yes. This is easily done, using</p> +<dl> + <dt>either RSA authentication</dt> + <dd>standard in the FreeS/WAN distribution</dd> + <dt>or X.509 certificates</dt> + <dd>requires <a href="#PKIcert">Super FreeS/WAN or a patch</a>.</dd> +</dl> + +<p>In either case, each Road Warrior must have a different key or +certificate.</p> + +<p>It is also possible using pre-shared key authentication, +though we don't recommend this; see the +<a href="#road.PSK">next question</a> for details.</p> + +<p>If you expect to have more than a few dozen Road Warriors connecting +simultaneously, you may need a fairly powerful gateway machine. See our +document on <a href="performance.html">FreeS/WAN performance</a>.</p> + +<h3><a name="road.PSK">Can I have many road warriors using shared secret +authentication?</a></h3> + +<p><STRONG>Yes, but avoid it if possible</STRONG>.</p> + +<p>You can have multiple Road Warriors using shared secret authentication +<strong>only if they all use the same secret</strong>. You must also +set:<p> + +<PRE> uniqueids=no </PRE> + +<p>in the connection definition.</p> + + +<p>Why it's less secure:</p> +<ul> + <li>If you have many users, it becomes almost certain the secret will + leak</li> + <li>The secret becomes quite valuable to an attacker</li> + <li>All users authenticate the same way, so the gateway cannot tell them + apart for logging or access control purposes</li> + <li>Changing the secret is difficult. You have to securely notify all + users.</li> + <li>If you find out the secret has been compromised, you can change it, but + then what? None of your users can connect without the new secret. How + will you notify them all, quickly and securely, without using the + VPN?</li> +</ul> + +<p>This is a designed-in limitation of the <a +href="glossary.html#IKE">IKE</a> key negotiation protocol, not a problem with +our implementation.</p> + +<p><strong>We very strongly recommend that you avoid using shared secret +authentication for multiple Road Warriors.</strong> Use RSA authentication +instead.</p> + +<p>The longer story: When using shared secrets, the protocol requires +that the responding +gateway be able to determine which secret to use at a time when all it knows +about the initiator is an IP address. This works fine if you know the +initiator's address in advance and can use it to look up the appropiriate +secret. However, it fails for Road Warriors since the gateway cannot know +their IP addresses in advance.</p> + +<p>With RSA signatures (or certificates) the protocol is slightly different. +The initiator provides an identifier early in the exchange and the responder +can use that identifier to look up the correct key or certificate. See <a +href="#road.many">above</a>.</p> + +<h3><a name="QoS">Can I use Quality of Service routing with +FreeS/WAN?</a></h3> + +<p>From project technical lead Henry Spencer:</p> +<pre>> Do QoS add to FreeS/WAN? +> For example integrating DiffServ and FreeS/WAN? + +With a current version of FreeS/WAN, you will have to add hidetos=no to +the config-setup section of your configuration file. By default, the TOS +field of tunnel packets is zeroed; with hidetos=no, it is copied from the +packet inside. (This is a modest security hole, which is why it is no +longer the default.) + +DiffServ does not interact well with tunneling in general. Ways of +improving this are being studied.</pre> + +<p>Copying the <a href="glossary.html#TOS">TOS</a> (type of service) +information from the encapsulated packet to the outer header reveals the TOS +information to an eavesdropper. This does not tell him much, but it might be +of use in <a href="glossary.html#traffic">traffic analysis</a>. Since we do +not have to give it to him, our default is not to.</p> + +<P>Even with the TOS hidden, you can still:</P> +<UL> +<LI>apply QOS rules to the tunneled (ESP) packets; for example, by +giving ESP packets a certain priority.</LI> +<LI>apply QOS rules to the packets as they enter or exit the tunnel +via an IPsec virtual interface (eg. <VAR>ipsec0</VAR>).</LI> +</UL> + +<p>See <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> for more on +the <var>hidetos=</var> parameter.</p> + + +<h3><a name="deadtunnel">Can I recognise dead tunnels and shut them +down?</a></h3> + +<p>There is no general mechanism to do this is in the IPsec protocols.</p> + +<p>From time to time, there is discussion on the IETF Working Group <a +href="mail.html#ietf">mailing list</a> of adding a "keep-alive" mechanism +(which some say should be called "make-dead"), but it is a fairly complex +problem and no consensus has been reached on whether or how it should be +done.</p> + +<p>The protocol does have optional <a href="#ignore">delete-SA</a> messages +which one side can send when it closes a connection in hopes this will cause +the other side to do the same. FreeS/WAN does not currently support these. In +any case, they would not solve the problem since:</p> +<ul> + <li>a gateway that crashes or hangs would not send the messages</li> + <li>the sender is not required to send them</li> + <li>they are not authenticated, so any receiver that trusts them leaves + itself open to a <a href="glossary.html#DOS">denial of service</a> + attack</li> + <li>the receiver is not required to do anything about them</li> + <li>the receiver cannot acknowledge them; the protocol provides no + mechanism for that</li> + <li>since they are not acknowledged, the sender cannot rely on them</li> +</ul> + +<p>However, connections do have limited lifetimes and you can control how +many attempts your gateway makes to rekey before giving up. For example, you +can set:</p> +<pre>conn default + keyingtries=3 + keylife=30m</pre> + +<p>With these settings old connections will be cleaned up. Within 30 minutes +of the other end dying, rekeying will be attempted. If it succeeds, the new +connection replaces the old one. If it fails, no new connection is created. +Either way, the old connection is taken down when its lifetime expires.</p> + +<p>Here is a mailing list message on the topic from FreeS/WAN tech support +person Claudia Schmeing:</p> +<pre>You ask how to determine whether a tunnel is redundant: + +> Can anybody explain the best way to determine this. Esp when a RW has +> disconnected? I thought 'ipsec auto --status' might be one way. + +If a tunnel goes down from one end, Linux FreeS/WAN on the +other end has no way of knowing this until it attempts to rekey. +Once it tries to rekey and fails, it will 'know' that the tunnel is +down. + +Because it doesn't have a way of knowing the state until this point, +it will also not be able to tell you the state via ipsec auto --status. + +> However, comparing output from a working tunnel with that of one that +> was closed +> did not show clearly show tunnel status. + +If your tunnel is down but not 'unrouted' (see man ipsec_auto), you +should not be able to ping the opposite side of the tunnel. You can +use this as an indicator of tunnel status. + +On a related note, you may be interested to know that as of 1.7, +redundant tunnels caused by RW disconnections are likely to be +less of a pain. From doc/CHANGES: + + There is a new configuration parameter, uniqueids, to control a new Pluto + option: when a new connection is negotiated with the same ID as an old + one, the old one is deleted immediately. This should help eliminate + dangling Road Warrior connections when the same Road Warrior reconnects. + It thus requires that IDs not be shared by hosts (a previously legal but + probably useless capability). NOTE WELL: the sample ipsec.conf now has + uniqueids=yes in its config-setup section. + + +Cheers, + +Claudia</pre> + +<h3><a name="demanddial">Can I build IPsec tunnels over a demand-dialed +link?</a></h3> + +<p>This is possible, but not easy. FreeS/WAN technical lead Henry Spencer +wrote:</p> +<pre>> 5. If the ISDN link goes down in between and is reestablished, the SAs +> are still up but the eroute are deleted and the IPsec interface shows +> garbage (with ifconfig) +> 6. Only restarting IPsec will bring the VPN back online. + +This one is awkward to solve. If the real interface that the IPsec +interface is mounted on goes down, it takes most of the IPsec machinery +down with it, and a restart is the only good way to recover. + +The only really clean fix, right now, is to split the machines in two: + +1. A minimal machine serves as the network router, and only it is aware +that the link goes up and down. + +2. The IPsec is done on a separate gateway machine, which thinks it has +a permanent network connection, via the router. + +This is clumsy but it does work. Trying to do both functions within a +single machine is tricky. There is a software package (diald) which will +give the illusion of a permanent connection for demand-dialed modem +connections; I don't know whether it's usable for ISDN, or whether it can +be made to cooperate properly with FreeS/WAN. + +Doing a restart each time the interface comes up *does* work, although it +is a bit painful. I did that with PPP when I was running on a modem link; +it wasn't hard to arrange the PPP scripts to bring IPsec up and down at +the right times. (I'd meant to investigate diald but never found time.) + +In principle you don't need to do a complete restart on reconnect, but you +do have to rebuild some things, and we have no nice clean way of doing +only the necessary parts.</pre> + +<p>In the same thread, one user commented:</p> +<pre>Subject: Re: linux-ipsec: IPsec and Dial Up Connections + Date: Wed, 22 Nov 2000 + From: Andy Bradford <andyb@calderasystems.com> + +On Wed, 22 Nov 2000 19:47:11 +0100, Philip Reetz wrote: + +> Are there any ideas what might be the cause of the problem and any way +> to work around it. +> Any help is highly appreciated. + +On my laptop, when using ppp there is a ip-up script in /etc/ppp that +will be executed each time that the ppp interface is brought up. +Likewise there is an ip-down script that is called when it is taken +down. You might consider custimzing those to stop and start FreeS/WAN +with each connection. I believe that ISDN uses the same files, though +I could be wrong---there should be something similar though.</pre> + +<h3><a name="GRE">Can I build GRE, L2TP or PPTP tunnels over IPsec?</a></h3> + +<p>Yes. Normally this is not necessary, but it is useful in a few special +cases. For example, if you must route non-IP packets such as IPX, you +will need to use a tunneling protocol that can route these packets. IPsec +can be layered around it for extra security. Another example: you +can provide failover protection for high availability (HA) environments by +combining IPsec with other tools. Ken Bantoft describes one such setup in +<A HREF="http://www.freeswan.ca/docs/HA">Using FreeS/WAN with Linux-HA, GRE, +OSPF and BGP for enterprise grade VPN solutions</A>.</P> + +<p>GRE over IPsec is covered as part of +<A HREF="http://www.freeswan.ca/docs/HA">that document</A>. +<a href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00209.html"> +Here are links</a> to other GRE resources. + +Jacco de Leuw has created +<A HREF="http://www.jacco2.dds.nl/networking/">this page on L2TP over IPsec</A> +with instructions for FreeS/WAN and several other brands of IPsec software. +</P> + +<P>Please let us know of other useful links via the +<A HREF="mail.html">mailing lists</A>. + + +<h3><a name="NetBIOS">... use Network Neighborhood (Samba, NetBIOS) over IPsec?</a></h3> + +<p>Your local PC needs to know how to translate NetBIOS names to IP addresses. +It may do this either via a local LMHOSTS file, or using a local or remote +WINS server. The WINS server is preferable since it provides a centralized +source of the information to the entire network. To use a WINS server over +the <A HREF="glossary.html#VPN">VPN</A> +(or any IP-based network), you must enable "NetBIOS over TCP".</p> + +<p><A HREF="http://www.samba.org">Samba</A> can emulate a WINS server +on Linux.</p> + +<p> +See also several discussions in our +<A HREF="http://lists.freeswan.org/pipermail/users/2002-September/thread.html">September +2002 Users archives</A></p> + + +<h2><a name="setup.faq">Life's little mysteries</a></h2> + +<p>FreeS/WAN is a fairly complex product. (Neither the networks it runs on +nor the protocols it uses are simple, so it could hardly be otherwise.) It +therefore sometimes exhibits behaviour which can be somewhat confusing, or +has problems which are not easy to diagnose. This section tries to explain +those problems.</p> + +<p>Setup and configuration of FreeS/WAN are covered in other documentation +sections:</p> +<ul> + <li><a href="quickstart.html">basic setup and configuration</a></li> + <li><a href="adv_config.html">advanced configuration</a></li> + <li><a href="trouble.html">Troubleshooting</a></li> +</ul> + +<p>However, we also list some of the commonest problems here.</p> + +<h3><a name="cantping">I cannot ping ....</a></h3> + +<p>This question is dealt with in the advanced configuration section under +the heading <a href="adv_config.html#multitunnel">multiple tunnels</a>.</p> + +<p>The standard subnet-to-subnet tunnel protects traffic <strong>only between +the subnets</strong>. To test it, you must use pings that go from one subnet +to the other.</p> + +<p>For example, suppose you have:</p> +<pre> subnet a.b.c.0/24 + | + eth1 = a.b.c.1 + gate1 + eth0 = 192.0.2.8 + | + + ~ internet ~ + + | + eth0 = 192.0.2.11 + gate2 + eth1 = x.y.z.1 + | + subnet x.y.z.0/24</pre> + +<p>and the connection description:</p> +<pre>conn abc-xyz + left=192.0.2.8 + leftsubnet=a.b.c.0/24 + right=192.0.2.11 + rightsubnet=x.y.z.0/24</pre> + +<p>You can test this connection description only by sending a ping that will +actually go through the tunnel. Assuming you have machines at addresses +a.b.c.2 and x.y.z.2, pings you might consider trying are:</p> +<dl> + <dt>ping from x.y.z.2 to a.b.c.2 or vice versa</dt> + <dd>Succeeds if tunnel is working. This is the <strong>only valid test of + the tunnel</strong>.</dd> + <dt>ping from gate2 to a.b.c.2 or vice versa</dt> + <dd><strong>Does not use tunnel</strong>. gate2 is not on protected + subnet.</dd> + <dt>ping from gate1 to x.y.z.2 or vice versa</dt> + <dd><strong>Does not use tunnel</strong>. gate1 is not on protected + subnet.</dd> + <dt>ping from gate1 to gate2 or vice versa</dt> + <dd><strong>Does not use tunnel</strong>. Neither gate is on a protected + subnet.</dd> +</dl> + +<p>Only the first of these is a useful test of this tunnel. The others do not +use the tunnel. Depending on other details of your setup and routing, +they:</p> +<ul> + <li>either fail, telling you nothing about the tunnel</li> + <li>or succeed, telling you nothing about the tunnel since these packets + use some other route</li> +</ul> + +<p>In some cases, you may be able to get around this. For the example network +above, you could use:</p> +<pre> ping -I a.b.c.1 x.y.z.1</pre> + +<p>Both the adresses given are within protected subnets, so this should go +through the tunnel.</p> + +<p>If required, you can build additional tunnels so that all the machines +involved can talk to all the others. See <a +href="adv_config.html#multitunnel">multiple tunnels</a> in the advanced +configuration document for details.</p> + +<h3><a name="forever">It takes forever to ...</a></h3> + +<p>Users fairly often report various problems involving long delays, +sometimes on tunnel setup and sometimes on operations done through the +tunnel, occasionally on simple things like ping or more often on more complex +operations like doing NFS or Samba through the tunnel.</p> + +<p>Almost always, these turn out to involve failure of a DNS lookup. The +timeouts waiting for DNS are typically set long so that you won't time out +when a query involves multiple lookups or long paths. Genuine failures +therefore produce long delays before they are detected.</p> + +<p>A mailing list message from project technical lead Henry Spencer:</p> +<pre>> ... when i run /etc/rc.d/init.d/ipsec start, i get: +> ipsec_setup: Starting FreeS/WAN IPsec 1.5... +> and it just sits there, doesn't give back my bash prompt. + +Almost certainly, the problem is that you're using DNS names in your +ipsec.conf, but DNS lookups are not working for some reason. You will +get your prompt back... eventually. But the DNS timeouts are long. +Doing something about this is on our list, but it is not easy.</pre> + +<p>In the meanwhile, we recommend that connection descriptions in <a +href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> use numeric IP addresses +rather than names which will require a DNS lookup.</p> + +<p>Names that do not require a lookup are fine. For example:</p> +<ul> + <li>a road warrior might use the identity + <var>rightid=@lancelot.example.org</var></li> + <li>the gateway might use <var>leftid=@camelot.example.org</var></li> +</ul> + +<p>These are fine. The @ sign prevents any DNS lookup. However, do not +attempt to give the gateway address as <var>left=camelot.example.org</var>. +That requires a lookup.</p> + +<p>A post from one user after solving a problem with long delays:</p> +<pre>Subject: Final Answer to Delay!!! + Date: Mon, 19 Feb 2001 + From: "Felippe Solutions" <felippe@solutionstecnologia.com.br> + +Sorry people, but seems like the Delay problem had nothing to do with +freeswan. + +The problem was DNS as some people sad from the beginning, but not the way +they thought it was happening. Samba, ssh, telnet and other apps try to +reverse lookup addresses when you use IP numbers (Stupid that ahh). + +I could ping very fast because I always ping with "-n" option, but I don't +know the option on the other apps to stop reverse addressing so I don't use +it.</pre> + +<p>This post is fairly typical. These problems are often tricky and +frustrating to diagnose, and most turn out to be DNS-related.</p> + +<p>One suggestion for diagnosis: test with both names and addresses if +possible. For example, try all of:</p> +<ul> + <li>ping <var>address</var></li> + <li>ping -n <var>address</var></li> + <li>ping <var>name</var></li> +</ul> + +<p>If these behave differently, the problem must be DNS-related since the +three commands do exactly the same thing except for DNS lookups.</p> + +<h3><a name="route">I send packets to the tunnel with route(8) but they +vanish</a></h3> + +<p>IPsec connections are designed to carry only packets travelling between +pre-defined connection endpoints. As project technical lead Henry Spencer put +it:</p> + +<blockquote> + IPsec tunnels are not just virtual wires; they are virtual wires with + built-in access controls. Negotiation of an IPsec tunnel includes + negotiation of access rights for it, which don't include packets to/from + other IP addresses. (The protocols themselves are quite inflexible about + this, so there are limits to what we can do about it.)</blockquote> + +<p>For fairly obvious security reasons, and to comply with the IPsec RFCs, <a +href="glossary.html#KLIPS">KLIPS</a> drops any packets it receives that are +not allowed on the tunnels currently defined. So if you send it packets with +<var>route(8)</var>, and suitable tunnels are not defined, the packets +vanish. Whether this is reported in the logs depends on the setting of +<var>klipsdebug</var> in your <a +href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> file.</p> + +<p>To rescue vanishing packets, you must ensure that suitable tunnels for +them exist, by editing the connection descriptions in <a +href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>. For example, supposing +you have a simple setup:</p> +<pre> leftsubnet -- leftgateway === internet === roadwarrior</pre> + +<p>If you want to give the roadwarrior access to some resource that is +located behind the left gateway but is not in the currently defined left +subnet, then the usual procedure is to define an additional tunnel for those +packets by creating a new connection description.</p> + +<p>In some cases, it may be easier to alter an existing connection +description, enlarging the definition of <var>leftsubnet</var>. For example, +instead of two connection descriptions with 192.168.8.0/24 and 192.168.9.0/24 +as their <var>leftsubnet</var> parameters, you can use a single description +with 192.168.8.0/23.</p> + +<p>If you have multiple endpoints on each side, you need to ensure that there +is a route for each pair of endpoints. See this <a +href="adv_config.html#multitunnel">example</a>.</p> + +<h3><a name="down_route">When a tunnel goes down, packets vanish</a></h3> + +<p>This is a special case of the vanishing packet problem described in the +previous question. Whenever KLIPS sees packets for which it does not have a +tunnel, it drops them.</p> + +<p>When a tunnel goes away, either because negotiations with the other +gateway failed or because you gave an <var>ipsec auto --down</var> command, +the route to its other end is left pointing into KLIPS, and KLIPS will drop +packets it has no tunnel for.</p> + +<p>This is a documented design decision, not a bug. FreeS/WAN must not +automatically adjust things to send packets via another route. The other +route might be insecure.</p> + +<p>Of course, re-routing may be necessary in many cases. In those cases, you +have to do it manually or via scripts. We provide the <var>ipsec auto +--unroute</var> command for these cases.</p> + +<p>From <a href="manpage.d/ipsec_auto.8.html">ipsec_auto(8)</a>:</p> + +<blockquote> + Normally, pluto establishes a route to the destination specified for a + connection as part of the --up operation. However, the route and only + the route can be established with the --route operation. Until and unless + an actual connection is established, this discards any packets sent + there, which may be preferable to having them sent elsewhere based on a + more general route (e.g., a default route).</blockquote> + +<blockquote> + Normally, pluto's route to a destination remains in place when a --down + operation is used to take the connection down (or if connection setup, or + later automatic rekeying, fails). This permits establishing a new + connection (perhaps using a different specification; the route is altered + as necessary) without having a ``window'' in which packets might go + elsewhere based on a more general route. Such a route can be removed + using the --unroute operation (and is implicitly removed by +--delete).</blockquote> + +<p>See also this mailing list <a +href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00523.html">message</a>.</p> + +<h3><a name="firewall_ate">The firewall ate my packets!</a></h3> + +<p>If firewalls filter out:</p> +<ul> + <li>either the UDP port 500 packets used in IKE negotiations</li> + <li>or the ESP and AH (protocols 50 and 51) packets used to implement the + IPsec tunnel</li> +</ul> + +<p>then IPsec cannot work. The first thing to check if packets seem to be +vanishing is the firewall rules on the two gateway machines and any other +machines along the path that you have access to.</p> + +<p>For details, see our document on <a href="firewall.html">firewalls</a>.</p> + +<p>Some advice from technical lead Henry Spencer on diagnosing such +problems:</p> +<pre>> > Packets vanishing between the hardware interface and the ipsecN interface +> > is usually the result of firewalls not being configured to let them in... +> +> Thanks for the suggestion. If only it were that simple! My ipchains startup +> script does take care of that, but just in case I manually inserted rules +> accepting everything from london on dublin. No difference. + +The other thing to check is whether the "RX packets dropped" count on the +ipsecN interface (run "ifconfig ipsecN", for N=1 or whatever, to see the +counts) is rising. If so, then there's some sort of configuration mismatch +between the two ends, and IPsec itself is rejecting them. If none of the +ipsecN counts is rising, then the packets are never reaching the IPsec +machinery, and the problem is almost certainly in firewalls etc.</pre> + +<h3><a name="dropconn">Dropped connections</a></h3> + +<p>Networks being what they are, IPsec connections can be broken for any +number of reasons, ranging from hardware failures to various software +problems such as the path MTU problems discussed <a +href="#pmtu.broken">elsewhere in the FAQ</a>. Fortunately, various diagnostic +tools exist that help you sort out many of the possible problems.</p> + +<p>There is one situation, however, where FreeS/WAN (using default settings) +may destroy a connection for no readily apparent reason. This occurs when +things are <strong>misconfigured</strong> so that <strong>two +tunnels</strong> from the same gateway expect <strong>the same subnet on the +far end</strong>.</p> + +<p>In this situation, the first tunnel comes up fine and works until the +second is established. At that point, because of the way we track connections +internally, the first tunnel ceases to exist as far as this gateway is +concerned. Of course the far end does not know that, and a storm of error +messages appears on both systems as it tries to use the tunnel.</p> + +<p>If the far end gives up, goes back to square one and negotiates a new +tunnel, then that wipes out the second tunnel and ...</p> + +<p>The solution is simple. <strong>Do not build multiple conn descriptions +with the same remote subnet</strong>.</p> + +<p>This is actually intended to be a feature, rather than a bug. Consider the +situation where a single remote system goes down, then comes back up and +reconnects to the gateway. It is useful to have the gateway tear down the old +tunnel and recover resources when the reconnection is made. It recognises +that situation by checking the remote subnet for each tunnel it builds and +discarding duplicates. This works fine as long as you don't configure +multiple tunnels with the same remote subnet.</p> + +<p>If this behaviour is inconvenient for you, you can disable it by setting +<var>uniqueids=no</var> in <a +href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p> + + +<h3><a name="defaultroutegone">Disappearing %defaultroute</a></h3> + +<p>When an underlying connection (eg. ppp) goes down, FreeS/WAN will not +recover properly without a little help. Here are the symptoms that FreeS/WAN +user Michael Carmody noticed: +<pre> +> After about 24 hours the freeswan connection takes over the default route. +> +> i.e instead of deafult gateway pointing to the router via eth0, it becomes a +> pointer to the router via ipsec0. + +> All internet access is then lost as all replies (and not just the link I +> wanted) are routed out ipsec0 and the router doesn't respond to the ipsec +> traffic. +</pre> + +<p>If you're using a +FreeS/WAN 2.x/KLIPS system, simply re-attach the IPsec virtual +interface with <em>ipsec tnconfig</em> command such as:</p> +<pre> ipsec tnconfig --attach --virtual ipsec0 --physical ppp0</pre> +<p>In your command, name the physical and virtual interfaces as they +appear paired on your system during regular uptime. For a system with several +physical/virtual interface pairs on flaky links, you'll need more than +one such command. +If you're using FreeS/WAN 1.x, you must restart FreeS/WAN, which is more time +consuming.</p> + +<p> +<A href="http://lists.freeswan.org/pipermail/design/2002-July/003070.html">Here</A> +is a script which can help to automate the process of FreeS/WAN restart at +need. +It could easily be adapted to use tnconfig instead.</p> + +<h3><a name="tcpdump.faq">TCPdump on the gateway shows strange things</a></h3> + +As another user pointed out, keeping the connect +<p>Attempting to look at IPsec packets by running monitoring tools on the +IPsec gateway machine can produce silly results. That machine is mangling the +packets for IPsec, and possibly for firewall or NAT purposes as well. If the +internals of the machine's IP stack are not what the monitoring tool expects, +then the tool can misinterpret them and produce nonsense output.</p> + +<p>See our <a href="testing.html#tcpdump.test">testing</a> document for more +detail.</p> + +<h3><a name="no_trace">Traceroute does not show anything between the +gateways</a></h3> + +<p>As far as traceroute can see, the two gateways are one hop apart; the data +packet goes directly from one to the other through the tunnel. Of course the +outer packets that implement the tunnel pass through whatever lies between +the gateways, but those packets are built and dismantled by the gateways. +Traceroute does not see them and cannot report anything about their path.</p> + +<p>Here is a mailing list message with more detail.</p> +<pre>Date: Mon, 14 May 2001 +To: linux-ipsec@freeswan.org +From: "John S. Denker" <jsd@research.att.com< +Subject: Re: traceroute: one virtual hop + +At 02:20 PM 5/14/01 -0400, Claudia Schmeing wrote: +> +>> > A bonus question: traceroute in subnet to subnet enviroment looks like: +>> > +>> > traceroute to andris.dmz (172.20.24.10), 30 hops max, 38 byte packets +>> > 1 drama (172.20.1.1) 0.716 ms 0.942 ms 0.434 ms +>> > 2 * * * +>> > 3 andris.dmz (172.20.24.10) 73.576 ms 78.858 ms 79.434 ms +>> > +>> > Why aren't there the other hosts which take part in the delivery during +> * * * ? +> +>If there is an ipsec tunnel between GateA and Gate B, this tunnel forms a +>'virtual wire'. When it is tunneled, the original packet becomes an inner +>packet, and new ESP and/or AH headers are added to create an outer packet +>around it. You can see an example of how this is done for AH at +>doc/ipsec.html#AH . For ESP it is similar. +> +>Think about the packet's path from the inner packet's perspective. +>It leaves the subnet, goes into the tunnel, and re-emerges in the second +>subnet. This perspective is also the only one available to the +>'traceroute' command when the IPSec tunnel is up. + +Claudia got this exactly right. Let me just expand on a couple of points: + +*) GateB is exactly one (virtual) hop away from GateA. This is how it +would be if there were a physically private wire from A to B. The +virtually private connection should work the same, and it does. + +*) While the information is in transit from GateA to GateB, the hop count +of the outer header (the "envelope") is being decremented. The hop count +of the inner header (the "contents" of the envelope) is not decremented and +should not be decremented. The hop count of the outer header is not +derived from and should not be derived from the hop count of the inner header. + +Indeed, even if the packets did time out in transit along the tunnel, there +would be no way for traceroute to find out what happened. Just as +information cannot leak _out_ of the tunnel to the outside, information +cannot leak _into_ the tunnel from outside, and this includes ICMP messages +from routers along the path. + +There are some cases where one might wish for information about what is +happening at the IP layer (below the tunnel layer) -- but the protocol +makes no provision for this. This raises all sorts of conceptual issues. +AFAIK nobody has ever cared enough to really figure out what _should_ +happen, let alone implement it and standardize it. + +*) I consider the "* * *" to be a slight bug. One might wish for it to be +replaced by "GateB GateB GateB". It has to do with treating host-to-subnet +traffic different from subnet-to-subnet traffic (and other gory details). +I fervently hope KLIPS2 will make this problem go away. + +*) If you want to ask questions about the link from GateA to GateB at the +IP level (below the tunnel level), you have to ssh to GateA and launch a +traceroute from there.</pre> + +<h2><a name="man4debug">Testing in stages</a></h2> + +<p>It is often useful in debugging to test things one at a time:</p> +<ul> + <li>disable IPsec entirely, for example by turning it off with + chkconfig(8), and make sure routing works</li> + <li>Once that works, try a manually keyed connection. This does not require + key negotiation between Pluto and the key daemon on the other end.</li> + <li>Once that works, try automatically keyed connections</li> + <li>Once IPsec works, add packet compression</li> + <li>Once everything seems to work, try stress tests with large transfers, + many connections, frequent re-keying, ...</li> +</ul> + +<p>FreeS/WAN releases are tested for all of these, so you can be reasonably +certain they <em>can</em> do them all. Of course, that does not mean they +<em>will</em> on the first try, especially if you have some unusual +configuration.</p> + +<p>The rest of this section gives information on diagnosing the problem when +each of the above steps fails.</p> + +<h3><a name="nomanual">Manually keyed connections don't work</a></h3> + +<p>Suspect one of:</p> +<ul> + <li>mis-configuration of IPsec system in the /etc/ipsec.conf file<br> + common errors are incorrect interface or next hop information</li> + <li>mis-configuration of manual connection in the /etc/ipsec.conf file</li> + <li>routing problems causing IPsec packets to be lost</li> + <li>bugs in KLIPS</li> + <li>mismatch between the transforms we support and those another IPsec + implementation offers.</li> +</ul> + +<h3><a name="spi_error">One manual connection works, but second one +fails</a></h3> + +<p>This is a fairly common problem when attempting to configure multiple +manually keyed connections from a single gateway.</p> + +<p>Each connection must be identified by a unique <a +href="glossary.html#SPI">SPI</a> value. For automatic connections, these +values are assigned automatically. For manual connections, you must set them +with <var>spi=</var> statements in <a +href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p> + +<p>Each manual connection must have a unique SPI value in the range 0x100 to +0x999. Two or more with the same value will fail. For details, see our doc +section <a href="adv_config.html#prodman">Using manual keying in +production</a> and the man page <a +href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p> + +<h3><a name="man_no_auto">Manual connections work, but automatic keying +doesn't</a></h3> + +<p>The most common reason for this behaviour is a firewall dropping the UDP +port 500 packets used in key negotiation.</p> + +<p>Other possibilities:</p> +<ul> + <li>mis-configuration of auto connection in the /etc/ipsec.conf file. + <p>One common configuration error is forgetting that you need + <var>auto=add</var> to load the connection description on the receiving + end so it recognises the connection when the other end asks for it.</p> + </li> + <li>error in shared secret in /etc/ipsec.secrets</li> + <li>one gateway lacks a route to the other so Pluto's UDP packets are + lost</li> + <li>bugs in Pluto</li> + <li>incompatibilities between Pluto's <a href="glossary.html#IKE">IKE</a> + implementation and the IKE at the other end of the tunnel. + <p>Some possibile problems are discussed in out <a + href="interop.html#interop.problem">interoperation</a> document.</p> + </li> +</ul> + +<h3><a name="nocomp">IPsec works, but connections using compression +fail</a></h3> + +<p>When we first added compression, we saw some problems:</p> +<ul> + <li>compatibility issues with other implementations. We followed the RFCs + and omitted some extra material that many compression libraries add by + default. Some other implementations left the extras in</li> + <li>bugs in assembler compression routines on non-Intel CPUs. The + workaround is to use C code instead of possibly problematic + assembler.</li> +</ul> + +<p>We have not seen either problem in some time (at least six months as I +write in March 2002), but if you have some unusual configuration then you may +see them.</p> + +<h3><a name="pmtu.broken">Small packets work, but large transfers +fail</a></h3> + +<p>If tests with ping(1) and a small packet size succeed, but tests or +transfers with larger packet sizes fail, suspect problems with packet +fragmentation and perhaps <a href="glossary.html#pathMTU">path MTU +discovery</a>.</p> + +<p>Our <a href="trouble.html#bigpacket">troubleshooting document</a> covers +these problems. Information on the underlying mechanism is in our <a +href="background.html#MTU.trouble">background</a> document.</p> + +<h3><a name="subsub">Subnet-to-subnet works, but tests from the gateways +don't</a></h3> + +<p>This is described under <a href="#cantping">I cannot ping...</a> above.</p> + +<h2><a name="compile.faq">Compilation problems</a></h2> + +<h3><a name="gmp.h_missing">gmp.h: No such file or directory</a></h3> + +<p>Pluto needs the GMP (<strong>G</strong>NU</p> + +<p><strong>M</strong>ulti-<strong>P</strong>recision) library for the large +integer calculations it uses in <a href="glossary.html#public">public key</a> +cryptography. This error message indicates a failure to find the library. You +must install it before Pluto will compile.</p> + +<p>The GMP library is included in most Linux distributions. Typically, there +are two RPMs, libgmp and libgmp-devel, You need to <em>install both</em>, +either from your distribution CDs or from your vendor's web site.</p> + +<p>On Debian, a mailing list message reports that the command to give is +<var>apt-get install gmp2</var>.</p> + +<p>For more information and the latest version, see the <a +href="http://www.swox.com/gmp/">GMP home page</a>.</p> + +<h3><a name="noVM">... virtual memory exhausted</a></h3> + +<p>We have had several reports of this message appearing, all on SPARC Linux. +Here is a mailing message on a solution:</p> +<pre>> ipsec_sha1.c: In function `SHA1Transform': +> ipsec_sha1.c:95: virtual memory exhausted + +I'm seeing exactly the same problem on an Ultra with 256MB ram and 500 +MB swap. Except I am compiling version 1.5 and its Red Hat 6.2. + +I can get around this by using -O instead of -O2 for the optimization +level. So it is probably a bug in the optimizer on the sparc complier. +I'll try and chase this down on the sparc lists.</pre> + +<h2><a name="error">Interpreting error messages</a></h2> + +<h3><a name="route-client">route-client (or host) exited with status +7</a></h3> + +<p>Here is a discussion of this error from FreeS/WAN "listress" (mailing list +tech support person) Claudia Schmeing. The "FAQ on the network unreachable +error" which she refers to is the next question below.</p> +<pre>> I reached the point where the two boxes (both on dial-up connections, but +> treated as static IPs by getting the IP and editing ipsec.conf after the +> connection is established) to the point where they exchange some info, but I +> get an error like "route-client command exited with status 7 \n internal +> error". +> Where can I find a description of this error? + +In general, if the FAQ doesn't cover it, you can search the mailing list +archives - I like to use +http://www.sandelman.ottawa.on.ca/linux-ipsec/ +but you can see doc/mail.html for different archive formats. + + +Your error comes from the _updown script, which performs some +routing and firewall functions to help Linux FreeS/WAN. More info +is available at doc/firewall.html and man ipsec.conf. Its routing +is integral to the health of Linux FreeS/WAN; it also provides facility +to insert custom firewall rules to be executed when you create or destroy +a connection. + +Yours is, of course, a routing error. You can be fairly sure the routing +machinery is saying "network is unreachable". There's a FAQ on the +"network is unreachable" error, but more information is available now; read on. + +If your _updown script is recent (for example if it shipped with +Linux FreeS/WAN 1.91), you will see another debugging line in your logs +that looks something like this: + +> output: /usr/local/lib/ipsec/_updown: `route add -net 128.174.253.83 +> netmask 255.255.255.255 dev ipsec0 gw 66.92.93.161' failed + +This is, of course, the system route command that exited with status 7, +(ie. failed). Man route for details. Seeing the command typed out yields +more information. If your _updown script is older, you may wish to update +it to show the command explicitly. + +Three parameters fed to the route command: net, netmask and gw [gateway] +are derived from things you've put in ipsec.conf. + +Net and netmask are derived from the peer's IP and mask. In more detail: + +You may see a routing error when routing to a client (ie. subnet), or +to a host (IPSec gateway or freestanding host; a box that does IPSec for +itself). In _updown, the "route-client" section is responsible to set up +the route for IPSec'd (usually, read 'tunneled') packets headed to a +peer subnet. Similarly, route-host routes IPSec'd packets to a peer host +or IPSec gateway. + +When routing to a 'client', net and netmask are ipsec.conf's left- or +rightsubnet (whichever is not local). Similarly, when routing to a +'host' the net is left or right. Host netmask is always /32, indicating a +single machine. + +Gw is nexthop's value. Again, the value in question is left- or rightnexthop, +whichever is local. Where left/right or left-/rightnexthop has the special +value %defaultroute (described in man ipsec.conf), gw will automagically get +the value of the next hop on the default route. + +Q: "What's a nexthop and why do I need one?" + +A: 'nexthop' is a routing kluge; its value is the next hop away + from the machine that's doing IPSec, and toward your IPSec peer. + You need it to get the processed packets out of the local system and + onto the wire. While we often route other packets through the machine + that's now doing IPSec, and are done with it, this does not suffice here. + After packets are processed with IPSec, this machine needs to know where + they go next. Of course using the 'IPSec gateway' as their routing gateway + would cause an infinite loop! [To visualize this, see the packet flow + diagram at doc/firewall.html.] To avoid this, we route packets through + the next hop down their projected path. + +Now that you know the background, consider: +1. Did you test routing between the gateways in the absence of Linux + FreeS/WAN, as recommended? You need to ensure the two machines that + will be running Linux FreeS/WAN can route to one another before trying to + make a secure connection. +2. Is there anything obviously wrong with the sense of your route command? + +Normally, this problem is caused by an incorrect local nexthop parameter. +Check out the use of %defaultroute, described in man ipsec.conf. This is +a simple way to set nexthop for most people. To figure nexthop out by hand, +traceroute in-the-clear to your IPSec peer. Nexthop is the traceroute's +first hop after your IPSec gateway.</pre> + +<h3><a name="unreachable">SIOCADDRT:Network is unreachable</a></h3> + +<p>This message is not from FreeS/WAN, but from the Linux IP stack itself. +That stack is seeing packets it has no route for, either because your routing +was broken before FreeS/WAN started or because FreeS/WAN's changes broke +it.</p> + +<p>Here is a message from Claudia suggesting ways to diagnose and fix such +problems:</p> +<pre>You write, +> I have correctly installed freeswan-1.8 on RH7.0 kernel 2.2.17, but when +> I setup a VPN connection with the other machine(RH5.2 Kernel 2.0.36 +> freeswan-1.0, it works well.) it told me that +> "SIOCADDRT:Network is unreachable"! But the network connection is no +> problem. + +Often this error is the result of a misconfiguration. + +Be sure that you can route successfully in the absence of Linux +FreeS/WAN. (You say this is no problem, so proceed to the next step.) + +Use a custom copy of the default updownscript. Do not change the route +commands, but add a diagnostic message revealing the exact text of the +route command. Is there a problem with the sense of the route command +that you can see? If so, then re-examine those ipsec.conf settings +that are being sent to the route command. + +You may wish to use the ipsec auto --route and --unroute commands to +troubleshoot the problem. See man ipsec_auto for details.</pre> + +<p>Since the above message was written, we have modified the updown script to +provide a better diagnostic for this problem. Check +<var>/var/log/messages</var>.</p> + +<p>See also the FAQ question <a href="#route-client">route-client (or host) +exited with status 7</a>.</p> + +<h3><a name="modprobe">ipsec_setup: modprobe: Can't locate module +ipsec</a></h3> + +<h3><a name="noKLIPS">ipsec_setup: Fatal error, kernel appears to lack +KLIPS</a></h3> + +<p>These messages indicate an installation failure. The kernel you are +running does not contain the <a href="glossary.html#KLIPS">KLIPS (kernel +IPsec)</a> code.</p> + +<p>Note that the "modprobe: Can't locate module ipsec" message appears even +if you are not using modules. If there is no KLIPS in your kernel, FreeS/WAN +tries to load it as a module. If that fails, you get this message.</p> + +<p>Commands you can quickly try are:</p> +<dl> + <dt><var>uname -a</var></dt> + <dd>to get details, including compilation date and time, of the currently + running kernel</dd> + <dt><var>ls /</var></dt> + <dt><var>ls /boot</var></dt> + <dd>to ensure a new kernel is where it should be. If kernel compilation + puts it in <var>/</var> but <var>lilo</var> wants it in + <var>/boot</var>, then you should uncomment the + <var>INSTALL_PATH=/boot</var> line in the kernel + <var>Makefile</var>.</dd> + <dt><var>more /etc/lilo.conf</var></dt> + <dd>to see that <var>lilo</var> has correct information</dd> + <dt><var>lilo</var></dt> + <dd>to ensure that information in <var>/etc/lilo.conf</var> has been + transferred to the boot sector</dd> +</dl> + +<p>If those don't find the problem, you have to go back and check through the +<a href="install.html">install</a> procedure to see what was missed.</p> + +<p>Here is one of Claudia's messages on the topic:</p> +<pre>> I tried to install freeswan 1.8 on my mandrake 7.2 test box. ... + +> It does show version and some output for whack. + +Yes, because the Pluto (daemon) part of ipsec is installed correctly, but +as we see below the kernel portion is not. + +> However, I get the following from /var/log/messages: +> +> Mar 11 22:11:55 pavillion ipsec_setup: Starting FreeS/WAN IPsec 1.8... +> Mar 11 22:12:02 pavillion ipsec_setup: modprobe: Can't locate module ipsec +> Mar 11 22:12:02 pavillion ipsec_setup: Fatal error, kernel appears to lack +> KLIPS. + +This is your problem. You have not successfully installed a kernel with +IPSec machinery in it. + +Did you build Linux FreeS/WAN as a module? If so, you need to ensure that +your new module has been installed in the directory where your kernel +loader normally finds your modules. If not, you need to ensure +that the new IPSec-enabled kernel is being loaded correctly. + +See also doc/install.html, and INSTALL in the distro.</pre> + +<h3><a name="noDNS">ipsec_setup: ... failure to fetch key for ... from +DNS</a></h3> + +<p>Quoting Henry:</p> +<pre>Note that by default, FreeS/WAN is now set up to + (a) authenticate with RSA keys, and + (b) fetch the public key of the far end from DNS. +Explicit attention to ipsec.conf will be needed if you want +to do something different.</pre> + +<p>and Claudia, responding to the same user:</p> +<pre>You write, + +> My current setup in ipsec.conf is leftrsasigkey=%dns I have +> commented this and authby=rsasig out. I am able to get ipsec running, +> but what I find is that the documentation only specifies for %dns are +> there any other values that can be placed in this variable other than +> %dns and the key? I am also assuming that this is where I would place +> my public key for the left and right side as well is this correct? + +Valid values for authby= are rsasig and secret, which entail authentication +by RSA signature or by shared secret, respectively. Because you have +commented authby=rsasig out, you are using the default value of authby=secret. + +When using RSA signatures, there are two ways to get the public key for the +IPSec peer: either copy it directly into *rsasigkey= in ipsec.conf, or +fetch it from dns. The magic value %dns for *rsasigkey parameters says to +try to fetch the peer's key from dns. + +For any parameters, you may find their significance and special values in +man ipsec.conf. If you are setting up keys or secrets, be sure also to +reference man ipsec.secrets.</pre> + +<h3><a name="dup_address">ipsec_setup: ... interfaces ... and ... share +address ...</a></h3> + +<p>This is a fatal error. FreeS/WAN cannot cope with two or more interfaces +using the same IP address. You must re-configure to avoid this.</p> + +<p>A mailing list message on the topic from Pluto developer Hugh +Redelmeier:</p> +<pre>| I'm trying to get freeswan working between two machine where one has a ppp +| interface. +| I've already suceeded with two machines with ethernet ports but the ppp +| interface is causing me problems. +| basically when I run ipsec start i get +| ipsec_setup: Starting FreeS/WAN IPsec 1.7... +| ipsec_setup: 003 IP interfaces ppp1 and ppp0 share address 192.168.0.10! +| ipsec_setup: 003 IP interfaces ppp1 and ppp2 share address 192.168.0.10! +| ipsec_setup: 003 IP interfaces ppp0 and ppp2 share address 192.168.0.10! +| ipsec_setup: 003 no public interfaces found +| +| followed by lots of cannot work out interface for connection messages +| +| now I can specify the interface in ipsec.conf to be ppp0 , but this does +| not affect the above behaviour. A quick look in server.c indicates that the +| interfaces value is not used but some sort of raw detect happens. +| +| I guess I could prevent the formation of the extra ppp interfaces or +| allocate them different ip but I'd rather not. if at all possible. Any +| suggestions please. + +Pluto won't touch an interface that shares an IP address with another. +This will eventually change, but it probably won't happen soon. + +For now, you will have to give the ppp1 and ppp2 different addresses.</pre> + +<h3><a name="kflags">ipsec_setup: Cannot adjust kernel flags</a></h3> + +<p>A mailing list message form technical lead Henry Spencer:</p> +<pre>> When FreeS/WAN IPsec 1.7 is starting on my 2.0.38 Linux kernel the following +> error message is generated: +> ipsec_setup: Cannot adjust kernel flags, no /proc/sys/net/ipsec directory! +> What is supposed to create this directory and how can I fix this problem? + +I think that directory is a 2.2ism, although I'm not certain (I don't have +a 2.0.xx system handy any more for testing). Without it, some of the +ipsec.conf config-setup flags won't work, but otherwise things should +function. </pre> + +<p>You also need to enable the <var>/proc</var> filesystem in your kernel +configuration for these operations to work.</p> + +<h3><a name="message_num">Message numbers (MI3, QR1, et cetera) in Pluto +messages</a></h3> + +<p>Pluto messages often indicate where Pluto is in the IKE protocols. The +letters indicate <strong>M</strong>ain mode or <strong>Q</strong>uick mode +and <strong>I</strong>nitiator or <strong>R</strong>esponder. The numerals +are message sequence numbers. For more detail, see our <a +href="ipsec.html#sequence">IPsec section</a>.</p> + +<h3><a name="conn_name">Connection names in Pluto error messages</a></h3> + +<p>From Pluto programmer Hugh Redelmeier:</p> +<pre>| Jan 17 16:21:10 remus Pluto[13631]: "jumble" #1: responding to Main Mode from Road Warrior 130.205.82.46 +| Jan 17 16:21:11 remus Pluto[13631]: "jumble" #1: no suitable connection for peer @banshee.wittsend.com +| +| The connection "jumble" has nothing to do with the incoming +| connection requests, which were meant for the connection "banshee". + +You are right. The message tells you which Connection Pluto is +currently using, which need not be the right one. It need not be the +right one now for the negotiation to eventually succeed! This is +described in ipsec_pluto(8) in the section "Road Warrior Support". + +There are two times when Pluto will consider switching Connections for +a state object. Both are in response to receiving ID payloads (one in +Phase 1 / Main Mode and one in Phase 2 / Quick Mode). The second is +not unique to Road Warriors. In fact, neither is the first any more +(two connections for the same pair of hosts could differ in Phase 1 ID +payload; probably nobody else has tried this).</pre> + +<h3><a name="cantorient">Pluto: ... can't orient connection</a></h3> + +<p>Older versions of FreeS/WAN used this message. The same error now gives +the "we have no ipsecN ..." error described just below.</p> + +<h3><a name="no.interface">... we have no ipsecN interface for either end of +this connection</a></h3> + +<p>Your tunnel has no IP address which matches the IP +address of any of the available IPsec interfaces. Either you've +misconfigured the connection, or you need to define an appropriate +IPsec interface connection. <VAR>interfaces=%defaultroute</VAR> works +in many cases.</p> + +<p>A longer story: Pluto needs to know whether it is running on +the machine which the +connection description calls <var>left</var> or on <var>right</var>. It +figures that out by:</p> +<ul> + <li>looking at the interfaces given in <var>interfaces=</var> lines in the + <var>config setup</var> section</li> + <li>discovering the IP addresses for those interfaces</li> + <li>searching for a match between those addresses and the ones given in + <var>left=</var> or <var>right=</var> lines.</li> +</ul> + +<p>Normally a match is found. Then Pluto knows where it is and can set up +other things (for example, if it is <var>left</var>) using parameters such as +<var>leftsubnet</var> and <var>leftnexthop</var>, and sending its outgoing +packets to <var>right</var>.</p> + +<p>If no match is found, it emits the above error message.</p> + +<h3><a name="noconn">Pluto: ... no connection is known</a></h3> + +<p>This error message occurs when a remote system attempts to negotiate a +connection and Pluto does not have a connection description that matches what +the remote system has requested. The most common cause is a configuration +error on one end or the other.</p> + +<p>Parameters involved in this match are <var>left</var>, <var>right</var>, +<var>leftsubnet</var> and <var>rightsubnet</var>.</p> + +<p><strong>The match must be exact</strong>. For example, if your left subnet +is a.b.c.0/24 then neither a single machine in that net nor a smaller subnet +such as a.b.c.64/26 will be considered a match.</p> + +<p>The message can also occur when an appropriate description exists but +Pluto has not loaded it. Use an <var>auto=add</var> statement in the +connection description, or an <var>ipsec auto --add <conn_name></var> +command, to correct this.</p> + +<p>An explanation from the Pluto developer:</p> +<pre>| Jul 12 15:00:22 sohar58 Pluto[574]: "corp_road" #2: cannot respond to IPsec +| SA request because no connection is known for +| 216.112.83.112/32===216.112.83.112...216.67.25.118 + +This is the first message from the Pluto log showing a problem. It +means that PGPnet is trying to negotiate a set of SAs with this +topology: + +216.112.83.112/32===216.112.83.112...216.67.25.118 +^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ +client on our side our host PGPnet host, no client + +None of the conns you showed look like this. + +Use + ipsec auto --status +to see a snapshot of what connections are in pluto, what +negotiations are going on, and what SAs are established. + +The leftsubnet= (client) in your conn is 216.112.83.64/26. It must +exactly match what pluto is looking for, and it does not.</pre> + +<h3><a name="nosuit">Pluto: ... no suitable connection ...</a></h3> + +<p>This is similar to the <a href="#noconn">no connection known</a> error, +but occurs at a different point in Pluto processing.</p> + +<p>Here is one of Claudia's messages explaining the problem:</p> +<pre>You write, + +> What could be the reason of the following error? +> "no suitable connection for peer '@xforce'" + +When a connection is initiated by the peer, Pluto must choose which entry in +the conf file best matches the incoming connection. A preliminary choice is +made on the basis of source and destination IPs, since that information is +available at that time. + +A payload containing an ID arrives later in the negotiation. Based on this +id and the *id= parameters, Pluto refines its conn selection. ... + +The message "no suitable connection" indicates that in this refining step, +Pluto does not find a connection that matches that ID. + +Please see "Selecting a connection when responding" in man ipsec_pluto for +more details.</pre> + +<p>See also <a href="#conn_name">Connection names in Pluto error +messages</a>.</p> + +<h3><a name="noconn.auth">Pluto: ... no connection has been +authorized</a></h3> + +<p>Here is one of Claudia's messages discussing this problem:</p> +<pre>You write, + +> May 22 10:46:31 debian Pluto[25834]: packet from x.y.z.p:10014: +> initial Main Mode message from x.y.z.p:10014 + but no connection has been authorized + +This error occurs early in the connection negotiation process, +at the first step of IKE negotiation (Main Mode), which is itself the +first of two negotiation phases involved in creating an IPSec connection. + +Here, Linux FreeS/WAN receives a packet from a potential peer, which +requests that they begin discussing a connection. + +The "no connection has been authorized" means that there is no connection +description in Linux FreeS/WAN's internal database that can be used to +link your ipsec interface with that peer. + +"But of course I configured that connection!" + +It may be that the appropriate connection description exists in ipsec.conf +but has not been added to the database with ipsec auto --add myconn or the +auto=add method. Or, the connection description may be misconfigured. + +The only parameters that are relevant in this decision are left= and right= . +Local and remote ports are also taken into account -- we see that the port +is printed in the message above -- but there is no way to control these +in ipsec.conf. + + +Failure at "no connection has been authorized" is similar to the +"no connection is known for..." error in the FAQ, and the "no suitable +connection" error described in the snapshot's FAQ. In all three cases, +Linux FreeS/WAN is trying to match parameters received in the +negotiation with the connection description in the local config file. + +As it receives more information, its matches take more parameters into +account, and become more precise: first the pair of potential peers, +then the peer IDs, then the endpoints (including any subnets). + +The "no suitable connection for peer *" occurs toward the end of IKE +(Main Mode) negotiation, when the IDs are matched. + +"no connection is known for a/b===c...d" is seen at the beginning of IPSec +(Quick Mode, phase 2) negotiation, when the connections are matched using +left, right, and any information about the subnets.</pre> + +<h3><a name="noDESsupport">Pluto: ... OAKLEY_DES_CBC is not +supported.</a></h3> + +<p>This message occurs when the other system attempts to negotiate a +connection using <a href="glossary.html#DES">single DES</a>, which we do not +support because it is <a href="politics.html#desnotsecure">insecure</a>.</p> + +<p>Our interoperation document has suggestions for <a +href="interop.html#noDES">how to deal with</a> systems that attempt to use +single DES.</p> + +<h3><a name="notransform">Pluto: ... no acceptable transform</a></h3> + +<p>This message means that the other gateway has made a proposal for +connection parameters, but nothing they proposed is acceptable to Pluto. +Possible causes include:</p> +<ul> + <li>misconfiguration on either end</li> + <li>policy incompatibilities, for example we require encrypted connections + but they are trying to create one with just authentication</li> + <li>interoperation problems, for example they offer only single DES and + FreeS/WAN does not support that. See <a + href="interop.html#interop.problem">discussion</a> in our interoperation + document.</li> +</ul> + +<p>A more detailed explanation, from Pluto programmer Hugh Redelmeier:</p> +<pre>Background: + +When one IKE system (for example, Pluto) is negotiating with another +to create an SA, the Initiator proposes a bunch of choices and the +Responder replies with one that it has selected. + +The structure of the choices is fairly complicated. An SA payload +contains a list of lists of "Proposals". The outer list is a set of +choices: the selection must be from one element of this list. + +Each of these elements is a list of Proposals. A selection must be +made from each of the elements of the inner list. In other words, +*all* of them apply (that is how, for example, both AH and ESP can +apply at once). + +Within each of these Proposals is a list of Transforms. For each +Proposal selected, one Transform must be selected (in other words, +each Proposal provides a choice of Transforms). + +Each Transform is made up of a list of Attributes describing, well, +attributes. Such as lifetime of the SA. Such as algorithm to be +used. All the Attributes apply to a Transform. + +You will have noticed a pattern here: layers alternate between being +disjunctions ("or") and conjunctions ("and"). + +For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is +cut back. There must be exactly one Proposal. So this degenerates to +a list of Transforms, one of which must be chosen. + +In your case, no proposal was considered acceptable to Pluto (the +Responder). So negotiation ceased. Pluto logs the reason it rejects +each Transform. So look back in the log to see what is going wrong.</pre> + +<h3><a name="rsasigkey">rsasigkey dumps core</a></h3> +A comment on this error from Henry: +<pre>On Fri, 29 Jun 2001, Rodrigo Gruppelli wrote: +> ...Well, it seem that there's +> another problem with it. When I try to generate a pair of RSA keys, +> rsasigkey cores dump... + +*That* is a neon sign flashing "GMP LIBRARY IS BROKEN". Rsasigkey calls +GMP a lot, and our own library a little bit, and that's very nearly all it +does. Barring bugs in its code or our library -- which have happened, but +not very often -- a problem in rsasigkey is a problem in GMP.</pre> + +<p>See the next question for how to deal with GMP errors.</p> + +<h3><a name="sig4">!Pluto failure!: ... exited with ... signal 4</a></h3> + +<p>Pluto has died. Signal 4 is SIGILL, illegal instruction.</p> + +<p>The most likely cause is that your <a href="glossary.html#GMP">GMP</a> +(GNU multi-precision) library is compiled for a different processor than what +you are running on. Pluto uses that library for its public key +calculations.</p> + +<p>Try getting the GMP sources and recompile for your processor type. Most +Linux distributions will include this source, or you can download it from the +<a href="http://www.swox.com/gmp/">GMP home page</a>.</p> + +<h3><a name="econnrefused">ECONNREFUSED error message</a></h3> + +<p>From John Denker, on the mailing list:</p> +<pre>1) The log message + some IKE message we sent has been rejected with + ECONNREFUSED (kernel supplied no details) +is much more suitable than the previous version. Thanks. + +2) Minor suggestion for further improvement: it might be worth mentioning +that the command + tcpdump -i eth1 icmp[0] != 8 and icmp[0] != 0 +is useful for tracking down the details in question. We shouldn't expect +all IPsec users to figure that out on their own. The log message might +even provide a hint as to where to look in the docs.</pre> + +<p>Reply From Pluto developer Hugh Redelmeier</p> +<pre>Good idea. + +I've added a bit pluto(8)'s BUGS section along these lines. +I didn't have the heart to lengthen this message.</pre> + +<h3><a name="no_eroute">klips_debug: ... no eroute!</a></h3> + +<p>This message means <a href="glossary.html#KLIPS">KLIPS</a> has received a +packet for which no IPsec tunnel has been defined.</p> + +<p>Here is a more detailed duscussion from the team's tech support person +Claudia Schmeing, responding to a query on the mailing list:</p> +<pre>> Why ipsec reports no eroute! ???? IP Masq... is disabled. + +In general, more information is required so that people on the list may +give you informed input. See doc/prob.report.</pre> + +<p>The document she refers to has since been replaced by a <a +href="trouble.html#prob.report">section</a> of the troubleshooting +document.</p> +<pre>However, I can make some general comments on this type of error. + +This error usually looks something like this (clipped from an archived +message): + +> ttl:64 proto:1 chk:45459 saddr:192.168.1.2 daddr:192.168.100.1 +> ... klips_debug:ipsec_findroute: 192.168.1.2->192.168.100.1 +> ... klips_debug:rj_match: * See if we match exactly as a host destination +> ... klips_debug:rj_match: ** try to match a leaf, t=0xc1a260b0 +> ... klips_debug:rj_match: *** start searching up the tree, t=0xc1a260b0 +> ... klips_debug:rj_match: **** t=0xc1a260c8 +> ... klips_debug:rj_match: **** t=0xc1fe5960 +> ... klips_debug:rj_match: ***** not found. +> ... klips_debug:ipsec_tunnel_start_xmit: Original head/tailroom: 2, 28 +> ... klips_debug:ipsec_tunnel_start_xmit: no eroute!: ts=47.3030, dropping. + + +What does this mean? +- -------------------- + +"eroute" stands for "extended route", and is a special type of route +internal to Linux FreeS/WAN. For more information about this type of route, +see the section of man ipsec_auto on ipsec auto --route. + +"no eroute!" here means, roughly, that Linux FreeS/WAN cannot find an +appropriate tunnel that should have delivered this packet. Linux +FreeS/WAN therefore drops the packet, with the message "no eroute! ... +dropping", on the assumption that this packet is not a legitimate +transmission through a properly constructed tunnel. + + +How does this situation come about? +- ----------------------------------- + +Linux FreeS/WAN has a number of connection descriptions defined in +ipsec.conf. These must be successfully brought "up" to form actual tunnels. +(see doc/setup.html's step 15, man ipsec.conf and man ipsec_auto +for details). + +Such connections are often specific to the endpoints' IPs. However, in +some cases they may be more general, for example in the case of +Road Warriors where left or right is the special value %any. + +When Linux FreeS/WAN receives a packet, it verifies that the packet has +come through a legitimate channel, by checking that there is an +appropriate tunnel through which this packet might legitimately have +arrived. This is the process we see above. + +First, it checks for an eroute that exactly matches the packet. In the +example above, we see it checking for a route that begins at 192.168.1.2 +and ends at 192.168.100.1. This search favours the most specific match that +would apply to the route between these IPs. So, if there is a connection +description exactly matching these IPs, the search will end there. If not, +the code will search for a more general description matching the IPs. +If there is no match, either specific or general, the packet will be +dropped, as we see, above. + +Unless you are working with Road Warriors, only the first, specific part +of the matching process is likely to be relevant to you. + + +"But I defined the tunnel, and it came up, why do I have this error?" +- --------------------------------------------------------------------- + +One of the most common causes of this error is failure to specify enough +connection descriptions to cover all needed tunnels between any two +gateways and their respective subnets. As you have noticed, troubleshooting +this error may be complicated by the use of IP Masq. However, this error is +not limited to cases where IP Masq is used. + +See doc/configuration.html#multitunnel for a detailed example of the +solution to this type of problem.</pre> + +<p>The documentation section she refers to is now <a +href="adv_config.html#multitunnel">here</a>.</p> + +<h3><a name="SAused">... trouble writing to /dev/ipsec ... SA already in +use</a></h3> + +<p>This error message occurs when two manual connections are set up with the +same SPI value. </p> + +<p>See the FAQ for <a href="#spi_error">One manual connection works, but +second one fails</a>.</p> + +<h3><a name="ignore">... ignoring ... payload</a></h3> + +<p>This message is harmless. The IKE protocol provides for a number of +optional messages types:</p> +<ul> + <li>delete SA</li> + <li>initial contact</li> + <li>vendor ID</li> + <li>...</li> +</ul> + +<p>An implementation is never required to send these, but they are allowed +to. The receiver is not required to do anything with them. FreeS/WAN ignores +them, but notifies you via the logs.</p> + +<p>For the "ignoring delete SA Payload" message, see also our discussion of +cleaning up <a href="#deadtunnel">dead tunnels</a>.</p> + +<h3><a name="unknown_rightcert">unknown parameter name "rightcert"</a></h3> + +<P>This message can appear when you've upgraded an X.509-enabled +Linux FreeS/WAN with a vanilla Linux FreeS/WAN. To use your X.509 configs +you will need to overwrite the new install with +<A HREF="http://www.freeswan.ca">Super FreeS/WAN</A>, or add the +<A HREF="http://www.strongsec.ca/freeswan">X.509 patch</A> by hand. +</P> + +<h2><a name="spam">Why don't you restrict the mailing lists to reduce +spam?</a></h2> + +<p>As a matter of policy, some of our <a href="mail.html">mailing lists</a> +need to be open to non-subscribers. Project management feel strongly that +maintaining this openness is more important than blocking spam.</p> +<ul> + <li>Users should be able to get help or report bugs without + subscribing.</li> + <li>Even a user who is subscribed may not have access to his or her + subscribed account when he or she needs help, miles from home base in the + middle of setting up a client's gateway.</li> + <li>There is arguably a legal requirement for this policy. A US resident or + citizen could be charged under munitions export laws for providing + technical assistance to a foreign cryptographic project. Such a charge + would be more easily defended if the discussion takes place in public, on + an open list.</li> +</ul> + +<p>This has been discussed several times at some length on the list. See the +<a href="mail.html#archive">list archives</a>. Bringing the topic up again is +unlikely to be useful. Please don't. Or at the very least, please don't +without reading the archives and being certain that whatever you are about to +suggest has not yet been discussed.</p> + +<p>Project technical lead Henry Spencer summarised one discussion:</p> + +<blockquote> + For the third and last time: this list *will* *not* do address-based + filtering. This is a policy decision, not an implementation problem. The + decision is final, and is not open to discussion. This needs to be + communicated better to people, and steps are being taken to do +that.</blockquote> + +<p>Adding this FAQ section is one of the steps he refers to.</p> + +<p>You have various options other than just putting up with the spam, +filtering it yourself, or unsubscribing:</p> +<ul> + <li>subscribe only to one or both of our lists with restricted posting + rules: + <ul> + <li><a + href="mailto:briefs@lists.freeswan.org?body=subscribe">briefs</a>, + weekly list summaries</li> + <li><a + href="mailto:announce@lists.freeswan.org?body=subscribe">announce</a>, + project-related announcements</li> + </ul> + </li> + <li>read the other lists via the <a + href="mail.html#archive">archives</a></li> +</ul> + +<p>A number of tools are available to filter mail.</p> +<ul> + <li>Many mail readers include some filtering capability.</li> + <li>Many Linux distributions include <a + href="http://www.procmail.org/">procmail(8)</a> for server-side + filtering.</li> + <li>The <a href="http://www.spambouncer.org/">Spam Bouncer</a> is a set of + procmail(8) filters designed to combat spam.</li> + <li>Roaring Penguin have a <a + href="http://www.roaringpenguin.com/mimedefang/">MIME defanger</a> that + removes potentially dangerous attachments.</li> +</ul> + +<p>If you use your ISP's mail server rather than running your own, consider +suggesting to the ISP that they tag suspected spam as <a +href="http://www.msen.com/1997/spam.html#SUSPECTED">this ISP</a> does. They +could just refuse mail from dubious sources, but that is tricky and runs some +risk of losing valuable mail or senselessly annoying senders and their +admins. However, they can safely tag and deliver dubious mail. The tags can +greatly assist your filtering.</p> + +<p>For information on tracking down spammers, see these <a +href="http://www.rahul.net/falk/#howtos">HowTos</a>, or the <a +href="http://www.sputum.com/index2.html">Sputum</a> site. Sputum have a Linux +anti-spam screensaver available for download.</p> + +<p>Here is a more detailed message from Henry:</p> +<pre>On Mon, 15 Jan 2001, Jay Vaughan wrote: +> I know I'm flogging a dead horse here, but I'm curious as to the reasons for +> an aversion for a subscriber-only mailing list? + +Once again: for legal reasons, it is important that discussions of these +things be held in a public place -- the list -- and we do not want to +force people to subscribe to the list just to ask one question, because +that may be more than merely inconvenient for them. There are also real +difficulties with people who are temporarily forced to use alternate +addresses; that is precisely the time when they may be most in need of +help, yet a subscribers-only policy shuts them out. + +These issues do not apply to most mailing lists, but for a list that is +(necessarily) the primary user support route for a crypto package, they +are very important. This is *not* an ordinary mailing list; it has to +function under awkward constraints that make various simplistic solutions +inapplicable or undesirable. + +> We're *ALL* sick of hearing about list management problems, not just you +> old-timers, so why don't you DO SOMETHING EFFECTIVE ABOUT IT... + +Because it's a lot harder than it looks, and many existing "solutions" +have problems when examined closely. + +> A suggestion for you, based on 10 years of experience with management of my +> own mailing lists would be to use mailman, which includes pretty much every +> feature under the sun that you guys need and want, plus some. The URL for +> mailman... + +I assure you, we're aware of mailman. Along with a whole bunch of others, +including some you almost certainly have never heard of (I hadn't!). + +> As for the argument that the list shouldn't be configured to enforce +> subscription - I contend that it *SHOULD* AT LEAST require manual address +> verification in order for posts to be redirected. + +You do realize, I hope, that interposing such a manual step might cause +your government to decide that this is not truly a public forum, and thus +you could go to jail if you don't get approval from them before mailing to +it? If you think this sounds irrational, your government is noted for +making irrational decisions in this area; we can't assume that they will +suddenly start being sensible. See above about awkward constraints. You +may be willing to take the risk, but we can't, in good conscience, insist +that all users with problems do so. + + Henry Spencer + henry@spsystems.net</pre> + +<p>and a message on the topic from project leader John Gilmore:</p> +<pre>Subject: Re: The linux-ipsec list's topic + Date: Sat, 30 Dec 2000 + From: John Gilmore <gnu@toad.com> + +I'll post this single message, once only, in this discussion, and then +not burden the list with any further off-topic messages. I encourage +everyone on the list to restrain themself from posting ANY off-topic +messages to the linux-ipsec list. + +The topic of the linux-ipsec mailing list is the FreeS/WAN software. + +I frequently see "discussions about spam on a list" overwhelm the +volume of "actual spam" on a list. BOTH kinds of messages are +off-topic messages. Twenty anti-spam messages take just as long to +detect and discard as twenty spam messages. + +The Linux-ipsec list encourages on-topic messages from people who have +not joined the list itself. We will not censor messages to the list +based on where they originate, or what return address they contain. +In other words, non-subscribers ARE allowed to post, and this will not +change. My own valid contributions have been rejected out-of-hand by +too many other mailing lists for me to want to impose that censorship +on anybody else's contributions. And every day I see the damage that +anti-spam zeal is causing in many other ways; that zeal is far more +damaging to the culture of the Internet than the nuisance of spam. + +In general, it is the responsibility of recipients to filter, +prioritize, or otherwise manage the handling of email that comes to +them. It is not the responsibility of the rest of the Internet +community to refrain from sending messages to recipients that they +might not want to see. If your software infrastructure for managing +your incoming email is insufficient, then improve it. If you think +the signal-to-noise ratio on linux-ipsec is too poor, then please +unsubscribe. But don't further increase the noise by posting to the +linux-ipsec list about those topics. + + John Gilmore + founder & sponsor, FreeS/WAN project</pre> +</body> +</html> |