2340 lines
118 KiB
HTML
2340 lines
118 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Introduction to FreeS/WAN</TITLE>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
|
|
<STYLE TYPE="text/css"><!--
|
|
BODY { font-family: serif }
|
|
H1 { font-family: sans-serif }
|
|
H2 { font-family: sans-serif }
|
|
H3 { font-family: sans-serif }
|
|
H4 { font-family: sans-serif }
|
|
H5 { font-family: sans-serif }
|
|
H6 { font-family: sans-serif }
|
|
SUB { font-size: smaller }
|
|
SUP { font-size: smaller }
|
|
PRE { font-family: monospace }
|
|
--></STYLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="policygroups.html">Previous</A>
|
|
<A HREF="manpages.html">Next</A>
|
|
<HR>
|
|
<H1><A NAME="5">FreeS/WAN FAQ</A></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>
|
|
<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.</P>
|
|
<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>
|
|
:</P>
|
|
<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="glossary.html#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>
|
|
<P></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>.</P>
|
|
<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:</P>
|
|
<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>
|
|
<HR>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="policygroups.html">Previous</A>
|
|
<A HREF="manpages.html">Next</A>
|
|
</BODY>
|
|
</HTML>
|