1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
4 <TITLE> Introduction to FreeS/WAN</TITLE>
5 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
8 <A HREF="toc.html">Contents</a>
9 <A HREF="rfc.html">Previous</a>
10 <A HREF="performance.html">Next</a>
12 <H1><A NAME="18">FreeS/WAN FAQ</A></H1>
13 <P> This is a collection of questions and answers, mostly taken from
14 the FreeS/WAN <A href="mail.html">mailing list</A>. See the project <A href="http://www.freeswan.org/">
15 web site</A> for more information. All the FreeS/WAN documentation is
17 <P> Contributions to the FAQ are welcome. Please send them to the
18 project <A href="mail.html">mailing list</A>.</P>
20 <H2><A name="questions">Questions</A></H2>
22 <LI><A href="#whatzit"> What is FreeS/WAN?</A></LI>
23 <LI><A href="#problems"> How do I report a problem or seek help?</A></LI>
24 <LI><A href="#generic">Generic questions</A></LI>
26 <LI><A href="#lemme_out"> This is too complicated. Isn't there an
28 <LI><A href="#commercial"> Can I get commercial support for this
30 <LI><A href="#modify.faq"> Can I modify FreeS/WAN to ...?</A></LI>
31 <LI><A href="#contrib.faq"> Can I contribute to the project?</A></LI>
32 <LI><A href="#ddoc.faq">Is there detailed design documentation?</A></LI>
33 <LI><A href="#interop.faq"> Can FreeS/WAN talk to ...?</A></LI>
34 <LI><A href="#old_to_new"> Can different FreeS/WAN versions talk to
36 <LI><A href="#versions"> Does FreeS/WAN run on my version of Linux?</A></LI>
37 <LI><A href="#k.versions"> Does FreeS/WAN run on the latest kernel
39 <LI><A href="#faq.speed"> Is a ... fast enough to handle FreeS/WAN with
40 ... connections?</A></LI>
42 <LI><A href="#compile.faq">Compilation problems</A></LI>
44 <LI><A href="#gmp.h_missing">gmp.h: No such file or directory</A></LI>
45 <LI><A href="#noVM">... virtual memory exhausted</A></LI>
47 <LI><A href="#setup.faq"> Life's little mysteries</A></LI>
49 <LI><A href="#cantping"> I cannot ping ....</A></LI>
50 <LI><A href="#forever">It takes forever to ...</A></LI>
51 <LI><A href="#route"> I send packets to the tunnel with route(8) but
53 <LI><A href="#down_route"> When a tunnel goes down, packets vanish</A></LI>
54 <LI><A href="#firewall_ate">The firewall ate my packets!</A></LI>
55 <LI><A href="#dropconn">Dropped connections</A></LI>
56 <LI><A href="config.html#tcpdump"> TCPdump on the gateway shows strange
58 <LI><A href="#no_trace"> Traceroute does not show anything between the
61 <LI><A href="#man4debug">Testing in stages</A></LI>
63 <LI><A href="#nomanual">Manually keyed connections don't work</A></LI>
64 <LI><A href="#spi_error">One manual connection works, but second one
66 <LI><A href="#man_no_auto"> Manual connections work, but automatic
67 keying doesn't</A></LI>
68 <LI><A href="#nocomp"> IPSEC works, but connections using compression
70 <LI><A href="#pmtu.broken"> Small packets work, but large transfers fail</A>
72 <LI><A href="#subsub">Subnet-to-subnet works, but tests from the
73 gateways don't</A></LI>
75 <LI><A href="#error"> Interpreting error messages</A></LI>
77 <LI><A href="#unreachable">SIOCADDRT:Network is unreachable</A></LI>
78 <LI><A href="#noKLIPS">ipsec_setup: Fatal error, kernel appears to lack
80 <LI><A href="#noDNS">ipsec_setup: ... failure to fetch key for ... from
82 <LI><A href="#dup_address">ipsec_setup: ... interfaces ... and ...
83 share address ...</A></LI>
84 <LI><A href="#kflags"> ipsec_setup: Cannot adjust kernel flags</A></LI>
85 <LI><A href="#conn_name">Connection names in Pluto error messages</A></LI>
86 <LI><A href="#cantorient">Pluto: ... can't orient connection</A></LI>
87 <LI><A href="#noconn"> Pluto: ... no connection is known</A></LI>
88 <LI><A href="#nosuit"> Pluto: ... no suitable connection ...</A></LI>
89 <LI><A href="#noconn.auth"> Pluto: ... no connection has been authorized</A>
91 <LI><A href="#noDESsupport"> Pluto: ... OAKLEY_DES_CBC is not supported.</A>
93 <LI><A href="#notransform"> Pluto: ... no acceptable transform</A></LI>
94 <LI><A href="#econnrefused">ECONNREFUSED error message</A></LI>
95 <LI><A href="#no_eroute"> klips_debug: ... no eroute!</A></LI>
96 <LI><A href="#SAused"> ... trouble writing to /dev/ipsec ... SA already
98 <LI><A href="#ignore"> ... ignoring ... payload</A></LI>
100 <LI><A href="#canI">Can I ...</A></LI>
102 <LI><A href="#reload">Can I reload connection info without restarting?</A>
104 <LI><A href="#masq.faq">Can I use several masqueraded subnets?</A></LI>
105 <LI><A href="#dup_route">Can I use subnets masqueraded to the same
107 <LI><A href="#road.masq">Can I assign a road warrior an address on my
109 <LI><A href="#QoS">Can I use Quality of Service routing with FreeS/WAN?</A>
111 <LI><A href="#deadtunnel">Can I recognise dead tunnels and shut them
113 <LI><A href="#demanddial">Can I build IPSEC tunnels over a
114 demand-dialed link?</A></LI>
115 <LI><A href="#GRE">Can I build GRE tunnels over IPSEC?</A></LI>
116 <LI><A href="#PKIcert"> Does FreeS/WAN support X.509 or other PKI
117 certificates?</A></LI>
118 <LI><A href="#Radius"> Does FreeS/WAN support Radius or other user
119 authentication?</A></LI>
120 <LI><A href="#noDES.faq"> Does FreeS/WAN support single DES encryption?</A>
123 <LI><A href="#spam">Why don't you restrict the mailing lists to reduce
127 <H2><A name="whatzit"> What is FreeS/WAN?</A></H2>
128 FreeS/WAN is a Linux implementation of the <A href="glossary.html#IPSEC">
129 IPSEC</A> protocols, providing security services at the IP (Internet
130 Protocol) level of the network.
131 <P> For more detail, see our <A href="intro.html">introduction</A>
132 document or the FreeS/WAN project <A href="http://www.freeswan.org/">
134 <H2><A name="problems">How do I report a problem or seek help?</A></H2>
135 See our <A href="prob.report">problem reporting</A> document.
136 Basically, what it says is <STRONG>give us the output from <NOBR><VAR>
137 ipsec barf</VAR></NOBR> from both gateways</STRONG>. Without full
138 information, we cannot diagnose a problem. However, <NOBR><VAR>ipsec
139 barf</VAR></NOBR> produces a lot of output. If at all possible, <STRONG>
140 please make barfs accessible via the web or FTP</STRONG> rather than
141 sending enormous mail messages.
142 <P><STRONG> Use the <A href="mail.html">mailing list</A> for problem
143 reports</STRONG>, rather than mailing developers directly. This gives
144 you access to more expertise, including users who may have encountered
145 and solved the same problems. In particular, for problems involving <A href="interop.html">
146 interoperation</A> with another IPSEC implementation, the users often
147 know more than the developers. </P>
148 <P> Using the list may also be important in relation to various <A href="politics.html#exlaw">
149 cryptography export laws</A>. A US citizen who provides technical
150 assistance to foreign cryptographic work might be charged under the
151 arms export regulations. Such a charge would be easier to defend if the
152 discussion took place on a public mailing list than if it were done in
154 <H2><A name="generic">Generic questions</A></H2>
155 <H3><A name="lemme_out">This is too complicated. Isn't there an easier
157 There are a number of Linux distributions or firewall products which
158 include FreeS/WAN. See this <A href="intro.html#products">list</A>.
159 Using one of these, chosen to match your requirements and budget, may
160 save you considerable time and effort. (If you don't know your
161 requirements, start by reading Schneier's <A href="biblio.html#secrets">
162 Secrets and Lies</A>. That gives the best overview of security issues I
164 <P> If you want the help of a contractor, or to hire staff with
165 FreeS/WAN expertise, you could: </P>
167 <LI>check availability in your area through your local Linux User Group
168 (<A href="http://www.linux.com/lug/">LUG Index</A>) </LI>
169 <LI>try asking on our <A href="mail.html">mailing list</A></LI>
171 <P> For companies offerring support, see the next question. </P>
172 <H3><A name="commercial">Can I get commercial support for this product?</A>
174 Many of the distributions or firewall products which include FreeS/WAN
175 (see this <A href="intro.html#products">list</A>) come with commercial
176 support or have it available as an option.
177 <P> Various companies specialize in commercial support of open source
178 software. Our project leader was a founder of the first such company,
179 Cygnus Support. It has since been bought by <A href="http://www.redhat.com">
180 Redhat</A>. Another such firm is <A href="http://www.linuxcare.com">
182 <H3><A name="modify.faq">Can I modify FreeS/WAN to ...?</A></H3>
183 You are free to modify FreeS/WAN in any way. See the discussion of <A href="intro.html#licensing">
184 licensing</A> in our introduction document.
185 <H3><A name="contrib.faq">Can I contribute to the project?</A></H3>
186 In general, we welcome contributions from the community. Various
187 contributed patches, either to fix bugs or to add features, have been
188 incorporated into our distribution. Other patches, not yet included in
189 the distribution, are listed in our <A href="web.html#patch">web links</A>
191 <P> Users have also contributed heavily to documentation, both by
192 creating their own <A href="intro.html#howto">HowTos</A> and by posting
193 things on the <A href="mail.html">mailing lists</A> which I have quoted
194 in these HTML docs. </P>
195 <P> There are, however, some caveats. </P>
196 <P> FreeS/WAN is being implemented in Canada, by Canadians, largely to
197 ensure that is it is entirely free of export restrictions. See this <A href="politics.html#status">
198 discussion</A>. We <STRONG>cannot accept code contributions from US
199 residents or citizens</STRONG>, not even one-line bugs fixes. The
200 reasons for this were recently discussed extensively on the mailing
201 list, in a thread starting <A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00111.html">
203 <P> Not all contributions are of interest to us. The project has a set
204 of fairly ambitious and quite specific goals, described in our <A href="intro.html#goals">
205 introduction</A>. Contributions that lead toward these goals are likely
206 to be welcomed enthusiastically. Other contributions may be seen as
207 lower priority, or even as a distraction. </P>
208 <H3><A name="ddoc.faq">Is there detailed design documentation?</A></H3>
211 <LI><A href="RFC.html">RFCs</A> specifying the protocols we implement </LI>
212 <LI><A href="manpages.html">man pages</A> for our utilities, library
213 functions and file formats </LI>
214 <LI>comments in the source code </LI>
215 <LI><A href="index.html">HTML documentation</A> written primarily for
217 <LI>archived discussions from the <A href="mail.html">mailing lists</A></LI>
218 <LI>other papers mentioned in our <A href="intro.html#applied">
219 introduction</A></LI>
221 The only formal design documents are a few papers in the last category
222 above. All the other categories, however, have things to say about
224 <H3><A name="interop.faq">Can FreeS/WAN talk to ...?</A></H3>
225 The IPSEC protocols are designed to support interoperation. In theory,
226 any two IPSEC implementations should be able to talk to each other.
227 <P> In practice, it is considerably more complex. We have a whole <A href="interop.html">
228 interop document</A> devoted to it. </P>
229 <H3><A name="old_to_new">Can different FreeS/WAN versions talk to each
231 Linux FreeS/WAN can interoperate with many IPSEC implementations,
232 including earlier versions of Linux FreeS/WAN itself.
233 <P> In general, new versions will use existing configuration files, at
234 least until the next major version number change. For example, 1.8 can
235 use files created for 1.7, 1.6, even back to 1.0, but not from 0.92.
236 This behaviour will continue until we release 2.0. </P>
237 <P> As of 1.8, however, conf file checking has become stricter, so that
238 an error that may have slipped past the checks in an earlier version
239 may be caught in a later one. From 1.8's doc/CHANGES: </P>
241 The internal configuration-file reader is progressively getting
242 fussier about what it will accept, which may cause problems for
243 illegal ipsec.conf files whose sins previously passed unnoticed.
244 IN PARTICULAR, the "auto" parameter's values are now checked for
247 <H3><A name="versions">Does FreeS/WAN run on my version of Linux?</A></H3>
248 We build and test on Redhat distributions, but FreeS/WAN runs just
249 fine on several other distributions, sometimes with minor fiddles to
250 adapt to the local environment. Details are in our <A href="compat.html#otherdist">
251 compatibility</A> document. Also, some distributions or products come
252 with <A href="intro.html#products">FreeS/WAN included</A>.
253 <P> FreeS/WAN is <STRONG>intended to run on all CPUs Linux supports</STRONG>
254 . As of June 2000, we know of it being used in production on x86, ARM,
255 Alpha and MIPS. It has also had successful tests on PPC and SPARC,
256 though we don't know of actual use there. Details are in our <A href="compat.html#CPUs">
257 compatibility</A> document. </P>
258 <P> FreeS/WAN has been tested on multiprocessor Intel Linux and worked
259 there. Note, however, that we do not test this often and have never
260 tested on multiprocessor machines of other architectures. </P>
261 <H3><A name="k.versions">Does FreeS/WAN run on the latest kernel
263 Sometimes yes, but quite often, no.
264 <P> Released versions of FreeS/WAN run on whatever production kernels
265 were current at the time of our release (or shortly before; we might
266 release for kernel <VAR>n</VAR> just as Linus releases <VAR>n+1</VAR>).
267 For example, FreeS/WAN 1.91 runs on kernel 2.2.19 or 2.4.5. Often they
268 will run on slightly earlier or later kernels as well, but we test on
269 the current production kernels, so those are strongly recommended. </P>
270 <P> The kernel is under active development and it is not uncommon for
271 changes to appear that cause problems for FreeS/WAN. For example, 2.4.6
272 or 2.4.7 may have changes that break FreeS/WAN 1.91. Or not; you can't
273 tell in advance. When such changes appear, we put a fix in the
274 FreeS/WAN snapshots, and distribute it with our next release. </P>
275 <P> However, this is not a high priority for us, and it may take
276 anything from a few days to several weeks for such a problem to find
277 its way to the top of our kernel programmer's To-Do list. In the
278 meanwhile, you have two choices: </P>
280 <LI>either stick with a slightly older kernel, even if it is not the
281 latest and greatest. This is recommended for production systems; new
282 versions may have new bugs. </LI>
283 <LI>or fix the problem yourself and send us a patch, via the <A href="mail.html">
284 Users mailing list</A>. </LI>
286 We don't even try to keep up with kernel changes outside the main 2.2
287 and 2.4 branches, such as the 2.4.x-ac patched versions from Alan Cox
288 or (when they appear) the 2.5 series of development kernels. We'd
289 rather work on developing the FreeS/WAN code than on chasing these
290 moving targets. We are, however, happy to get patches for problems
292 <P> See also the <A href="install.html#choosek">Choosing a kernel</A>
293 section of our installation document. </P>
294 <H3><A name="faq.speed">Is a ... fast enough to handle FreeS/WAN with
295 ... connections?</A></H3>
296 Certainly FreeS/WAN can run happily on limited machines. Very roughly:
298 <LI>a 486 machines can handle a T1, ADSL or cable link (but the machine
299 may be breathing hard) </LI>
300 <LI>a current (mid-2001) technology PC can easily handle at least a 10
301 Mbit/second link </LI>
303 Beyond that, the picture is not clear. Much depends on details of your
304 network, your traffic, and other loads on both machine and net.
305 <P> See our <A href="performance.html">FreeS/WAN performance</A>
306 document and our discussion of <A href="config.html#biggate">many
307 tunnels for one gateway</A> for more detail. </P>
308 <H2><A name="compile.faq">Compilation problems</A></H2>
309 <H3><A name="gmp.h_missing">gmp.h: No such file or directory</A></H3>
310 Pluto needs the GMP (<STRONG>G</STRONG>NU <STRONG>M</STRONG>ulti-<STRONG>
311 P</STRONG>recision) library for the large integer calculations it uses
312 in <A href="glossary.html#public"> public key</A> cryptography. This
313 error message indicates a failure to find the library. You must install
314 it before Pluto will compile.
315 <P> The GMP library is included in most Linux distributions. Typically,
316 there are two RPMs, libgmp and libgmp-devel, You need to <EM>install
317 both</EM>, either from your distribution CDs or from your vendor's web
319 <P> On Debian, a mailing list message reports that the command to give
320 is <NOBR><VAR>apt-get install gmp2</VAR></NOBR>. </P>
321 <P> For more information and the latest version, see the <A href="http://www.swox.com/gmp/">
322 GMP home page</A>. </P>
323 <H3><A name="noVM">... virtual memory exhausted</A></H3>
324 We have had several reports of this message appearing, all on SPARC
325 Linux. Here is a mailing message on a solution:
327 > ipsec_sha1.c: In function `SHA1Transform':
328 > ipsec_sha1.c:95: virtual memory exhausted
330 I'm seeing exactly the same problem on an Ultra with 256MB ram and 500
331 MB swap. Except I am compiling version 1.5 and its Red Hat 6.2.
333 I can get around this by using -O instead of -O2 for the optimization
334 level. So it is probably a bug in the optimizer on the sparc complier.
335 I'll try and chase this down on the sparc lists.
337 <H2><A name="setup.faq">Life's little mysteries</A></H2>
338 FreeS/WAN is a fairly complex product. (Neither the networks it runs
339 on nor the protocols it uses are simple, so it could hardly be
340 otherwise.) It therefore sometimes exhibits behaviour which can be
341 somewhat confusing, or has problems which are not easy to diagnose.
342 This section tries to explain those problems.
343 <P> Setup and configuration of FreeS/WAN are covered in other
344 documentation sections: </P>
346 <LI><A href="install.html"> Installation</A></LI>
347 <LI><A href="config.html"> Configuration</A></LI>
348 <LI><A href="trouble.html"> Troubleshooting</A></LI>
350 <P> However, we also list some of the commonest problems here. </P>
351 <H3><A name="cantping">I cannot ping ....</A></H3>
352 This question is dealt with in the configuration section under the
353 heading <A href="config.html#multitunnel">multiple tunnels</A>.
354 <P> The standard subnet-to-subnet tunnel protects traffic <STRONG>only
355 between the subnets</STRONG>. To test it, you must use pings that go
356 from one subnet to the other. </P>
357 <P> For example, suppose you have: </P>
377 <P> and the connection description: </P>
382 leftsubnet=a.b.c.0/24
384 rightsubnet=x.y.z.0/24
386 <P> You can test this connection description only by sending a ping
387 that will actually go through the tunnel. Assuming you have machines at
388 addresses a.b.c.2 and x.y.z.2, pings you might consider trying are: </P>
390 <DT> ping from x.y.z.2 to a.b.c.2 or vice versa</DT>
391 <DD> Succeeds if tunnel is working. This is the <STRONG>only valid test
392 of the tunnel</STRONG>. </DD>
393 <DT> ping from gate2 to a.b.c.2 or vice versa</DT>
394 <DD><STRONG> Does not use tunnel</STRONG>. gate2 is not on protected
396 <DT> ping from gate1 to x.y.z.2 or vice versa</DT>
397 <DD><STRONG> Does not use tunnel</STRONG>. gate1 is not on protected
399 <DT> ping from gate1 to gate2 or vice versa</DT>
400 <DD><STRONG> Does not use tunnel</STRONG>. Neither gate is on a
401 protected subnet. </DD>
403 <P> Only the first of these is a useful test of this tunnel. The others
404 do not use the tunnel. Depending on other details of your setup and
407 <LI>either fail, telling you nothing about the tunnel </LI>
408 <LI>or succeed, telling you nothing about the tunnel since these
409 packets use some other route </LI>
411 <P> If required, you can of course build additional tunnels so that all
412 the machines involved can talk to all the others. See <A href="config.html#multitunnel">
413 multiple tunnels</A> in the configuration document for details. </P>
414 <H3><A name="forever">It takes forever to ...</A></H3>
415 Users fairly often report various problems involving long delays,
416 sometimes on tunnel setup and sometimes on operations done through the
417 tunnel, occasionally on simple things like ping or more often on more
418 complex operations like doing NFS or Samba through the tunnel.
419 <P> Almost always, these turn out to involve failure of a DNS lookup.
420 The timeouts waiting for DNS are typically set long so that you won't
421 time out when a query involves multiple lookups or long paths. Genuine
422 failures therefore produce long delays before they are detected. </P>
423 <P> A mailing list message from project technical lead Henry Spencer: </P>
425 > ... when i run /etc/rc.d/init.d/ipsec start, i get:
426 > ipsec_setup: Starting FreeS/WAN IPSEC 1.5...
427 > and it just sits there, doesn't give back my bash prompt.
429 Almost certainly, the problem is that you're using DNS names in your
430 ipsec.conf, but DNS lookups are not working for some reason. You will
431 get your prompt back... eventually. But the DNS timeouts are long.
432 Doing something about this is on our list, but it is not easy.
434 <P> In the meanwhile, we recommend that connection descriptions in <A href="manpage.d/ipsec.conf.5.html">
435 ipsec.conf(5)</A> use numeric IP addresses rather than names which will
436 require a DNS lookup. </P>
437 <P> Names that do not require a lookup are fine. For example: </P>
439 <LI>a road warrior might use the identity <VAR>
440 rightid=@lancelot.example.org</VAR></LI>
441 <LI>the gateway might use <VAR>leftid=@camelot.example.org</VAR></LI>
443 <P> These are fine. The @ sign prevents any DNS lookup. However, do not
444 attempt to give the gateway address as <VAR>left=camelot.example.org</VAR>
445 . That requires a lookup. </P>
446 <P> A post from one user after solving a problem with long delays: </P>
448 Subject: Final Answer to Delay!!!
449 Date: Mon, 19 Feb 2001
450 From: "Felippe Solutions" <felippe@solutionstecnologia.com.br>
452 Sorry people, but seems like the Delay problem had nothing to do with
455 The problem was DNS as some people sad from the beginning, but not the way
456 they thought it was happening. Samba, ssh, telnet and other apps try to
457 reverse lookup addresses when you use IP numbers (Stupid that ahh).
459 I could ping very fast because I always ping with "-n" option, but I don't
460 know the option on the other apps to stop reverse addressing so I don't use
463 This post is fairly typical. These problems are often tricky and
464 frustrating to diagnose, and most turn out to be DNS-related.
465 <P> One suggestion for diagnosis: test with both names and addresses if
466 possible. For example, try all of: </P>
468 <LI>ping <VAR>address</VAR></LI>
469 <LI>ping -n <VAR>address</VAR></LI>
470 <LI>ping <VAR>name</VAR></LI>
472 <P> If these behave differently, the problem must be DNS-related since
473 the three commands do exactly the same thing except for DNS lookups. </P>
474 <H3><A name="route">I send packets to the tunnel with route(8) but they
476 IPSEC connections are designed to carry only packets travelling
477 between pre-defined connection endpoints. As project technical lead
478 Henry Spencer put it: <BLOCKQUOTE> IPsec tunnels are not just virtual
479 wires; they are virtual wires with built-in access controls.
480 Negotiation of an IPsec tunnel includes negotiation of access rights
481 for it, which don't include packets to/from other IP addresses. (The
482 protocols themselves are quite inflexible about this, so there are
483 limits to what we can do about it.) </BLOCKQUOTE> For fairly obvious
484 security reasons, and to comply with the IPSEC RFCs, <A href="glossary.html#KLIPS">
485 KLIPS</A> drops any packets it receives that are not allowed on the
486 tunnels currently defined. So if you send it packets with <VAR>route(8)</VAR>
487 , and suitable tunnels are not defined, the packets vanish. Whether
488 this is reported in the logs depends on the setting of <VAR>klipsdebug</VAR>
489 in your <A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A> file.
490 <P> To rescue vanishing packets, you must ensure that suitable tunnels
491 for them exist, by editing the connection descriptions in <A href="manpage.d/ipsec.conf.5.html">
492 ipsec.conf(5)</A>. For example, supposing you have a simple setup: </P>
494 leftsubnet -- leftgateway === internet === roadwarrior
496 If you want to give the roadwarrior access to some resource that is
497 located behind the left gateway but is not in the currently defined
498 left subnet, then the usual procedure is to define an additional tunnel
499 for those packets by creating a new connection description.
500 <P> In some cases, it may be easier to alter an existing connection
501 description, enlarging the definition of <VAR>leftsubnet</VAR>. For
502 example, instead of two connection descriptions with 192.168.8.0/24 and
503 192.168.9.0/24 as their <VAR>leftsubnet</VAR> parameters, you can use a
504 single description with 192.168.8.0/23. </P>
505 <P> If you have multiple endpoints on each side, you need to ensure
506 that there is a route for each pair of endpoints. See our <A href="config.html#multitunnel">
507 configuration</A> document for an example. </P>
508 <H3><A name="down_route">When a tunnel goes down, packets vanish</A></H3>
509 This is a special case of the vanishing packet problem described in
510 the previous question. Whenever KLIPS sees packets for which it does
511 not have a tunnel, it drops them.
512 <P> When a tunnel goes away, either because negotiations with the other
513 gateway failed or because you gave an <NOBR><VAR>ipsec auto --down</VAR></NOBR>
514 command, the route to its other end is left pointing into KLIPS, and
515 KLIPS will drop packets it has no tunnel for. </P>
516 <P> This is a documented design decision, not a bug. FreeS/WAN must not
517 automatically adjust things to send packets via another route. The
518 other route might be insecure. </P>
519 <P> Of course, re-routing may be necessary in many cases. In those
520 cases, you have to do it manually or via scripts. We provide the <NOBR><VAR>
521 ipsec auto --unroute</VAR></NOBR> command for these cases. </P>
522 <P> From <A href="manpage.d/ipsec_auto.8.html">ipsec_auto(8)</A>: <BLOCKQUOTE>
523 Normally, pluto establishes a route to the destination specified
524 for a connection as part of the --up operation. However, the route
525 and only the route can be established with the --route operation.
526 Until and unless an actual connection is established, this
527 discards any packets sent there, which may be preferable to having
528 them sent elsewhere based on a more general route (e.g., a
529 default route). </BLOCKQUOTE><BLOCKQUOTE> Normally, pluto's route to a
530 destination remains in place when a --down operation is used to
531 take the connection down (or if connection setup, or later automatic
532 rekeying, fails). This permits establishing a new connection (perhaps
533 using a different specification; the route is altered as necessary)
534 without having a ``window'' in which packets might go elsewhere based
535 on a more general route. Such a route can be removed using the
536 --unroute operation (and is implicitly removed by --delete). </BLOCKQUOTE>
538 <P> See also this mailing list <A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00523.html">
540 <H3><A name="firewall_ate">The firewall ate my packets!</A></H3>
541 If firewalls filter out:
543 <LI>either the UDP port 500 packets used in IKE negotiations</LI>
544 <LI>or the ESP and AH (protocols 50 and 51) packets used to implement
545 the IPSEC tunnel</LI>
547 <P> then IPSEC cannot work. The first thing to check if packets seem to
548 be vanishing is the firewall rules on the two gateway machines and any
549 other machines along the path that you have access to. </P>
550 <P> For details, see our document on <A href="firewall.html">firewalls</A>
552 <H3><A name="dropconn">Dropped connections</A></H3>
553 <P> Networks being what they are, IPSEC connections can be broken for
554 any number of reasons, ranging from hardware failures to various
555 software problems such as the path MTU problems discussed <A href="#pmtu.broken">
556 elsewhere in the FAQ</A>. Fortunately, various diagnostic tools exist
557 that help you sort out many of the possible problems.</P>
558 <P> There is one situation, however, where FreeS/WAN (using default
559 settings) may destroy a connection for no readily apparent reason. This
560 occurs when things are <STRONG>misconfigured</STRONG> so that <STRONG>
561 two tunnels</STRONG> from the same gateway expect <STRONG>the same
562 subnet on the far end</STRONG>.</P>
563 <P> In this situation, the first tunnel comes up fine and works until
564 the second is established. At that point, because of the way we track
565 connections internally, the first tunnel ceases to exist as far as this
566 gateway is concerned. Of course the far end does not know that, and a
567 storm of error messages appears on both systems as it tries to use the
569 <P> If the far end gives up, goes back to square one and negotiates a
570 new tunnel, then that wipes out the second tunnel and ...</P>
571 <P> The solution is simple. <STRONG>Do not build multiple conn
572 descriptions with the same remote subnet</STRONG>.</P>
573 <P> This is actually intended to be a feature, rather than a bug.
574 Consider the situation where a single remote system goes down, then
575 comes back up and reconnects to the gateway. It is useful to have the
576 gateway tear down the old tunnel and recover resources when the
577 reconnection is made. It recognises that situation by checking the
578 remote subnet for each tunnel it builds and discarding duplicates. This
579 works fine as long as you don't configure multiple tunnels with the
580 same remote subnet.</P>
581 <P> If this behaviour is inconvenient for you, you can disable it by
582 setting <VAR>uniqueids=no</VAR> in <A href="manpage.d/ipsec.conf.5.html">
583 ipsec.conf(5)</A>. </P>
584 <H3><A name="tcpdump.faq">TCPdump on the gateway shows strange things</A>
586 Attempting to look at IPSEC packets by running monitoring tools on the
587 IPSEC gateway machine can produce silly results. That machine is
588 mangling the packets for IPSEC, and possibly for firewall or NAT
589 purposes as well. If the internals of the machine's IP stack are not
590 what the monitoring tool expects, then the tool can misinterpret them
591 and produce nonsense output.
592 <P> At one point, this problem was quite severe. On more recent
593 systems, <STRONG>the problem has been solved</STRONG>. The version of
594 tcpdump shipped with Redhat 6.2, for example, understands IPSEC well
595 enough to be usable on a gateway. If in doubt about your version of
596 tcpdump, you can get the latest version from <A href="http://www.tcpdump.org/">
597 tcpdump.org</A>. </P>
598 <P> Even if you have a version of tcpdump that works on gateways
599 however, the most certain way to examine IPSEC packets is to look at
600 them on the wire. For security, you need to be certain, so we recommend
601 doing that. To do so, you need a <STRONG>separate sniffer machine
602 located between the two gateways</STRONG>. This machine can be routing
603 IPSEC packets, but it must not be an IPSEC gateway. </P>
604 <P> A common test setup is to put a machine with dual Ethernet cards in
605 between two gateways under test. The central machine both routes
606 packets and provides a place to safely run tcpdump or other sniffing
607 tools. What you end up with looks like: </P>
608 <H4>Testing network</H4>
630 <P> With p and q any convenient values that do not interfere with other
631 routes you may have. The ipsec.conf(5) file then has, among other
637 leftnexthop=192.168.p.2
639 rightnexthop=192.168.q.2
641 Once that works, you can remove the "route/monitor box", and connect
642 the two gateways to the Internet. The only parameters in ipsec.conf(5)
643 that need to change are the four shown above. You replace them with
644 values appropriate for your Internet connection, and change the eth0 IP
645 addresses and the default routes on both gateways.
646 <P> Note that nothing on either subnet needs to change. This lets you
647 test most of your IPSEC setup before connecting to the insecure
649 <H3><A name="no_trace">Traceroute does not show anything between the
651 As far as traceroute can see, the two gateways are one hop apart; the
652 data packet goes directly from one to the other through the tunnel. Of
653 course the outer packets that implement the tunnel pass through
654 whatever lies between the gateways, but those packets are built and
655 dismantled by the gateways. Traceroute does not see them and cannot
656 report anything about their path.
657 <P> Here is a mailing list message with more detail. </P>
659 Date: Mon, 14 May 2001
660 To: linux-ipsec@freeswan.org
661 From: "John S. Denker" <jsd@research.att.com<
662 Subject: Re: traceroute: one virtual hop
664 At 02:20 PM 5/14/01 -0400, Claudia Schmeing wrote:
666 >> > A bonus question: traceroute in subnet to subnet enviroment looks like:
668 >> > traceroute to andris.dmz (172.20.24.10), 30 hops max, 38 byte packets
669 >> > 1 drama (172.20.1.1) 0.716 ms 0.942 ms 0.434 ms
670 >> > 2 * * *
671 >> > 3 andris.dmz (172.20.24.10) 73.576 ms 78.858 ms 79.434 ms
673 >> > Why aren't there the other hosts which take part in the delivery during
676 >If there is an ipsec tunnel between GateA and Gate B, this tunnel forms a
677 >'virtual wire'. When it is tunneled, the original packet becomes an inner
678 >packet, and new ESP and/or AH headers are added to create an outer packet
679 >around it. You can see an example of how this is done for AH at
680 >doc/ipsec.html#AH . For ESP it is similar.
682 >Think about the packet's path from the inner packet's perspective.
683 >It leaves the subnet, goes into the tunnel, and re-emerges in the second
684 >subnet. This perspective is also the only one available to the
685 >'traceroute' command when the IPSec tunnel is up.
687 Claudia got this exactly right. Let me just expand on a couple of points:
689 *) GateB is exactly one (virtual) hop away from GateA. This is how it
690 would be if there were a physically private wire from A to B. The
691 virtually private connection should work the same, and it does.
693 *) While the information is in transit from GateA to GateB, the hop count
694 of the outer header (the "envelope") is being decremented. The hop count
695 of the inner header (the "contents" of the envelope) is not decremented and
696 should not be decremented. The hop count of the outer header is not
697 derived from and should not be derived from the hop count of the inner header.
699 Indeed, even if the packets did time out in transit along the tunnel, there
700 would be no way for traceroute to find out what happened. Just as
701 information cannot leak _out_ of the tunnel to the outside, information
702 cannot leak _into_ the tunnel from outside, and this includes ICMP messages
703 from routers along the path.
705 There are some cases where one might wish for information about what is
706 happening at the IP layer (below the tunnel layer) -- but the protocol
707 makes no provision for this. This raises all sorts of conceptual issues.
708 AFAIK nobody has ever cared enough to really figure out what _should_
709 happen, let alone implement it and standardize it.
711 *) I consider the "* * *" to be a slight bug. One might wish for it to be
712 replaced by "GateB GateB GateB". It has to do with treating host-to-subnet
713 traffic different from subnet-to-subnet traffic (and other gory details).
714 I fervently hope KLIPS2 will make this problem go away.
716 *) If you want to ask questions about the link from GateA to GateB at the
717 IP level (below the tunnel level), you have to ssh to GateA and launch a
718 traceroute from there.
720 <H2><A name="man4debug">Testing in stages</A></H2>
721 <P> It is often useful in debugging to test things one at a time:</P>
723 <LI>disable IPSEC entirely, e.g. by turning it off with chkconfig(8),
724 and make sure routing works</LI>
725 <LI>Once that works, try a manually keyed connection. This does not
726 require key negotiation between Pluto and the key daemon on the other
728 <LI>Once that works, try automatically keyed connections</LI>
729 <LI>Once IPSEC works, add packet compression</LI>
730 <LI>Once everything seems to work, try stress tests with large
731 transfers, many connections, frequent re-keying, ... </LI>
733 <P> FreeS/WAN releases are tested for all of these, so you can be
734 reasonably certain they <EM>can</EM> do them all. Of course, that does
735 not mean they <EM>will</EM> on the first try, especially if you have
736 some unusual configuration. </P>
737 <P> The rest of this section gives information on diagnosing the
738 problem when each of the above steps fails. </P>
739 <H3><A name="nomanual">Manually keyed connections don't work</A></H3>
740 <P>Suspect one of:</P>
742 <LI>mis-configuration of IPSEC system in the /etc/ipsec.conf file
743 <BR> e.g. incorrect interface or next hop information</LI>
744 <LI>mis-configuration of manual connection in the /etc/ipsec.conf file</LI>
745 <LI>routing problems causing IPSEC packets to be lost</LI>
746 <LI>bugs in KLIPS</LI>
747 <LI>mismatch between the transforms we support and those another IPSEC
748 implementation offers.</LI>
750 <H3><A name="spi_error">One manual connection works, but second one
752 This is fairly common problem when attempting to configure multiple
753 manually keyed connections from a single gateway.
754 <P> Each connection must be identified by a unique <A href="glossary.html#SPI">
755 SPI</A> value. For automatic connections, these values are assigned
756 automatically. For manual connections, you must set them with <VAR>spi=</VAR>
757 statements in <A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A>. </P>
758 <P> Each manual connection must have a unique SPI value in the range
759 0x100 to 0x999. Two or more with the same value will fail. For details,
760 see our HTML doc section <A href="config.html#prodman">Using manual
761 keying in production</A> and the man page <A href="manpage.d/ipsec.conf.5.html">
762 ipsec.conf(5)</A>. </P>
763 <H3><A name="man_no_auto">Manual connections work, but automatic keying
765 The most common reason for this behaviour is a firewall dropping the
766 UDP port 500 packets used in key negotiation.
767 <P> Other possibilities:</P>
769 <LI>mis-configuration of auto connection in the /etc/ipsec.conf file. </LI>
770 <P>One common configuration error is forgetting that you need <VAR>
771 auto=add</VAR> to load the connection description on the receiving end
772 so it recognises the connection when the other end asks for it.</P>
773 <LI>error in shared secret in /etc/ipsec.secrets</LI>
774 <LI>one gateway lacks a route to the other so Pluto's UDP packets are
776 <LI>bugs in Pluto</LI>
777 <LI>incompatibilities between Pluto's <A href="glossary.html#IKE">IKE</A>
778 implementation and the IKE at the other end of the tunnel. </LI>
779 <P>Some possibile problems are discussed in out <A href="interop.html#interop.problem">
780 interoperation</A> document.</P>
782 <H3><A name="nocomp">IPSEC works, but connections using compression fail</A>
786 <LI>(especially if small packets are OK, but large ones fail)
787 compatibility issues with other implementations. We follow the RFCs
788 and omit some extra material that many compression libraries add by
789 default. Others may have the extras left in.</LI>
790 <LI>bugs in the FreeS/WAN IPComp code, which is new for 1.6 and not yet
793 <H3><A name="pmtu.broken">Small packets work, but large transfers fail</A>
795 <P> If tests with ping(1) and a small packet size succeed, but tests or
796 transfers with larger packet sizes fail, suspect problems with <A href="glossary.html#pathMTU">
797 path MTU discovery</A>.</P>
798 <P> IPSEC makes packets larger by adding an ESP or AH header. This can
799 tickle assorted bugs in path MTU discovery mechanisms and cause a
800 variety of annoying symptoms. Here is one example of a discussion of
801 this problem off the mailing list:</P>
803 Date: Mon, 3 Apr 2000
804 From: "Michael H. Warfield" <mhw@wittsend.com>
808 > Chris> It appears that the Osicom router discards IP
809 > Chris> fragments...
811 > Amazing. A device that discards fragments isn't a router, it's at
812 > best a boat anchor.
814 It may not be exactly what it appears. I ran into a similar problem
815 with an ISDN link a while ago giving similar symptoms. Turned out that
816 the device was negotiating an MTU that it really couldn't handle and the
817 device in front of it (a Linux box with always defragment enabled) was
818 defragmenting the huge IPSec datagrams and then refragmenting them into
819 hunks that the ISDN PPP thought it could handle but couldn't. Problem was
820 solved by manually capping the MTU on the ISDN link to a smaller value.
822 I gave the FreeSwan guys a hard time until tracking it down since
823 FreeSwan was the only thing that appeared to be able to tickle the bug.
824 Nothing else seemed to be broken. What it really was that MTU discovery
825 was avoiding the problem on normal links and it was only the IPSEC tunnels
826 that were creating huge datagrams that went through the defragment/refragment
829 Point here is that it "appeared" as though the ISDN link was
830 failing to handle fragments when it was really a configuration error and
831 a software bug resulting in a bad MTU that was really the culprit. So
832 it may not be that the router is not handling fragments. It may be that
833 it's missconfigured or has some other bug that only FreeSwan is tripping
836 <H3><A name="subsub">Subnet-to-subnet works, but tests from the
837 gateways don't</A></H3>
838 This is described under <A href="#cantping">I cannot ping...</A>
840 <H2><A name="error">Interpreting error messages</A></H2>
841 <H3><A name="unreachable">SIOCADDRT:Network is unreachable</A></H3>
842 This message is not from FreeS/WAN, but from the Linux IP stack
843 itself. That stack is seeing packets it has no route for, either
844 because your routing was broken before FreeS/WAN started or because
845 FreeS/WAN's changes broke it.
846 <P> Here is a message from FreeS/WAN "listress" (mailing list tech
847 support person) Claudia Schmeing suggesting ways to diagnose and fix
851 > I have correctly installed freeswan-1.8 on RH7.0 kernel 2.2.17, but when
852 > I setup a VPN connection with the other machine(RH5.2 Kernel 2.0.36
853 > freeswan-1.0, it works well.) it told me that
854 > "SIOCADDRT:Network is unreachable"! But the network connection is no
857 Often this error is the result of a misconfiguration.
859 Be sure that you can route successfully in the absence of Linux
860 FreeS/WAN. (You say this is no problem, so proceed to the next step.)
862 Use a custom copy of the default updownscript. Do not change the route
863 commands, but add a diagnostic message revealing the exact text of the
864 route command. Is there a problem with the sense of the route command
865 that you can see? If so, then re-examine those ipsec.conf settings
866 that are being sent to the route command.
868 You may wish to use the ipsec auto --route and --unroute commands to
869 troubleshoot the problem. See man ipsec_auto for details.
871 Since the above message was written, we have modified the updown
872 script to provide a better diagnostic for this problem. Check <VAR>
873 /var/log/messages</VAR>.
874 <H3><A name="noKLIPS">ipsec_setup: Fatal error, kernel appears to lack
876 This message indicates an installation failure. The kernel you are
877 running does not contain the KLIPS (kernel IPSEC) code.
878 <P> Commands you can quickly try are: </P>
880 <DT><VAR>uname -a</VAR></DT>
881 <DD>to get details, including compilation date and time, of the
882 currently running kernel </DD>
883 <DT><VAR>ls /</VAR></DT>
884 <DT><VAR>ls /boot</VAR></DT>
885 <DD>to ensure a new kernel is where it should be. If kernel compilation
886 puts it in <VAR>/</VAR> but <VAR>lilo</VAR> wants it in <VAR>/boot</VAR>
887 , then you should uncomment the <VAR>INSTALL_PATH=/boot</VAR> line in
888 the kernel <VAR>Makefile</VAR>. </DD>
889 <DT><VAR>more /etc/lilo.conf</VAR></DT>
890 <DD>to see that <VAR>lilo</VAR> has correct information </DD>
891 <DT><VAR>lilo</VAR></DT>
892 <DD>to ensure that information in <VAR>/etc/lilo.conf</VAR> has been
893 transferred to the boot sector </DD>
895 If those don't find the problem, you have to go back and check through
896 the <A href="install.html">install</A> procedure to see what was
898 <P> Here is one of Claudia's messages on the topic: </P>
900 > I tried to install freeswan 1.8 on my mandrake 7.2 test box. ...
902 > It does show version and some output for whack.
904 Yes, because the Pluto (daemon) part of ipsec is installed correctly, but
905 as we see below the kernel portion is not.
907 > However, I get the following from /var/log/messages:
909 > Mar 11 22:11:55 pavillion ipsec_setup: Starting FreeS/WAN IPSEC 1.8...
910 > Mar 11 22:12:02 pavillion ipsec_setup: modprobe: Can't locate module ipsec
911 > Mar 11 22:12:02 pavillion ipsec_setup: Fatal error, kernel appears to lack
914 This is your problem. You have not successfully installed a kernel with
915 IPSec machinery in it.
917 Did you build Linux FreeS/WAN as a module? If so, you need to ensure that
918 your new module has been installed in the directory where your kernel
919 loader normally finds your modules. If not, you need to ensure
920 that the new IPSec-enabled kernel is being loaded correctly.
922 See also doc/install.html, and INSTALL in the distro.
924 <H3><A name="noDNS">ipsec_setup: ... failure to fetch key for ... from
928 Note that by default, FreeS/WAN is now set up to
929 (a) authenticate with RSA keys, and
930 (b) fetch the public key of the far end from DNS.
931 Explicit attention to ipsec.conf will be needed if you want
932 to do something different.
934 and Claudia, responding to the same user:
938 > My current setup in ipsec.conf is leftrsasigkey=%dns I have
939 > commented this and authby=rsasig out. I am able to get ipsec running,
940 > but what I find is that the documentation only specifies for %dns are
941 > there any other values that can be placed in this variable other than
942 > %dns and the key? I am also assuming that this is where I would place
943 > my public key for the left and right side as well is this correct?
945 Valid values for authby= are rsasig and secret, which entail authentication
946 by RSA signature or by shared secret, respectively. Because you have
947 commented authby=rsasig out, you are using the default value of authby=secret.
949 When using RSA signatures, there are two ways to get the public key for the
950 IPSec peer: either copy it directly into *rsasigkey= in ipsec.conf, or
951 fetch it from dns. The magic value %dns for *rsasigkey parameters says to
952 try to fetch the peer's key from dns.
954 For any parameters, you may find their significance and special values in
955 man ipsec.conf. If you are setting up keys or secrets, be sure also to
956 reference man ipsec.secrets.
958 <H3><A name="dup_address">ipsec_setup: ... interfaces ... and ... share
960 This is a fatal error. FreeS/WAN cannot cope with two or more
961 interfaces using the same IP address. You must re-configure to avoid
963 <P> A mailing list message on the topic from Pluto developer Hugh
966 | I'm trying to get freeswan working between two machine where one has a ppp
968 | I've already suceeded with two machines with ethernet ports but the ppp
969 | interface is causing me problems.
970 | basically when I run ipsec start i get
971 | ipsec_setup: Starting FreeS/WAN IPSEC 1.7...
972 | ipsec_setup: 003 IP interfaces ppp1 and ppp0 share address 192.168.0.10!
973 | ipsec_setup: 003 IP interfaces ppp1 and ppp2 share address 192.168.0.10!
974 | ipsec_setup: 003 IP interfaces ppp0 and ppp2 share address 192.168.0.10!
975 | ipsec_setup: 003 no public interfaces found
977 | followed by lots of cannot work out interface for connection messages
979 | now I can specify the interface in ipsec.conf to be ppp0 , but this does
980 | not affect the above behaviour. A quick look in server.c indicates that the
981 | interfaces value is not used but some sort of raw detect happens.
983 | I guess I could prevent the formation of the extra ppp interfaces or
984 | allocate them different ip but I'd rather not. if at all possible. Any
985 | suggestions please.
987 Pluto won't touch an interface that shares an IP address with another.
988 This will eventually change, but it probably won't happen soon.
990 For now, you will have to give the ppp1 and ppp2 different addresses.
992 <H3><A name="kflags">ipsec_setup: Cannot adjust kernel flags</A></H3>
993 A mailing list message form technical lead Henry Spencer:
995 > When FreeS/WAN IPSEC 1.7 is starting on my 2.0.38 Linux kernel the following
996 > error message is generated:
997 > ipsec_setup: Cannot adjust kernel flags, no /proc/sys/net/ipsec directory!
998 > What is supposed to create this directory and how can I fix this problem?
1000 I think that directory is a 2.2ism, although I'm not certain (I don't have
1001 a 2.0.xx system handy any more for testing). Without it, some of the
1002 ipsec.conf config-setup flags won't work, but otherwise things should
1005 You also need to enable the <VAR>/proc</VAR> filesystem in your kernel
1006 configuration for these operations to work.
1007 <H3><A name="conn_name">Connection names in Pluto error messages</A></H3>
1008 <P> From Pluto programmer Hugh Redelmeier:</P>
1010 | Jan 17 16:21:10 remus Pluto[13631]: "jumble" #1: responding to Main Mode from Road Warrior 130.205.82.46
1011 | Jan 17 16:21:11 remus Pluto[13631]: "jumble" #1: no suitable connection for peer @banshee.wittsend.com
1013 | The connection "jumble" has nothing to do with the incoming
1014 | connection requests, which were meant for the connection "banshee".
1016 You are right. The message tells you which Connection Pluto is
1017 currently using, which need not be the right one. It need not be the
1018 right one now for the negotiation to eventually succeed! This is
1019 described in ipsec_pluto(8) in the section "Road Warrior Support".
1021 There are two times when Pluto will consider switching Connections for
1022 a state object. Both are in response to receiving ID payloads (one in
1023 Phase 1 / Main Mode and one in Phase 2 / Quick Mode). The second is
1024 not unique to Road Warriors. In fact, neither is the first any more
1025 (two connections for the same pair of hosts could differ in Phase 1 ID
1026 payload; probably nobody else has tried this).
1028 <H3><A name="cantorient">Pluto: ... can't orient connection</A></H3>
1029 Each Pluto needs to know whether it is running on the machine which
1030 the connection description calls <VAR>left</VAR> or on <VAR>right</VAR>
1031 . It figures that out by:
1033 <LI>looking at the interfaces given in <VAR>interfaces=</VAR> lines in
1034 the <VAR>config setup</VAR> section </LI>
1035 <LI>discovering the IP addresses for those interfaces </LI>
1036 <LI>searching for a match between those addresses and the ones given
1037 in <VAR>left=</VAR> or <VAR>right=</VAR> lines. </LI>
1039 <P> Normally a match is found. Then Pluto knows where it is and can set
1040 up other things (for example, if it is <VAR>left</VAR>) using
1041 parameters such as <VAR>leftsubnet</VAR> and <VAR>leftnexthop</VAR>,
1042 and sending its outgoing packets to <VAR>right</VAR>. </P>
1043 <P> If no match is found, it emits the above error message. </P>
1044 <H3><A name="noconn">Pluto: ... no connection is known</A></H3>
1045 This error message occurs when a remote system attempts to negotiate a
1046 connection and Pluto does not have a connection description that
1047 matches what the remote system has requested. The most common cause is
1048 a configuration error on one end or the other.
1049 <P> Parameters involved in this match are <VAR>left</VAR>, <VAR>right</VAR>
1050 , <VAR>leftsubnet</VAR> and <VAR>rightsubnet</VAR>. </P>
1051 <P><STRONG> The match must be exact</STRONG>. For example, if your left
1052 subnet is a.b.c.0/24 then neither a single machine in that net nor a
1053 smaller subnet such as a.b.c.64/26 will be considered a match. </P>
1054 <P> The message can also occur when an appropriate description exists
1055 but Pluto has not loaded it. Use an <VAR>auto=add</VAR> statement in
1056 the connection description, or an <VAR>ipsec auto --add <conn_name></VAR>
1057 command, to correct this. </P>
1058 <P> An explanation from the Pluto developer: </P>
1060 | Jul 12 15:00:22 sohar58 Pluto[574]: "corp_road" #2: cannot respond to IPsec
1061 | SA request because no connection is known for
1062 | 216.112.83.112/32===216.112.83.112...216.67.25.118
1064 This is the first message from the Pluto log showing a problem. It
1065 means that PGPnet is trying to negotiate a set of SAs with this
1068 216.112.83.112/32===216.112.83.112...216.67.25.118
1069 ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
1070 client on our side our host PGPnet host, no client
1072 None of the conns you showed look like this.
1076 to see a snapshot of what connections are in pluto, what
1077 negotiations are going on, and what SAs are established.
1079 The leftsubnet= (client) in your conn is 216.112.83.64/26. It must
1080 exactly match what pluto is looking for, and it does not.
1082 <H3><A name="nosuit">Pluto: ... no suitable connection ...</A></H3>
1083 This is similar to the <A href="#noconn">no connection known</A>
1084 error, but occurs at a different point in Pluto processing.
1085 <P> Here is one of Claudia's messages explaining the problem: </P>
1089 > What could be the reason of the following error?
1090 > "no suitable connection for peer '@xforce'"
1092 When a connection is initiated by the peer, Pluto must choose which entry in
1093 the conf file best matches the incoming connection. A preliminary choice is
1094 made on the basis of source and destination IPs, since that information is
1095 available at that time.
1097 A payload containing an ID arrives later in the negotiation. Based on this
1098 id and the *id= parameters, Pluto refines its conn selection. ...
1100 The message "no suitable connection" indicates that in this refining step,
1101 Pluto does not find a connection that matches that ID.
1103 Please see "Selecting a connection when responding" in man ipsec_pluto for
1106 <P> See also <A href="#conn_name">Connection names in Pluto error
1108 <H3><A name="noconn.auth">Pluto: ... no connection has been authorized</A>
1110 Here is one of Claudia's messages discussing this problem:
1114 > May 22 10:46:31 debian Pluto[25834]: packet from x.y.z.p:10014:
1115 > initial Main Mode message from x.y.z.p:10014
1116 but no connection has been authorized
1118 This error occurs early in the connection negotiation process,
1119 at the first step of IKE negotiation (Main Mode), which is itself the
1120 first of two negotiation phases involved in creating an IPSec connection.
1122 Here, Linux FreeS/WAN receives a packet from a potential peer, which
1123 requests that they begin discussing a connection.
1125 The "no connection has been authorized" means that there is no connection
1126 description in Linux FreeS/WAN's internal database that can be used to
1127 link your ipsec interface with that peer.
1129 "But of course I configured that connection!"
1131 It may be that the appropriate connection description exists in ipsec.conf
1132 but has not been added to the database with ipsec auto --add myconn or the
1133 auto=add method. Or, the connection description may be misconfigured.
1135 The only parameters that are relevant in this decision are left= and right= .
1136 Local and remote ports are also taken into account -- we see that the port
1137 is printed in the message above -- but there is no way to control these
1141 Failure at "no connection has been authorized" is similar to the
1142 "no connection is known for..." error in the FAQ, and the "no suitable
1143 connection" error described in the snapshot's FAQ. In all three cases,
1144 Linux FreeS/WAN is trying to match parameters received in the
1145 negotiation with the connection description in the local config file.
1147 As it receives more information, its matches take more parameters into
1148 account, and become more precise: first the pair of potential peers,
1149 then the peer IDs, then the endpoints (including any subnets).
1151 The "no suitable connection for peer *" occurs toward the end of IKE
1152 (Main Mode) negotiation, when the IDs are matched.
1154 "no connection is known for a/b===c...d" is seen at the beginning of IPSec
1155 (Quick Mode, phase 2) negotiation, when the connections are matched using
1156 left, right, and any information about the subnets.
1158 <H3><A name="noDESsupport">Pluto: ... OAKLEY_DES_CBC is not supported.</A>
1160 This message occurs when the other system attempts to negotiate a
1161 connection using single DES, which we do not support because it is <A href="politics.html#desnotsecure">
1163 <P> Our interoperation document has suggestions for <A href="interop.html#noDES">
1164 how to deal with</A> systems that attempt to use single DES. </P>
1165 <H3><A name="notransform"> Pluto: ... no acceptable transform</A></H3>
1166 This message means that the other gateway has made a proposal for
1167 connection parameters, but nothing they proposed is acceptable to
1168 Pluto. Possible causes include:
1170 <LI>misconfiguration on either end </LI>
1171 <LI>policy incompatibilities, for example we require encrypted
1172 connections but they are trying to create one with just authentication </LI>
1173 <LI>interoperation problems, for example they offer only single DES and
1174 FreeS/WAN does not support that. (see <A href="interop.html#noDES">below</A>
1175 for DES problems) </LI>
1177 A more detailed explanation, from Pluto programmer Hugh Redelmeier:
1181 When one IKE system (for example, Pluto) is negotiating with another
1182 to create an SA, the Initiator proposes a bunch of choices and the
1183 Responder replies with one that it has selected.
1185 The structure of the choices is fairly complicated. An SA payload
1186 contains a list of lists of "Proposals". The outer list is a set of
1187 choices: the selection must be from one element of this list.
1189 Each of these elements is a list of Proposals. A selection must be
1190 made from each of the elements of the inner list. In other words,
1191 *all* of them apply (that is how, for example, both AH and ESP can
1194 Within each of these Proposals is a list of Transforms. For each
1195 Proposal selected, one Transform must be selected (in other words,
1196 each Proposal provides a choice of Transforms).
1198 Each Transform is made up of a list of Attributes describing, well,
1199 attributes. Such as lifetime of the SA. Such as algorithm to be
1200 used. All the Attributes apply to a Transform.
1202 You will have noticed a pattern here: layers alternate between being
1203 disjunctions ("or") and conjunctions ("and").
1205 For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
1206 cut back. There must be exactly one Proposal. So this degenerates to
1207 a list of Transforms, one of which must be chosen.
1209 In your case, no proposal was considered acceptable to Pluto (the
1210 Responder). So negotiation ceased. Pluto logs the reason it rejects
1211 each Transform. So look back in the log to see what is going wrong.
1213 <H3><A name="econnrefused">ECONNREFUSED error message</A></H3>
1214 <P> From John Denker, on the mailing list:</P>
1217 some IKE message we sent has been rejected with
1218 ECONNREFUSED (kernel supplied no details)
1219 is much more suitable than the previous version. Thanks.
1221 2) Minor suggestion for further improvement: it might be worth mentioning
1223 tcpdump -i eth1 icmp[0] != 8 and icmp[0] != 0
1224 is useful for tracking down the details in question. We shouldn't expect
1225 all IPsec users to figure that out on their own. The log message might
1226 even provide a hint as to where to look in the docs.
1228 <P> Reply From Pluto developer Hugh Redelmeier</P>
1232 I've added a bit pluto(8)'s BUGS section along these lines.
1233 I didn't have the heart to lengthen this message.
1235 <LI><A name="no_eroute">klips_debug: ... no eroute!</A> This message
1236 means <A href="glossary.html#KLIPS">KLIPS</A> has received a packet for
1237 which no IPSEC tunnel has been defined. </LI>
1238 <P> Here is a more detailed duscussion from the team's tech support
1239 person Claudia Schmeing, responding to a query on the mailing list: </P>
1241 > Why ipsec reports no eroute! ???? IP Masq... is disabled.
1242 In general, more information is required so that people on the list may
1243 give you informed input. See doc/prob.report.
1245 However, I can make some general comments on this type of error.
1247 This error usually looks something like this (clipped from an archived
1250 > ttl:64 proto:1 chk:45459 saddr:192.168.1.2 daddr:192.168.100.1
1251 > ... klips_debug:ipsec_findroute: 192.168.1.2->192.168.100.1
1252 > ... klips_debug:rj_match: * See if we match exactly as a host destination
1253 > ... klips_debug:rj_match: ** try to match a leaf, t=0xc1a260b0
1254 > ... klips_debug:rj_match: *** start searching up the tree, t=0xc1a260b0
1255 > ... klips_debug:rj_match: **** t=0xc1a260c8
1256 > ... klips_debug:rj_match: **** t=0xc1fe5960
1257 > ... klips_debug:rj_match: ***** not found.
1258 > ... klips_debug:ipsec_tunnel_start_xmit: Original head/tailroom: 2, 28
1259 > ... klips_debug:ipsec_tunnel_start_xmit: no eroute!: ts=47.3030, dropping.
1262 What does this mean?
1263 - --------------------
1265 "eroute" stands for "extended route", and is a special type of route
1266 internal to Linux FreeS/WAN. For more information about this type of route,
1267 see the section of man ipsec_auto on ipsec auto --route.
1269 "no eroute!" here means, roughly, that Linux FreeS/WAN cannot find an
1270 appropriate tunnel that should have delivered this packet. Linux
1271 FreeS/WAN therefore drops the packet, with the message "no eroute! ...
1272 dropping", on the assumption that this packet is not a legitimate
1273 transmission through a properly constructed tunnel.
1276 How does this situation come about?
1277 - -----------------------------------
1279 Linux FreeS/WAN has a number of connection descriptions defined in
1280 ipsec.conf. These must be successfully brought "up" to form actual tunnels.
1281 (see doc/setup.html's step 15, man ipsec.conf and man ipsec_auto
1284 Such connections are often specific to the endpoints' IPs. However, in
1285 some cases they may be more general, for example in the case of
1286 Road Warriors where left or right is the special value %any.
1288 When Linux FreeS/WAN receives a packet, it verifies that the packet has
1289 come through a legitimate channel, by checking that there is an
1290 appropriate tunnel through which this packet might legitimately have
1291 arrived. This is the process we see above.
1293 First, it checks for an eroute that exactly matches the packet. In the
1294 example above, we see it checking for a route that begins at 192.168.1.2
1295 and ends at 192.168.100.1. This search favours the most specific match that
1296 would apply to the route between these IPs. So, if there is a connection
1297 description exactly matching these IPs, the search will end there. If not,
1298 the code will search for a more general description matching the IPs.
1299 If there is no match, either specific or general, the packet will be
1300 dropped, as we see, above.
1302 Unless you are working with Road Warriors, only the first, specific part
1303 of the matching process is likely to be relevant to you.
1306 "But I defined the tunnel, and it came up, why do I have this error?"
1307 - ---------------------------------------------------------------------
1309 One of the most common causes of this error is failure to specify enough
1310 connection descriptions to cover all needed tunnels between any two
1311 gateways and their respective subnets. As you have noticed, troubleshooting
1312 this error may be complicated by the use of IP Masq. However, this error is
1313 not limited to cases where IP Masq is used.
1315 See doc/configuration.html#multitunnel for a detailed example of the
1316 solution to this type of problem.
1318 <H3><A name="SAused">... trouble writing to /dev/ipsec ... SA already
1320 From the mailing list:
1322 > When I activate one manual tunnels it works, but when I try to activate
1323 > another tunnel, it gives an error message...
1324 > tunnel_2: Had trouble writing to /dev/ipsec SA:tun0x200@202.103.5.63 --
1325 > SA already in use. Delete old one first.
1327 Please read the Using manual keying in production discussion in
1328 config.html, specifically the part about needing a different spi
1329 (or spibase) setting for each connection.
1331 This problem is also discussed in this FAQ under the heading <A href="#spi_error">
1332 One manual connection works, but second one fails</A>.
1333 <H3><A name="ignore">... ignoring ... payload</A></H3>
1334 This message is harmless. The IKE protocol provides for a number of
1335 optional messages types:
1338 <LI>initial contact </LI>
1342 An implementation is never required to send these, but they are
1343 allowed to. The receiver is not required to do anything with them.
1344 FreeS/WAN ignores them, but notifies you via the logs.
1345 <P> For the "ignoring delete SA Payload" message, see also the
1346 discussion below of cleaning up <A href="#deadtunnel">dead tunnels</A>. </P>
1347 <H2><A name="canI">Can I ...</A></H2>
1348 <H3><A name="reload">Can I reload connection info without restarting?</A>
1350 Yes, you can do this. Here are the details, in a mailing list message
1351 from Pluto programmer Hugh Redelmeier:
1353 | How can I reload config's without restarting all of pluto and klips? I am using
1354 | FreeSWAN -> PGPNet in a medium sized production environment, and would like to be
1355 | able to add new connections ( i am using include config/* ) without dropping current
1360 | If not, are there plans to add this kind of feature?
1362 ipsec auto --add whatever
1363 This will look in the usual place (/etc/ipsec.conf) for a conn named
1364 whatever and add it.
1366 If you added new secrets, you need to do
1367 ipsec auto --rereadsecrets
1368 before Pluto needs to know those secrets.
1370 | I have looked (perhaps not thoroughly enough tho) to see how to do this:
1372 There may be more bits to look for, depending on what you are trying
1375 <P> Another useful command here is <NOBR><VAR>ipsec auto --replace
1376 <conn_name></VAR></NOBR> which re-reads data for a named connection. </P>
1377 <H3><A name="masq.faq">Can I use several masqueraded subnets?</A></H3>
1378 Yes. This is done all the time. See the discussion in our <A href="config.html#route_or_not">
1379 setup</A> document. The only restriction is that the subnets on the two
1380 ends must not overlap. See the next question.
1381 <P> Here is a mailing list message on the topic. The user incorrectly
1382 thinks you need a 2.4 kernel for this -- actually various people have
1383 been doing it on 2.0 and 2.2 for quite some time -- but he has it right
1386 Subject: Double NAT and freeswan working :)
1387 Date: Sun, 11 Mar 2001
1388 From: Paul Wouters <paul@xtdnet.nl>
1390 Just to share my pleasure, and make an entry for people who are searching
1391 the net on how to do this. Here's the very simple solution to have a double
1392 NAT'ed network working with freeswan. (Not sure if this is old news, but I'm
1393 not on the list (too much spam) and I didn't read this in any HOWTO/FAQ/doc
1394 on the freeswan site yet (Sandy, put it in! :)
1396 10.0.0.0/24 --- 10.0.0.1 a.b.c.d ---- a.b.c.e {internet} ----+
1398 10.0.1.0/24 --- 10.0.1.1 f.g.h.i ---- f.g.h.j {internet} ----+
1400 the goal is to have the first network do a VPN to the second one, yet also
1401 have NAT in place for connections not destinated for the other side of the
1402 NAT. Here the two Linux security gateways have one real IP number (cable
1403 modem, dialup, whatever.
1405 The problem with NAT is you don't want packets from 10.*.*.* to 10.*.*.*
1406 to be NAT'ed. While with Linux 2.2, you can't, with Linux 2.4 you can.
1408 (This has been tested and works for 2.4.2 with Freeswan snapshot2001mar8b)
1410 relevant parts of /etc/ipsec.conf:
1413 leftsubnet=10.0.1.0/24
1416 leftid=@firewall.netone.nl
1417 leftrsasigkey=0x0........
1419 rightsubnet=10.0.0.0/24
1420 rightnexthop=a.b.c.e
1422 rightid=@firewall.nettwo.nl
1423 rightrsasigkey=0x0......
1424 # To authorize this connection, but not actually start it, at startup,
1428 and now the real trick. Setup the NAT correctly on both sites:
1431 iptables -t nat -A POSTROUTING -o eth0 -d \! 10.0.0.0/8 -j MASQUERADE
1433 This tells the NAT code to only do NAT for packets with destination other then
1434 10.* networks. note the backslash to mask the exclamation mark to protect it
1441 <H3><A name="dup_route">Can I use subnets masqueraded to the same
1443 <STRONG> No.</STRONG> The notion that IP addresses are unique is one of
1444 the fundamental principles of the IP protocol. Messing with it is
1445 exceedingly perilous.
1446 <P> Fairly often a situation comes up where a company has several
1447 branches, all using the same <A href="glossary.html#non-routable">
1448 non-routable addresses</A>, perhaps 192.168.0.0/24. This works fine as
1449 long as those nets are kept distinct. The <A href="glossary.html#masq">
1450 IP masquerading</A> on their firewalls ensures that packets reaching
1451 the Internet carry the firewall address, not the private address. </P>
1452 <P> This can break down when IPSEC enters the picture. FreeS/WAN builds
1453 a tunnel that pokes through both masquerades and delivers packets from <VAR>
1454 leftsubnet</VAR> to <VAR>rightsubnet</VAR> and vice versa. For this to
1455 work, the two subnets <EM>must</EM> be distinct. </P>
1456 <P> There are several solutions to this problem. </P>
1458 <LI>Usually, you <STRONG>re-number the subnets</STRONG>. Perhaps the
1459 Vancouver office becomes 192.168.101.0/24, Calgary 192.168.102.0/24 and
1460 so on. FreeS/WAN can happily handle this. With, for example <VAR>
1461 leftsubnet=192.168.101.0/24</VAR> and <VAR>rightsubnet=192.168.102.0/24</VAR>
1462 in a connection description, any machine in Calgary can talk to any
1463 machine in Vancouver. If you want to be more restrictive and use
1464 something like <VAR>leftsubnet=192.168.101.128/25</VAR> and <VAR>
1465 rightsubnet=192.168.102.240/28</VAR> so only certain machines on each
1466 end have access to the tunnel, that's fine too. </LI>
1467 <LI>You could also <STRONG>split the subnet</STRONG> into smaller ones,
1468 for example using <VAR>192.168.1.0/25</VAR> in Vancouver and <VAR>
1469 rightsubnet=192.168.0.128/25</VAR> in Calgary. </LI>
1470 <LI>Alternately, you can just <STRONG>give up routing</STRONG> directly
1471 to machines on the subnets. Omit the <VAR>leftsubnet</VAR> and <VAR>
1472 rightsubnet</VAR> parameters from your connection descriptions. Your
1473 IPSEC tunnels will then run between the public interfaces of the two
1474 firewalls. Packets will be masqueraded both before they are put into
1475 tunnels and after they emerge. Your Vancouver client machines will see
1476 only one Calgary machine, the firewall. </LI>
1478 <H3><A name="road.masq">Can I assign a road warrior an address on my
1480 Yes, but it is tricky. This has been discussed on the mailing list.
1481 The discussion was not entirely clear to me, so I cannot yet document
1482 the procedures. At this point, all I know is:
1484 <LI>You can use a variant of the <A href="config.html#extruded">
1485 extruded subnet</A> procedure. </LI>
1486 <LI>You have to avoid having the road warrior's assigned address within
1487 the range you actually use at home base. See previous question. </LI>
1488 <LI>On the other hand, you want the roadwarrior's address to be within
1489 the range that <EM>seems</EM> to be on your network. </LI>
1491 <P> For example, you might have: </P>
1493 <DT>leftsubnet=a.b.c.0/25</DT>
1494 <DD>head office network</DD>
1495 <DT>rightsubnet=a.b.c.240/32</DT>
1496 <DD>extruded to a road warrior</DD>
1498 <DD>whole network, including both the above</DD>
1500 <H3><A name="QoS">Can I use Quality of Service routing with FreeS/WAN?</A>
1502 From project technical lead Henry Spencer:
1504 > Do QoS add to FreeS/WAN?
1505 >For example integrating DiffServ and FreeS/WAN?
1507 With a current version of FreeS/WAN, you will have to add hidetos=no to
1508 the config-setup section of your configuration file. By default, the TOS
1509 field of tunnel packets is zeroed; with hidetos=no, it is copied from the
1510 packet inside. (This is a modest security hole, which is why it is no
1511 longer the default.)
1513 DiffServ does not interact well with tunneling in general. Ways of
1514 improving this are being studied.
1516 <P> Copying the TOS information from the encapsulated packet to the
1517 outer header reveals the TOS information to an eavesdropper. It is not
1518 clear whether or how an attacker could use this information, but since
1519 we do not have to give it to him, our default is not to. </P>
1520 <P> See <A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A> for
1521 more on the <VAR>hidetos=</VAR> parameter. </P>
1522 <H3><A name="deadtunnel">Can I recognise dead tunnels and shut them
1524 There is no general mechanism to do this is in the IPSEC protocols.
1525 <P> From time to time, there is discussion on the IETF Working Group <A href="mail.htl#ietf">
1526 mailing list</A> of adding a "keep-alive" mechanism (which some say
1527 should be called "make-dead"), but it is a fairly complex problem and
1528 no consensus has been reached on whether or how it should be done. </P>
1529 <P> The protocol does have optional <A href="#ignore">delete-SA</A>
1530 messages which one side can send when it closes a connection in hopes
1531 this will cause the other side to do the same. FreeS/WAN does not
1532 currently support these. In any case, they would not solve the problem
1535 <LI>a gateway that crashes or hangs would not send the messages </LI>
1536 <LI>the sender is not required to send them </LI>
1537 <LI>they are not authenticated, so any receiver that trusts them leaves
1538 itself open to a <A href="glossary.html#DOS">denial of service</A>
1540 <LI>the receiver is not required to do anything about them </LI>
1541 <LI>the receiver cannot acknowledge them; the protocol provides no
1542 mechanism for that </LI>
1543 <LI>since they are not acknowledged, the sender cannot rely on them </LI>
1545 <P> However, connections do have limited lifetimes and you can control
1546 how many attempts your gateway makes to rekey before giving up. For
1547 example, you can set: </P>
1553 With these settings old connections will be cleaned up. Within 30
1554 minutes of the other end dying, rekeying will be attempted. If it
1555 succeeds, the new connection replaces the old one. If it fails, no new
1556 connection is created. Either way, the old connection is taken down
1557 when its lifetime expires.
1558 <P> Here is a mailing list message on the topic from FreeS/WAN tech
1559 support person Claudia Schmeing: </P>
1561 You ask how to determine whether a tunnel is redundant:
1563 > Can anybody explain the best way to determine this. Esp when a RW has
1564 > disconnected? I thought 'ipsec auto --status' might be one way.
1566 If a tunnel goes down from one end, Linux FreeS/WAN on the
1567 other end has no way of knowing this until it attempts to rekey.
1568 Once it tries to rekey and fails, it will 'know' that the tunnel is
1571 Because it doesn't have a way of knowing the state until this point,
1572 it will also not be able to tell you the state via ipsec auto --status.
1574 > However, comparing output from a working tunnel with that of one that
1576 > did not show clearly show tunnel status.
1578 If your tunnel is down but not 'unrouted' (see man ipsec_auto), you
1579 should not be able to ping the opposite side of the tunnel. You can
1580 use this as an indicator of tunnel status.
1582 On a related note, you may be interested to know that as of 1.7,
1583 redundant tunnels caused by RW disconnections are likely to be
1584 less of a pain. From doc/CHANGES:
1586 There is a new configuration parameter, uniqueids, to control a new Pluto
1587 option: when a new connection is negotiated with the same ID as an old
1588 one, the old one is deleted immediately. This should help eliminate
1589 dangling Road Warrior connections when the same Road Warrior reconnects.
1590 It thus requires that IDs not be shared by hosts (a previously legal but
1591 probably useless capability). NOTE WELL: the sample ipsec.conf now has
1592 uniqueids=yes in its config-setup section.
1599 <H3><A name="demanddial">Can I build IPSEC tunnels over a demand-dialed
1601 This is possible, but not easy. FreeS/WAN technical lead Henry Spencer
1604 > 5. If the ISDN link goes down in between and is reestablished, the SAs
1605 > are still up but the eroute are deleted and the IPSEC interface shows
1606 > garbage (with ifconfig)
1607 > 6. Only restarting IPSEC will bring the VPN back online.
1609 This one is awkward to solve. If the real interface that the IPsec
1610 interface is mounted on goes down, it takes most of the IPsec machinery
1611 down with it, and a restart is the only good way to recover.
1613 The only really clean fix, right now, is to split the machines in two:
1615 1. A minimal machine serves as the network router, and only it is aware
1616 that the link goes up and down.
1618 2. The IPsec is done on a separate gateway machine, which thinks it has
1619 a permanent network connection, via the router.
1621 This is clumsy but it does work. Trying to do both functions within a
1622 single machine is tricky. There is a software package (diald) which will
1623 give the illusion of a permanent connection for demand-dialed modem
1624 connections; I don't know whether it's usable for ISDN, or whether it can
1625 be made to cooperate properly with FreeS/WAN.
1627 Doing a restart each time the interface comes up *does* work, although it
1628 is a bit painful. I did that with PPP when I was running on a modem link;
1629 it wasn't hard to arrange the PPP scripts to bring IPsec up and down at
1630 the right times. (I'd meant to investigate diald but never found time.)
1632 In principle you don't need to do a complete restart on reconnect, but you
1633 do have to rebuild some things, and we have no nice clean way of doing
1634 only the necessary parts.
1636 In the same thread, one user commented:
1638 Subject: Re: linux-ipsec: IPSEC and Dial Up Connections
1639 Date: Wed, 22 Nov 2000
1640 From: Andy Bradford <andyb@calderasystems.com>
1642 On Wed, 22 Nov 2000 19:47:11 +0100, Philip Reetz wrote:
1644 > Are there any ideas what might be the cause of the problem and any way
1645 > to work around it.
1646 > Any help is highly appreciated.
1648 On my laptop, when using ppp there is a ip-up script in /etc/ppp that
1649 will be executed each time that the ppp interface is brought up.
1650 Likewise there is an ip-down script that is called when it is taken
1651 down. You might consider custimzing those to stop and start FreeS/Wan
1652 with each connection. I believe that ISDN uses the same files, though
1653 I could be wrong---there should be something similar though.
1655 <H3><A name="GRE">Can I build GRE tunnels over IPSEC?</A></H3>
1656 This is possible in theory, but we are short on practical details. If
1657 you do this, please let us know via the <A href="mail.html">mailing
1659 <P> Theere is a <A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00209.html">
1660 list message</A> with links to relevant resources. </P>
1661 <H3><A name="PKIcert"> Does FreeS/WAN support X.509 or other PKI
1662 certificates?</A></H3>
1663 FreeS/WAN, as distributed, does not currently support use of <A href="glossary.html#x509">
1664 X.509</A> or other <A href="glossary.html#PKI">PKI</A> certificates for
1665 authentication of gateways. We are concentrating on moving toward
1666 authentication via <A href="glossary.html#SDNS">Secure DNS</A> and <A href="glossary.html#carpediem">
1667 opportunistic encryption</A>; X.509 support is not (or at least not
1668 yet) on the priority list.
1669 <P> On the other hand, it is a priority for some users and
1670 user-contributed patches are available to add X.509 certificate support
1671 to FreeS/WAN now. See the <A href="web.html#patch"> patches</A> section
1672 of our web references document for details. </P>
1673 <H3><A name="Radius">Does FreeS/WAN support Radius or other user
1674 authentication?</A></H3>
1675 Not yet. So far, there is no standard way to authenticate users for
1676 IPSEC, though there is a very active IETF <A href="http://www.ietf.org/html.charters/ipsra-charter.html">
1677 working group</A> looking at the problem, and several vendors have
1678 implemented various things already.
1679 <P> In the absence of a standard, user authentication has not been a
1680 priority for the FreeS/WAN team, and is unlikely to become one. This
1681 would be a good project for a volunteer, perhaps a staff member or
1682 contractor at some company that needs the feature. Certainly our team
1683 would co-operate with such an effort; we just don't have time to do it. </P>
1684 <P> Of course, there are various ways to avoid any requirement for user
1685 authentication in IPSEC. Consider the situation where road warriors
1686 build IPSEC tunnels to your office net and you are considering
1687 requiring user authentication during tunnel negotiation. Alternatives
1690 <LI>If you can trust the road warrior machines, then set them up so
1691 that only authorised users can create tunnels. If your road warriors
1692 use laptops, consider the possibility of theft. </LI>
1693 <LI>If the tunnel only provides access to particular servers and you
1694 can trust those servers, then set the servers up to require user
1695 authentication. </LI>
1697 If either of those is trustworthy, it is not clear that you need user
1698 authentication in IPSEC.
1699 <H3><A name="noDES.faq">Does FreeS/WAN support single DES encryption?</A>
1701 No, single DES is not used either at the <A href="glossary.html#IKE">
1702 IKE</A> level for negotiating connections or at the <A href="glossary.html#IPSEC">
1703 IPSEC</A> level for actually building them.
1704 <P> Single DES is <A href="politics.html#desnotsecure">insecure</A>. As
1705 we see it, it is more important to deliver real security than to comply
1706 with a standard which has been subverted into allowing use of
1707 inadequate methods. See this <A href="politics.html#weak">discussion</A>
1709 <P> If you want to interoperate with an IPSEC implementation which
1710 offers only DES, see our <A href="interop.html#noDES">interoperation</A>
1712 <H2><A name="spam">Why don't you restrict the mailing lists to reduce
1714 <P> As a matter of policy, some of our <A href="mail.html">mailing lists</A>
1715 need to be open to non-subscribers. Project management feel strongly
1716 that maintaining this openness is more important than blocking spam. </P>
1718 <LI>Users should be able to get help or report bugs without
1720 <LI>Even a user who is subscribed may not have access to his or her
1721 subscribed account when he or she needs help, miles from home base in
1722 the middle of setting up a client's gateway. </LI>
1723 <LI>There is arguably a legal requirement for this policy. A US
1724 resident or citizen could be charged under munitions export laws for
1725 providing technical assistance to a foreign cryptographic project. Such
1726 a charge would be more easily defended if the discussion takes place in
1727 public, on an open list. </LI>
1729 <P> This has been discussed several times at some length on the list.
1730 See the <A href="mail.html#archive">list archives</A>. Bringing the
1731 topic up again is unlikely to be useful. Please don't. Or at the very
1732 least, please don't without reading the archives and being certain that
1733 whatever you are about to suggest has not yet been discussed. </P>
1734 <P> Project technical lead Henry Spencer summarised one discussion: <BLOCKQUOTE>
1735 For the third and last time: this list *will* *not* do address-based
1736 filtering. This is a policy decision, not an implementation problem.
1737 The decision is final, and is not open to discussion. This needs to be
1738 communicated better to people, and steps are being taken to do that. </BLOCKQUOTE>
1739 Adding this FAQ section is one of the steps he refers to. </P>
1740 <P> You have various options other than just putting up with the spam,
1741 filtering it yourself, or unsubscribing: </P>
1743 <LI>subscribe only to one or both of our lists with restricted posting
1746 <LI><A href="mailto:briefs@lists.freeswan.org?body=subscribe">briefs</A>
1747 , weekly list summaries </LI>
1748 <LI><A href="mailto:announce@lists.freeswan.org?body=subscribe">announce</A>
1749 , project-related announcements </LI>
1752 <LI>read the other lists via the <A href="mail.html#archive">archives</A>
1755 <P> A number of tools are available to filter mail. </P>
1757 <LI>Many mail readers include some filtering capability. </LI>
1758 <LI>Many Linux distributions include <A href="http://www.procmail.org/">
1759 procmail(8)</A> for server-side filtering. </LI>
1760 <LI>The <A href="http://www.spambouncer.org/">Spam Bouncer</A> is a set
1761 of procmail(8) filters designed to combat spam. </LI>
1762 <LI>Roaring Penguin have a <A href="http://www.roaringpenguin.com/mimedefang/">
1763 MIME defanger</A> that removes potentially dangerous attachments. </LI>
1765 <P> If you use your ISP's mail server rather than running your own,
1766 consider suggesting to the ISP that they tag suspected spam as <A href="http://www.msen.com/1997/spam.html#SUSPECTED">
1767 this ISP</A> does. They could just refuse mail from dubious sources,
1768 but that is tricky and runs some risk of losing valuable mail or
1769 senselessly annoying senders and their admins. However, they can safely
1770 tag and deliver dubious mail. The tags can greatly assist your
1772 <P> For information on tracking down spammers, see these <A href="http://www.rahul.net/falk/#howtos">
1773 HowTos</A>, or the <A href="http://www.sputum.com/index2.html">Sputum</A>
1774 site. Sputum have a Linux anti-spam screensaver available for
1776 <P> Here is a more detailed message from Henry: </P>
1778 On Mon, 15 Jan 2001, Jay Vaughan wrote:
1779 > I know I'm flogging a dead horse here, but I'm curious as to the reasons for
1780 > an aversion for a subscriber-only mailing list?
1782 Once again: for legal reasons, it is important that discussions of these
1783 things be held in a public place -- the list -- and we do not want to
1784 force people to subscribe to the list just to ask one question, because
1785 that may be more than merely inconvenient for them. There are also real
1786 difficulties with people who are temporarily forced to use alternate
1787 addresses; that is precisely the time when they may be most in need of
1788 help, yet a subscribers-only policy shuts them out.
1790 These issues do not apply to most mailing lists, but for a list that is
1791 (necessarily) the primary user support route for a crypto package, they
1792 are very important. This is *not* an ordinary mailing list; it has to
1793 function under awkward constraints that make various simplistic solutions
1794 inapplicable or undesirable.
1796 > We're *ALL* sick of hearing about list management problems, not just you
1797 > old-timers, so why don't you DO SOMETHING EFFECTIVE ABOUT IT...
1799 Because it's a lot harder than it looks, and many existing "solutions"
1800 have problems when examined closely.
1802 > A suggestion for you, based on 10 years of experience with management of my
1803 > own mailing lists would be to use mailman, which includes pretty much every
1804 > feature under the sun that you guys need and want, plus some. The URL for
1807 I assure you, we're aware of mailman. Along with a whole bunch of others,
1808 including some you almost certainly have never heard of (I hadn't!).
1810 > As for the argument that the list shouldn't be configured to enforce
1811 > subscription - I contend that it *SHOULD* AT LEAST require manual address
1812 > verification in order for posts to be redirected.
1814 You do realize, I hope, that interposing such a manual step might cause
1815 your government to decide that this is not truly a public forum, and thus
1816 you could go to jail if you don't get approval from them before mailing to
1817 it? If you think this sounds irrational, your government is noted for
1818 making irrational decisions in this area; we can't assume that they will
1819 suddenly start being sensible. See above about awkward constraints. You
1820 may be willing to take the risk, but we can't, in good conscience, insist
1821 that all users with problems do so.
1826 and a message on the topic from project leader John Gilmore:
1828 Subject: Re: The linux-ipsec list's topic
1829 Date: Sat, 30 Dec 2000
1830 From: John Gilmore <gnu@toad.com>
1832 I'll post this single message, once only, in this discussion, and then
1833 not burden the list with any further off-topic messages. I encourage
1834 everyone on the list to restrain themself from posting ANY off-topic
1835 messages to the linux-ipsec list.
1837 The topic of the linux-ipsec mailing list is the FreeS/WAN software.
1839 I frequently see "discussions about spam on a list" overwhelm the
1840 volume of "actual spam" on a list. BOTH kinds of messages are
1841 off-topic messages. Twenty anti-spam messages take just as long to
1842 detect and discard as twenty spam messages.
1844 The Linux-ipsec list encourages on-topic messages from people who have
1845 not joined the list itself. We will not censor messages to the list
1846 based on where they originate, or what return address they contain.
1847 In other words, non-subscribers ARE allowed to post, and this will not
1848 change. My own valid contributions have been rejected out-of-hand by
1849 too many other mailing lists for me to want to impose that censorship
1850 on anybody else's contributions. And every day I see the damage that
1851 anti-spam zeal is causing in many other ways; that zeal is far more
1852 damaging to the culture of the Internet than the nuisance of spam.
1854 In general, it is the responsibility of recipients to filter,
1855 prioritize, or otherwise manage the handling of email that comes to
1856 them. It is not the responsibility of the rest of the Internet
1857 community to refrain from sending messages to recipients that they
1858 might not want to see. If your software infrastructure for managing
1859 your incoming email is insufficient, then improve it. If you think
1860 the signal-to-noise ratio on linux-ipsec is too poor, then please
1861 unsubscribe. But don't further increase the noise by posting to the
1862 linux-ipsec list about those topics.
1865 founder sponsor, FreeS/WAN project
1868 <A HREF="toc.html">Contents</a>
1869 <A HREF="rfc.html">Previous</a>
1870 <A HREF="performance.html">Next</a>
OSDN Git Service
