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