diff options
Diffstat (limited to 'doc/src/faq.html')
| -rw-r--r-- | doc/src/faq.html | 2770 |
1 files changed, 0 insertions, 2770 deletions
diff --git a/doc/src/faq.html b/doc/src/faq.html deleted file mode 100644 index f62fc1c88..000000000 --- a/doc/src/faq.html +++ /dev/null @@ -1,2770 +0,0 @@ -<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> |