3 <meta http-equiv="Content-Type" content="text/html">
4 <title>Advanced FreeS/WAN configuration</title>
6 content="Linux, IPsec, VPN, security, FreeSWAN, configuration">
9 Written by Sandy Harris for the Linux FreeS/WAN project
10 Freely distributable under the GNU General Public License
12 More information at www.freeswan.org
13 Feedback to users@lists.freeswan.org
16 RCS ID: $Id: adv_config.html,v 1.13 2002/03/24 18:47:34 sandy Exp $
17 Last changed: $Date: 2002/03/24 18:47:34 $
18 Revision number: $Revision: 1.13 $
20 CVS revision numbers do not correspond to FreeS/WAN release numbers.
25 <h1><a name="otherconf">Other configuration possibilities</a></h1>
27 <p>This document describes various options for FreeS/WAN configuration which
28 are less used or more complex (often both) than the standard cases described
29 in our <a href="quickstart.html">quickstart</a> document.</p>
31 <h2><a name="thumb">Some rules of thumb about configuration</a></h2>
33 <h3><a name="cheap.tunnel">Tunnels are cheap</a></h3>
35 <p>Nearly all of the overhead in IPsec processing is in the encryption and
36 authentication of packets. Our <a href="performance.html">performance</a>
37 document discusses these overheads.</p>
39 <p>Beside those overheads, the cost of managing additional tunnels is
40 trivial. Whether your gateway supports one tunnel or ten just does not
41 matter. A hundred might be a problem; there is a <a
42 href="performance.html#biggate">section</a> on this in the performance
45 <p>So, in nearly all cases, if using multiple tunnels gives you a reasonable
46 way to describe what you need to do, you should describe it that way in your
47 configuration files.</p>
49 <p>For example, one user recently asked on a mailing list about this network
51 <pre> netA---gwA---gwB---netB
54 netA and B are secured netC not.
55 netA and gwA can not access netC</pre>
57 <p>The user had constructed only one tunnel, netA to netB, and wanted to know
58 how to use ip-route to get netC packets into it. This is entirely
59 unnecessary. One of the replies was:</p>
60 <pre> The simplest way and indeed the right way to
61 solve this problem is to set up two connections:
71 rightsubnet=NetC</pre>
73 <p>This would still be correct even if we added nets <nobr>D, E, F,
74 ...</nobr>to the above diagram and needed twenty tunnels.</p>
76 <p>Of course another possibility would be to just use one tunnel, with a
77 subnet mask that includes both netB and netC (or B, C, D, ...). See next
80 <p>In general, you can construct as many tunnels as you need. Networks like
81 netC in this example that do not connect directly to the gateway are fine, as
82 long as the gateway can route to them.</p>
84 <p>The number of tunnels can become an issue if it reaches 50 or so. This is
85 discussed in the <a href="performance.html#biggate">performance</a> document.
86 Look there for information on supporting hundreds of Road Warriors from one
89 <p>If you find yourself with too many tunnels for some reason like having
90 eight subnets at one location and nine at another so you end up with
91 <nobr>9*8=72</nobr>tunnels, read the next section here.</p>
93 <h3><a name="subnet.size">Subnet sizes</a></h3>
95 <p>The subnets used in <var>leftsubnet</var> and <var>rightsubnet</var> can
96 be of any size that fits your needs, and they need not correspond to physical
99 <p>You adjust the size by changing the <a href="glossary.html#subnet">subnet
100 mask</a>, the number after the slash in the subnet description. For
103 <li>in 192.168.100.0/24 the /24 mask says 24 bits are used to designate the
104 network. This leave 8 bits to label machines. This subnet has 256
105 addresses. .0 and .255 are reserved, so it can have 254 machines.</li>
106 <li>A subnet with a /23 mask would be twice as large, 512 addresses.</li>
107 <li>A subnet with a /25 mask would be half the size, 128 addresses.</li>
108 <li>/0 is the whole Internet</li>
109 <li>/32 is a single machine</li>
112 <p>As an example of using these in connection descriptions, suppose your
113 company's head office has four physical networks using the address ranges:</p>
115 <dt>192.168.100.0/24</dt>
117 <dt>192.168.101.0/24</dt>
119 <dt>192.168.102.0/24</dt>
121 <dt>192.168.103.0/24</dt>
122 <dd>administration</dd>
125 <p>You can use exactly those subnets in your connection descriptions, or use
126 larger subnets to grant broad access if required:</p>
128 <dt>leftsubnet=192.168.100.0/24</dt>
129 <dd>remote hosts can access only development</dd>
130 <dt>leftsubnet=192.168.100.0/23</dt>
131 <dd>remote hosts can access development or production</dd>
132 <dt>leftsubnet=192.168.102.0/23</dt>
133 <dd>remote hosts can access marketing or administration</dd>
134 <dt>leftsubnet=192.168.100.0/22</dt>
135 <dd>remote hosts can access any of the four departments</dd>
138 <p>or use smaller subnets to restrict access:</p>
140 <dt>leftsubnet=192.168.103.0/24</dt>
141 <dd>remote hosts can access any machine in administration</dd>
142 <dt>leftsubnet=192.168.103.64/28</dt>
143 <dd>remote hosts can access only certain machines in administration.</dd>
144 <dt>leftsubnet=192.168.103.42/32</dt>
145 <dd>remote hosts can access only one particular machine in
149 <p>To be exact, 192.68.103.64/28 means all addresses whose top 28 bits match
150 192.168.103.64. There are 16 of these because there are 16 possibilities for
151 the remainingg 4 bits. Their addresses are 192.168.103.64 to
154 <p>Each connection description can use a different subnet if required.</p>
156 <p>It is possible to use all the examples above on the same FreeS/WAN
157 gateway, each in a different connection description, perhaps for different
158 classes of user or for different remote offices.</p>
160 <p>It is also possible to have multiple tunnels using different
161 <var>leftsubnet</var> descriptions with the same <var>right</var>. For
162 example, when the marketing manager is on the road he or she might have
165 <dt>leftsubnet=192.168.102.0/24</dt>
166 <dd>all machines in marketing</dd>
167 <dt>192.168.101.32/29</dt>
168 <dd>some machines in production</dd>
169 <dt>leftsubnet=192.168.103.42/32</dt>
170 <dd>one particular machine in administration</dd>
173 <p>This takes three tunnels, but tunnels are cheap. If the laptop is set up
174 to build all three tunnels automatically, then he or she can access all these
175 machines concurrently, perhaps from different windows.</p>
177 <h3><a name="example.more">Other network layouts</a></h3>
179 <p>Here is the usual network picture for a site-to-site VPN::</p>
180 <pre> Sunset==========West------------------East=========Sunrise
181 local net untrusted net local net</pre>
183 <p>and for the Road Warrior::</p>
184 <pre> telecommuter's PC or
186 Sunset==========West------------------East
187 corporate LAN untrusted net</pre>
189 <p>Other configurations are also possible.</p>
191 <h4><a name="internet.subnet">The Internet as a big subnet</a></h4>
193 <p>A telecommuter might have:</p>
194 <pre> Sunset==========West------------------East ================= firewall --- the Internet
195 home network untrusted net corporate network</pre>
197 <p>This can be described as a special case of the general subnet-to-subnet
198 connection. The subnet on the right is 0.0.0.0/0, the whole Internet.</p>
200 <p>West (the home gateway) can have its firewall rules set up so that only
201 IPsec packets to East are allowed out. It will then behave as if its only
202 connection to the world was a wire to East.</p>
204 <p>When machines on the home network need to reach the Internet, they do so
205 via the tunnel, East and the corporate firewall. From the viewpoint of the
206 Internet (perhaps of some EvilDoer trying to break in!), those home office
207 machines are behind the firewall and protected by it.</p>
209 <h4><a name="wireless.config">Wireless</a></h4>
211 <p>Another possible configuration comes up when you do not trust the local
212 network, either because you have very high security standards or because your
213 are using easily-intercepted wireless signals.</p>
215 <p>Some wireless networks have built-in encryption called <a
216 href="glossary.html#WEP">WEP</a>, but its security is dubious. It is a fairly
217 common practice to use IPsec instead.</p>
219 <p>In this case, part of your network may look like this:</p>
220 <pre> West-----------------------------East == the rest of your network
221 workstation untrusted wireless net</pre>
223 <p>Of course, there would likely be several wireless workstations, each with
224 its own IPsec tunnel to the East gateway.</p>
226 <p>The connection descriptions look much like Road Warrior descriptions:</p>
228 <li>each workstation should have its own unique
230 <li>identifier for IPsec</li>
232 <li>connection description.</li>
235 <li>on the gateway, use <var>left=%any</var>, or the workstation IP
237 <li>on workstations, <var>left=%defaultroute</var>, or the workstation IP
239 <li><var>leftsubnet=</var> is not used.</li>
242 <p>The <var>rightsubnet=</var> parameter might be set in any of several
245 <dt>rightsubnet=0.0.0.0/0</dt>
246 <dd>allowing workstations to access the entire Internet (see <a
247 href="#internet.subnet">above</a>)</dd>
248 <dt>rightsubnet=a.b.c.0/24</dt>
249 <dd>allowing access to your entire local network</dd>
250 <dt>rightsubnet=a.b.c.d/32</dt>
251 <dd>restricting the workstation to connecting to a particular server</dd>
254 <p>Of course you can mix and match these as required. For example, a
255 university might allow faculty full Internet access while letting student
256 laptops connect only to a group of lab machines.</p>
258 <h2><a name="choose">Choosing connection types</a></h2>
260 <p>One choice you need to make before configuring additional connections is
261 what type or types of connections you will use. There are several options,
262 and you can use more than one concurrently.</p>
264 <h3><a name="man-auto">Manual vs. automatic keying</a></h3>
266 <p>IPsec allows two types of connections, with manual or automatic keying.
267 FreeS/WAN starts them with commands such as:</p>
268 <pre> ipsec manual --start <var>name</var>
269 ipsec auto --up <var>name</var></pre>
271 <p>The difference is in how they are keyed.</p>
273 <dt><a href="glossary.html#manual">Manually keyed</a> connections</dt>
274 <dd>use keys stored in <a
275 href="manpage.d/ipsec.conf.5.html">ipsec.conf</a>.</dd>
276 <dt><a href="glossary.html#auto">Automatically keyed</a> connections</dt>
277 <dd>use keys automatically generated by the Pluto key negotiation daemon.
278 The key negotiation protocol, <a href="glossary.html#IKE">IKE</a>, must
279 authenticate the other system. (It is vulnerable to a <a
280 href="glossary.html#middle">man-in-the-middle attack</a> if used
281 without authentication.) We currently support two authentication
284 <li>using shared secrets stored in <a
285 href="manpage.d/ipsec.secrets.5.html">ipsec.secrets</a>.</li>
286 <li>RSA <a href="glossary.html#public">public key</a> authentication,
287 with our machine's private key in <a
288 href="manpage.d/ipsec.secrets.5.html">ipsec.secrets</a>. Public
289 keys for other machines may either be placed in <a
290 href="manpage.d/ipsec.conf.5.html">ipsec.conf</a> or provided via
292 <p>A third method, using RSA keys embedded in <a
293 href="glossary.html#X509">X.509</a> certtificates, is provided by
294 user <a href="web.html#patch">patches</a>.</p>
299 <p><a href="glossary.html#manual">Manually keyed</a> connections provide
300 weaker security than <a href="glossary.html#auto">automatically keyed</a>
301 connections. An opponent who reads ipsec.secrets(5) gets your encryption key
302 and can read all data encrypted by it. If he or she has an archive of old
303 messages, all of them back to your last key change are also readable.</p>
305 <p>With automatically-(re)-keyed connections, an opponent who reads
306 ipsec.secrets(5) gets the key used to authenticate your system in IKE -- the
307 shared secret or your private key, depending what authentication mechanism is
308 in use. However, he or she does not automatically gain access to any
309 encryption keys or any data.</p>
311 <p>An attacker who has your authentication key can mount a <a
312 href="glossary.html#middle">man-in-the-middle attack</a> and, if that
313 succeeds, he or she will get encryption keys and data. This is a serious
314 danger, but it is better than having the attacker read everyting as soon as
315 he or she breaks into ipsec.secrets(5).. Moreover, the keys change often so
316 an opponent who gets one key does not get a large amount of data. To read all
317 your data, he or she would have to do a man-in-the-middle attack at every key
320 <p>We discuss using <a href="#prodman">manual keying in production</a> below,
321 but this is <strong>not recommended</strong> except in special circumstances,
322 such as needing to communicate with some implementation that offers no
323 auto-keyed mode compatible with FreeS/WAN.</p>
325 <p>Manual keying may also be useful for testing. There is some discussion of
326 this in our <a href="faq.html#man4debug">FAQ</a>.</p>
328 <h3><a name="auto-auth">Authentication methods for auto-keying</a></h3>
330 <p>The IKE protocol which Pluto uses to negotiate connections between
331 gateways must use some form of authentication of peers. A gateway must know
332 who it is talking to before it can create a secure connection. We support two
333 basic methods for this authentication:</p>
335 <li>shared secrets, stored in <a
336 href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a></li>
337 <li>RSA authentication</li>
340 <p>There are, howver, several variations on the RSA theme, using different
341 methods of managing the RSA keys:</p>
343 <li>our RSA private key in <a
344 href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a> with other
345 gateways' public keys
349 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a></dd>
351 <dd>looked up via <a href="glossary.html#DNS">DNS</a></dd>
354 <li>authentication with <a href="glossary.html#x509">x.509</a>
355 certificates.; See our <a href="web.html#patch">links section</a> for
356 information on user-contributed patches for this.:</li>
359 <p>Public keys in <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5</a>)
360 give a reasonably straightforward method of specifying keys for explicitly
361 configured connections.</p>
363 <p>Putting public keys in DNS allows us to support <a
364 href="glossary.html#carpediem">opportunistic encryption</a>. Any two
365 FreeS/WAN gateways can provide secure communication, without either of them
366 having any preset information about the other.</p>
368 <p>X.509 certificates may be required to interface to various <a
369 href="glossary.html#PKI">PKI</a>s.</p>
371 <h3><a name="adv-pk">Advantages of public key methods</a></h3>
373 <p>Authentication with a <a href="glossary.html#public">public key</a> method
374 such as <a href="glossary.html#RSA">RSA</a> has some important advantages
375 over using shared secrets.</p>
377 <li>no problem of secure transmission of secrets
379 <li>A shared secret must be shared, so you have the problem of
380 transmitting it securely to the other party. If you get this wrong,
381 you have no security.</li>
382 <li>With a public key technique, you transmit only your public key. The
383 system is designed to ensure that it does not matter if an enemy
384 obtains public keys. The private key never leaves your machine.</li>
387 <li>easier management
389 <li>Suppose you have 20 branch offices all connecting to one gateway at
390 head office, and all using shared secrets. Then the head office admin
391 has 20 secrets to manage. Each of them must be kept secret not only
392 from outsiders, but also from 19 of the branch office admins. The
393 branch office admins have only one secret each to manage.
394 <p>If the branch offices need to talk to each other, this becomes
395 problematic. You need another <nobr>20*19/2 = 190</nobr>secrets for
396 branch-to-branch communication, each known to exactly two branches.
397 Now all the branch admins have the headache of handling 20 keys, each
398 shared with exactly one other branch or with head office.</p>
399 <p>For larger numbers of branches, the number of connections and
400 secrets increases quadratically and managing them becomes a
401 nightmare. A 1000-gateway fully connected network needs 499,500
402 secrets, each known to exactly two players. There are ways to reduce
403 this problem, for example by introducing a central key server, but
404 these involve additional communication overheads, more administrative
405 work, and new threats that must be carefully guarded against.</p>
407 <li>With public key techniques, the <em>only</em> thing you have to
408 keep secret is your private key, and <em>you keep that secret from
410 <p>As network size increaes, the number of public keys used increases
411 linearly with the number of nodes. This still requires careful
412 administration in large applications, but is nothing like the
413 disaster of a quadratic increase. On a 1000-gateway network, you have
414 1000 private keys, each of which must be kept secure on one machine,
415 and 1000 public keys which must be distributed. This is not a trivial
416 problem, but it is manageable.</p>
420 <li>does not require fixed IP addresses
422 <li>When shared secrets are used in IPsec, the responder must be able
423 to tell which secret to use by looking at the IP address on the
424 incoming packets. When the other parties do not have a fixed IP
425 address to be identified by (for example, on nearly all dialup ISP
426 connections and many cable or ADSL links), this does not work well --
427 all must share the same secret!</li>
428 <li>When RSA authentication is in use, the initiator can identify
429 itself by name before the key must be determined. The responder then
430 checks that the message is signed with the public key corresponding
436 <p>There is also a disadvantage:</p>
438 <li>your private key is a single point of attack, extremely valuable to an
441 <li>with shared secrets, an attacker who steals your ipsec.secrets file
442 can impersonate you or try <a
443 href="glossary.html#middle">man-in-the-middle</a> attacks, but can
444 only attack connections described in that file</li>
445 <li>an attacker who steals your private key gains the chance to attack
446 not only existing connections <em>but also any future
447 connections</em> created using that key</li>
452 <p>This is partly counterbalanced by the fact that the key is never
453 transmitted and remains under your control at all times. It is likely
454 necessary, however, to take account of this in setting security policy. For
455 example, you should change gateway keys when an administrator leaves the
456 company, and should change them periodically in any case.</p>
458 <p>Overall, public key methods are <strong>more secure, more easily managed
459 and more flexible</strong>. We recommend that they be used for all
460 connections, unless there is a compelling reason to do otherwise.</p>
462 <h2><a name="prodsecrets">Using shared secrets in production</a></h2>
464 <p>Generally, public key methods are preferred for reasons given above, but
465 shared secrets can be used with no loss of security, just more work and
466 perhaps more need to take precautions.</p>
468 <p>What I call "shared secrets" are sometimes also called "pre-shared keys".
469 They are used only for for authentication, never for encryption. Calling them
470 "pre-shared keys" has confused some users into thinking they were encryption
471 keys, so I prefer to avoid the term..</p>
473 <p>If you are interoperating with another IPsec implementation, you may find
474 its documentation calling them "passphrases".</p>
476 <h3><a name="secrets">Putting secrets in ipsec.secrets(5)</a></h3>
478 <p>If shared secrets are to be used to <a
479 href="glossary.html#authentication">authenticate</a> communication for the <a
480 href="glossary.html#DH">Diffie-Hellman</a> key exchange in the <a
481 href="glossary.html#IKE">IKE</a> protocol, then those secrets must be stored
482 in <var>/etc/ipsec.secrets</var>. For details, see the <a
483 href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a> man page.</p>
485 <p>A few considerations are vital:</p>
487 <li>make the secrets long and unguessable. Since they need not be
488 remembered by humans, very long ugly strings may be used. We suggest
489 using our <a href="manpage.d/ipsec_ranbits.8.html">ipsec_ranbits(8)</a>
490 utility to generate long (128 bits or more) random strings.</li>
491 <li>transmit secrets securely. You have to share them with other systems,
492 but you lose if they are intercepted and used against you. Use <a
493 href="glossary.html#PGP">PGP</a>, <a href="glossary.html#SSH">SSH</a>,
494 hand delivery of a floppy disk which is then destroyed, or some other
495 trustworthy method to deliver them.</li>
496 <li>store secrets securely, in root-owned files with permissions
498 <li>limit sharing of secrets. Alice, Bob, Carol and Dave may all talk to
499 each other, but only Alice and Bob should know the secret for an
501 <li><strong>do not share private keys</strong>. The private key for RSA
502 authentication of your system is stored in <a
503 href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a>, but it is a
504 different class of secret from the pre-shared keys used for the "shared
505 secret" authentication. No-one but you should have the RSA private
509 <p>Each line has the IP addresses of the two gateways plus the secret. It
510 should look something like this:</p>
511 <pre> 10.0.0.1 11.0.0.1 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"</pre>
513 <p><var>PSK</var> indicates the use of a
514 <strong>p</strong>re-<strong>s</strong>hared <strong>k</strong>ey. The quotes
515 and the whitespace shown are required.</p>
517 <p>You can use any character string as your secret. For security, it should
518 be both long and extremely hard to guess. We provide a utility to generate
520 href="manpage.d/ipsec_ranbits.8.html">ipsec_ranbits(8)</a>.</p>
522 <p>You want the same secret on the two gateways used, so you create a line
523 with that secret and the two gateway IP addresses. The installation process
524 supplies an example secret, useful <em>only</em> for testing. You must change
525 it for production use.</p>
527 <h3><a name="securing.secrets">File security</a></h3>
529 <p>You must deliver this file, or the relevant part of it, to the other
530 gateway machine by some <strong>secure</strong> means. <em>Don't just FTP or
531 mail the file!</em> It is vital that the secrets in it remain secret. An
532 attacker who knew those could easily have <em>all the data on your "secure"
535 <p>This file must be owned by root and should have permissions
536 <var>rw-------</var>.</p>
538 <h3><a name="notroadshared">Shared secrets for road warriors</a></h3>
540 <p>You can use a shared secret to support a single road warrior connecting to
541 your gateway, and this is a reasonable thing to do in some circumstances.
542 Public key methods have advantages, discussed <a href="#choose">above</a>,
543 but they are not critical in this case.</p>
545 <p>To do this, the line in ipsec.secrets(5) is something like:</p>
546 <pre> 10.0.0.1 0.0.0.0 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"</pre>
547 where the <var>0.0.0.0</var> means that any IP address is acceptable.
549 <p><strong>For more than one road warrior, shared secrets are <em>not</em>
550 recommended.</strong> If shared secrets are used, then when the responder
551 needs to look up the secret, all it knows about the sender is an IP address.
552 This is fine if the sender is at a fixed IP address specified in the config
553 file. It is also fine if only one road warrior uses the wildcard
554 <var>0.0.0.0</var> address. However, if you have more than one road warrior
555 using shared secret authentication, then they must all use that wildcard and
556 therefore <strong>all road warriors using PSK autentication must use the same
557 secret</strong>. Obviously, this is insecure.</p>
559 <p><strong>For multiple road warriors, use public key
560 authentication.</strong> Each roadwarrior can then have its own identity (our
561 <var>leftid=</var> or <var>rightid=</var> parameters), its own public/private
562 key pair, and its own secure connection.</p>
564 <h2><a name="prodman">Using manual keying in production</a></h2>
566 <p>Generally, <a href="glossary.html#auto">automatic keying</a> is preferred
567 over <a href="glossary.html#manual">manual keying</a> for production use
568 because it is both easier to manage and more secure. Automatic keying frees
569 the admin from much of the burden of managing keys securely, and can provide
570 <a href="glossary.html#PFS">perfect forward secrecy</a>. This is discussed in
571 more detail <a href="#man-auto">above</a>.</p>
573 <p>However, it is possible to use manual keying in production if that is what
574 you want to do. This might be necessary, for example, in order to
575 interoperate with some device that either does not provide automatic keying
576 or provides it in some version we cannot talk to.</p>
578 <p>Note that with manual keying <strong>all security rests with the
579 keys</strong>. If an adversary acquires your keys, you've had it. He or she
580 can read everything ever sent with those keys, including old messages he or
581 she may have archived.</p>
583 <p>You need to <strong>be really paranoid about keys</strong> if you're going
584 to rely on manual keying for anything important.</p>
586 <li>keep keys in files with 600 permissions, owned by root</li>
587 <li>be extremely careful about security of your gateway systems. Anyone who
588 breaks into a gateway and gains root privileges can get all your keys and
589 read everything ever encrypted with those keys, both old messages he has
590 archived and any new ones you may send.</li>
591 <li>change keys regularly. This can be a considerable bother, (and provides
592 an excellent reason to consider automatic keying instead), but it is
593 <em>absolutely essential</em> for security. Consider a manually keyed
594 system in which you leave the same key in place for months:
596 <li>an attacker can have a very large sample of text sent with that key
597 to work with. This makes various cryptographic attacks much more
598 likely to succeed.</li>
599 <li>The chances of the key being compromised in some non-cryptographic
600 manner -- a spy finds it on a discarded notepad, someone breaks into
601 your server or your building and steals it, a staff member is bribed,
602 tricked, seduced or coerced into revealing it, etc. -- also increase
604 <li>a successful attacker can read everything ever sent with that key.
605 This makes any successful attack extremely damaging.</li>
607 It is clear that you must change keys often to have any useful security.
608 The only question is how often.</li>
609 <li>use <a href="glossary.html#PGP">PGP</a> or <a
610 href="glossary.html#SSH">SSH</a> for all key transfers</li>
611 <li>don't edit files with keys in them when someone can look over your
613 <li>worry about network security; could someone get keys by snooping
614 packets on the LAN between your X desktop and the gateway?</li>
615 <li>lock up your backup tapes for the gateway system</li>
616 <li>... and so on</li>
619 <p>Linux FreeS/WAN provides some facilities to help with this. In particular,
620 it is good policy to <strong>keep keys in separate files</strong> so you can
621 edit configuration information in /etc/ipsec.conf without exposing keys to
622 "shoulder surfers" or network snoops. We support this with the
623 <var>also=</var> and <var>include</var> syntax in <a
624 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p>
626 <p>See the last example in our <a href="examples">examples</a> file. In the
627 /etc/ipsec.conf <var>conn samplesep</var> section, it has the line:</p>
628 <pre> also=samplesep-keys</pre>
630 <p>which tells the "ipsec manual" script to insert the configuration
631 description labelled "samplesep-keys" if it can find it. The /etc/ipsec.conf
632 file must also have a line such as:</p>
633 <pre>include ipsec.*.conf</pre>
635 <p>which tells it to read other files. One of those other files then might
636 contain the additional data:</p>
637 <pre>conn samplesep-keys
640 espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
641 espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf</pre>
643 <p>The first line matches the label in the "also=" line, so the indented
644 lines are inserted. The net effect is exactly as if the inserted lines had
645 occurred in the original file in place of the "also=" line.</p>
647 <p>Variables set here are:</p>
650 <dd>A number needed by the manual keying code. Any 3-digit hex number
651 will do, but if you have more than one manual connection then
652 <strong>spi must be different</strong> for each connection.</dd>
654 <dd>Options for <a href="glossary.html#ESP">ESP</a> (Encapsulated
655 Security Payload), the usual IPsec encryption mode. Settings here are
656 for <a href="glossary.html#encryption">encryption</a> using <a
657 href="glossary.html#3DES">triple DES</a> and <a
658 href="glossary.html#authentication">authentication</a> using <a
659 href="glossary.html#MD5">MD5</a>. Note that encryption without
660 authentication should not be used; it is insecure.</dd>
662 <dd>Key for ESP encryption. Here, a 192-bit hex number for triple
665 <dd>Key for ESP authentication. Here, a 128-bit hex number for MD5.</dd>
668 <p><strong>Note</strong> that the <strong>example keys we supply</strong> are
669 intended <strong>only for testing</strong>. For real use, you should go to
670 automatic keying. If that is not possible, create your own keys for manual
671 mode and keep them secret</p>
673 <p>Of course, any files containing keys <strong>must</strong> have 600
674 permissions and be owned by root.</p>
676 <p>If you connect in this way to multiple sites, we recommend that you keep
677 keys for each site in a separate file and adopt some naming convention that
678 lets you pick them all up with a single "include" line. This minimizes the
679 risk of losing several keys to one error or attack and of accidentally giving
680 another site admin keys which he or she has no business knowing.</p>
682 <p>Also note that if you have multiple manually keyed connections on a single
683 machine, then the <var>spi</var> parameter must be different for each one.
684 Any 3-digit hex number is OK, provided they are different for each
685 connection. We reserve the range 0x100 to 0xfff for manual connections. Pluto
686 assigns SPIs from 0x1000 up for automatically keyed connections.</p>
688 <p>If <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> contains keys
689 for manual mode connections, then it too must have permissions
690 <var>rw-------</var>. We recommend instead that, if you must manual keying in
691 production, you keep the keys in separate files.</p>
693 <p>Note also that <a href="manpage.d/ipsec.conf.5.html">ipsec.conf</a> is
694 installed with permissions <var>rw-r--r--</var>. If you plan to use manually
695 keyed connections for anything more than initial testing, you <b>must</b>:</p>
697 <li>either change permissions to <var>rw-------</var></li>
698 <li>or store keys separately in secure files and access them via include
699 statements in <a href="manpage.d/ipsec.conf.5.html">ipsec.conf</a>.</li>
702 <p>We recommend the latter method for all but the simplest configurations.</p>
704 <h3><a name="ranbits">Creating keys with ranbits</a></h3>
706 <p>You can create new <a href="glossary.html#random">random</a> keys with the
707 <a href="manpage.d/ipsec_ranbits.8.html">ranbits(8)</a> utility. For example,
710 ipsec ranbits 192 > temp
711 ipsec ranbits 128 >> temp</pre>
713 <p>create keys in the sizes needed for our default algorithms:</p>
715 <li>192-bit key for <a href="glossary.html#3DES">3DES</a> encryption <br>
716 (only 168 bits are used; parity bits are ignored)</li>
717 <li>128-bit key for keyed <a href="glossary.html#MD5">MD5</a>
721 <p>If you want to use <a href="glossary.html#SHA">SHA</a> instead of <a
722 href="glossary.html#MD5">MD5</a>, that requires a 160-bit key</p>
724 <p>Note that any <strong>temporary files</strong> used must be kept
725 <strong>secure</strong> since they contain keys. That is the reason for the
726 umask command above. The temporary file should be deleted as soon as you are
727 done with it. You may also want to change the umask back to its default value
728 after you are finished working on keys.</p>
730 <p>The ranbits utility may pause for a few seconds if not enough entropy is
731 available immediately. See ipsec_ranbits(8) and random(4) for details. You
732 may wish to provide some activity to feed entropy into the system. For
733 example, you might move the mouse around, type random characters, or do
734 <var>du /usr > /dev/null</var> in the background.</p>
736 <h2><a name="boot">Setting up connections at boot time</a></h2>
738 <p>You can tell the system to set up connections automatically at boot time
739 by putting suitable stuff in /etc/ipsec.conf on both systems. The relevant
740 section of the file is labelled by a line reading <var>config setup</var>.</p>
742 <p>Details can be found in the <a
743 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> man page. We also
744 provide a file of <a href="examples">example configurations</a>.</p>
746 <p>The most likely options are something like:</p>
748 <dt>interfaces="ipsec0=eth0 ipsec1=ppp0"</dt>
749 <dd>Tells KLIPS which interfaces to use. Up to four interfaces numbered
750 ipsec[0-3] are supported. Each interface can support an arbitrary
752 <p>Note that for PPP, you give the ppp[0-9] device name here, not the
753 underlying device such as modem (or eth1 if you are using PPPoE).</p>
755 <dt>interfaces=%defaultroute</dt>
756 <dd>Alternative setting, useful in simple cases. KLIPS will pick up both
757 its interface and the next hop information from the settings of the
758 Linux default route.</dd>
759 <dt>forwardcontrol=no</dt>
760 <dd>Normally "no". Set to "yes" if the IP forwarding option is disabled
761 in your network configuration. (This can be set as a kernel
762 configuration option or later. e.g. on Redhat, it's in
763 /etc/sysconfig/network and on SuSE you can adjust it with Yast.) Linux
764 FreeS/WAN will then enable forwarding when starting up and turn it off
765 when going down. This is used to ensure that no packets will be
766 forwarded before IPsec comes up and takes control.</dd>
767 <dt>syslog=daemon.error</dt>
768 <dd>Used in messages to the system logging daemon (syslogd) to specify
769 what type of software is sending the messages. If the settings are
770 "daemon.error" as in our example, then syslogd treats the messages as
771 error messages from a daemon.
772 <p>Note that <a href="glossary.html#Pluto">Pluto</a> does not currently
773 pay attention to this variable. The variable controls setup messages
777 <dd>Debug settings for <a href="glossary.html#KLIPS">KLIPS</a>.</dd>
779 <dd>Debug settings for <a href="glossary.html#Pluto">Pluto</a>.</dd>
780 <dt>... for both the above DEBUG settings</dt>
781 <dd>Normally, leave empty as shown above for no debugging output.<br>
782 Use "all" for maximum information.<br>
783 See ipsec_klipsdebug(8) and ipsec_pluto(8) man page for other options.
784 Beware that if you set /etc/ipsec.conf to enable debug output, your
785 system's log files may get large quickly.</dd>
786 <dt>dumpdir=/safe/directory</dt>
787 <dd>Normally, programs started by ipsec setup don't crash. If they do, by
788 default, no core dump will be produced because such dumps would contain
789 secrets. If you find you need to debug such crashes, you can set
790 dumpdir to the name of a directory in which to collect the core
792 <dt>manualstart=</dt>
793 <dd>List of manually keyed connections to be automatically started at
794 boot time. Useful for testing, but not for long term use. Connections
795 which are automatically started should also be automatically
798 <dd>Whether to start <a href="glossary.html#Pluto">Pluto</a> when ipsec
800 This parameter is optional and defaults to "yes" if not present.
801 <p>"yes" is strongly recommended for production use so that the keying
802 daemon (Pluto) will automatically re-key the connections regularly. The
803 ipsec-auto parameters ikelifetime, ipseclifetime and reykeywindow give
804 you control over frequency of rekeying.</p>
806 <dt>plutoload="reno-van reno-adam reno-nyc"</dt>
807 <dd>List of tunnels (by name, e.g. fred-susan or reno-van in our
808 examples) to be loaded into Pluto's internal database at startup. In
809 this example, Pluto loads three tunnels into its database when it is
811 <p>If plutoload is "%search", Pluto will load any connections whose
812 description includes "auto=add" or "auto=start".</p>
814 <dt>plutostart="reno-van reno-adam reno-nyc"</dt>
815 <dd>List of tunnels to attempt to negotiate when Pluto is started.
816 <p>If plutostart is "%search", Pluto will start any connections whose
817 description includes "auto=start".</p>
818 <p>Note that, for a connection intended to be permanent, <strong>both
819 gateways should be set try to start</strong> the tunnel. This allows
820 quick recovery if either gateway is rebooted or has its IPsec
821 restarted. If only one gateway is set to start the tunnel and the other
822 gateway restarts, the tunnel may not be rebuilt.</p>
824 <dt>plutowait=no</dt>
825 <dd>Controls whether Pluto waits for one tunnel to be established before
826 starting to negotiate the next. You might set this to "yes"
828 <li>if your gateway is a very limited machine and you need to
829 conserve resources.</li>
830 <li>for debugging; the logs are clearer if only one connection is
831 brought up at a time</li>
833 For a busy and resource-laden production gateway, you likely want "no"
834 so that connections are brought up in parallel and the whole process
835 takes less time.</dd>
838 <p>The example assumes you are at the Reno office and will use IPsec to
839 Vancouver, New York City and Amsterdam.</p>
841 <h2><a name="multitunnel">Multiple tunnels between the same two
844 <p>Consider a pair of subnets, each with a security gateway, connected via
846 <pre> 192.168.100.0/24 left subnet
852 101.101.101.1 left next hop
854 202.202.202.1 right next hop
856 202.202.202.202 right
860 192.168.200.0/24 right subnet</pre>
862 <p>A tunnel specification such as:</p>
863 <pre>conn northnet-southnet
865 leftnexthop=101.101.101.1
866 leftsubnet=192.168.100.0/24
868 right=202.202.202.202
869 rightnexthop=202.202.202.1
870 rightsubnet=192.168.200.0/24
871 rightfirewall=yes</pre>
872 will allow machines on the two subnets to talk to each other. You might test
873 this by pinging from polarbear (192.168.100.7) to penguin (192.168.200.5).
875 <p>However, <strong>this does not cover other traffic you might want to
876 secure</strong>. To handle all the possibilities, you might also want these
877 connection descriptions:</p>
878 <pre>conn northgate-southnet
880 leftnexthop=101.101.101.1
881 right=202.202.202.202
882 rightnexthop=202.202.202.1
883 rightsubnet=192.168.200.0/24
886 conn northnet-southgate
888 leftnexthop=101.101.101.1
889 leftsubnet=192.168.100.0/24
891 right=202.202.202.202
892 rightnexthop=202.202.202.1</pre>
894 <p>Without these, neither gateway can do IPsec to the remote subnet. There is
895 no IPsec tunnel or eroute set up for the traffic.</p>
897 <p>In our example, with the non-routable 192.168.* addresses used, packets
898 would simply be discarded. In a different configuration, with routable
899 addresses for the remote subnet, <strong>they would be sent
900 unencrypted</strong> since there would be no IPsec eroute and there would be
901 a normal IP route.</p>
903 <p>You might also want:</p>
904 <pre>conn northgate-southgate
906 leftnexthop=101.101.101.1
907 right=202.202.202.202
908 rightnexthop=202.202.202.1</pre>
910 <p>This is required if you want the two gateways to speak IPsec to each
913 <p>This requires a lot of duplication of details. Judicious use of
914 <var>also=</var> and <var>include</var> can reduce this problem.</p>
916 <p>Note that, while FreeS/WAN supports all four tunnel types, not all
917 implementations do. In particular, some versions of Windows 2000 and the
918 freely downloadable version of PGP provide only "client" functionality. You
919 cannot use them as gateways with a subnet behind them. To get that
920 functionality, you must upgrade to Windows 2000 server or the commercially
921 available PGP products.</p>
923 <h3><a name="advroute">One tunnel plus advanced routing</a></h3>
924 It is also possible to use the new routing features in 2.2 and later kernels
925 to avoid most needs for multple tunnels. Here is one mailing list message on
927 <pre>Subject: Re: linux-ipsec: IPSec packets not entering tunnel?
928 Date: Mon, 20 Nov 2000
929 From: Justin Guyett <jfg@sonicity.com>
931 On Mon, 20 Nov 2000, Claudia Schmeing wrote:
935 > 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24
937 > I've created all four tunnels, and can ping to test each of them,
938 > *except* homegate-officenet.
940 I keep wondering why people create all four tunnels. Why not route
941 traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
942 And 99% of the time you don't need to access "office" directly, which
943 means you can eliminate all but the subnet<->subnet connection.</pre>
944 and FreeS/WAN technical lead Henry Spencer's comment:
945 <pre>> I keep wondering why people create all four tunnels. Why not route
946 > traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
948 This is feasible, given some iproute2 attention to source addresses, but
949 it isn't something we've documented yet... (partly because we're still
950 making some attempt to support 2.0.xx kernels, which can't do this, but
951 mostly because we haven't caught up with it yet).
953 > And 99% of the time you don't need to access "office" directly, which
954 > means you can eliminate all but the subnet<->subnet connection.
956 Correct in principle, but people will keep trying to ping to or from the
957 gateways during testing, and sometimes they want to run services on the
958 gateway machines too.</pre>
960 <h2><a name="extruded.config">Extruded Subnets</a></h2>
962 <p>What we call <a href="glossary.html#extruded">extruded subnets</a> are a
963 special case of <a href="glossary.html#VPN.gloss">VPNs</a>.</p>
965 <p>If your buddy has some unused IP addresses, in his subnet far off at the
966 other side of the Internet, he can loan them to you... provided that the
967 connection between you and him is fast enough to carry all the traffic
968 between your machines and the rest of the Internet. In effect, he "extrudes"
969 a part of his address space over the network to you, with your Internet
970 traffic appearing to originate from behind his Internet gateway.</p>
972 <p>Suppose your friend has a.b.c.0/24 and wants to give you a.b.c.240/28. The
973 initial situation is:</p>
974 <pre> subnet gateway Internet
975 a.b.c.0/24 a.b.c.1 p.q.r.s</pre>
976 where anything from the Internet destined for any machine in a.b.c.0/24 is
977 routed via p.q.r.s and that gateway knows what to do from there.
979 <p>Of course it is quite normal for various smaller subnets to exist behind
980 your friend's gateway. For example, your friend's company might have
981 a.b.c.16/28=development, a.b.c.32/28=marketing and so on. The Internet
982 neither knows not cares about this; it just delivers packets to the p.q.r.s
983 and lets the gateway do whatever needs to be done from there.</p>
985 <p>What we want to do is take a subnet, perhaps a.b.c.240/28, out of your
986 friend's physical location <em>while still having your friend's gateway route
987 to it</em>. As far as the Internet is concerned, you remain behind that
989 <pre> subnet gateway Internet your gate extruded
991 a.b.c.0/24 a.b.c.1 p.q.r.s d.e.f.g a.b.c.240/28
993 ========== tunnel ==========</pre>
995 <p>The extruded addresses have to be a complete subnet.</p>
997 <p>In our example, the friend's security gateway is also his Internet
998 gateway, but this is not necessary. As long as all traffic from the Internet
999 to his addresses passes through the Internet gate, the security gate could be
1000 a machine behind that. The IG would need to route all traffic for the
1001 extruded subnet to the SG, and the SG could handle the rest.</p>
1003 <p>First, configure your subnet using the extruded addresses. Your security
1004 gateway's interface to your subnet needs to have an extruded address
1005 (possibly using a Linux <a href="glossary.html#virtual">virtual
1006 interface</a>, if it also has to have a different address). Your gateway
1007 needs to have a route to the extruded subnet, pointing to that interface. The
1008 other machines at your site need to have addresses in that subnet, and
1009 default routes pointing to your gateway.</p>
1011 <p>If any of your friend's machines need to talk to the extruded subnet,
1012 <em>they</em> need to have a route for the extruded subnet, pointing at his
1015 <p>Then set up an IPsec subnet-to-subnet tunnel between your gateway and his,
1016 with your subnet specified as the extruded subnet, and his subnet specified
1017 as "0.0.0.0/0". Do it with manual keying first for testing, and then with
1018 automatic keying for production use.</p>
1020 <p>The tunnel description should be:</p>
1023 leftsubnet=0.0.0.0/0
1025 rightsubnet=a.b.c.0/28</pre>
1027 <p>If either side was doing firewalling for the extruded subnet before the
1028 IPsec connection is set up, ipsec_manual and ipsec_auto need to know about
1029 that (via the {left|right}firewall parameters) so that it can be overridden
1030 for the duration of the connection.</p>
1032 <p>And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that is,
1033 the whole Internet -- through the tunnel to his SG, which then sends it
1034 onward as if it came from his subnet. When traffic for the extruded subnet
1035 arrives at his SG, it gets sent through the tunnel to your SG, which passes
1036 it to the right machine.</p>
1038 <p>Remember that when ipsec_manual or ipsec_auto takes a connection down, it
1039 <em>does not undo the route</em> it made for that connection. This lets you
1040 take a connection down and bring up a new one, or a modified version of the
1041 old one, without having to rebuild the route it uses and without any risk of
1042 packets which should use IPsec accidentally going out in the clear. Because
1043 the route always points into KLIPS, the packets will always go there. Because
1044 KLIPS temporarily has no idea what to do with them (no eroute for them), they
1045 will be discarded.</p>
1047 <p>If you <em>do</em> want to take the route down, this is what the "unroute"
1048 operation in manual and auto is for. Just do an unroute after doing the
1051 <p>Note that the route for a connection may have replaced an existing
1052 non-IPsec route. Nothing in Linux FreeS/WAN will put that pre-IPsec route
1053 back. If you need it back, you have to create it with the route command.</p>
1055 <h2><a name="roadvirt">Road Warrior with virtual IP address</a></h2>
1057 <p>Here is a mailing list message about another way to configure for road
1058 warrior support:</p>
1059 <pre>Subject: Re: linux-ipsec: understanding the vpn
1060 Date: Thu, 28 Oct 1999 10:43:22 -0400
1061 From: Irving Reid <irving@nevex.com>
1063 > local-------linux------internet------mobile
1067 > now when the mobile user connects to the linux box
1068 > it is given a virtual IP address, i have configured it to
1069 > be in the 10.x.x.x range. mobile user and linux box
1070 > have a tunnel between them with these IP addresses.
1072 > Uptil this all is fine.
1074 If it is possible to configure your mobile client software *not* to
1075 use a virtual IP address, that will make your life easier. It is easier
1076 to configure FreeS/WAN to use the actual address the mobile user gets
1079 Unfortunately, some Windows clients don't let you choose.
1081 > what i would like to know is that how does the mobile
1082 > user communicate with other computers on the local
1083 > LAN , of course with the vpn ?
1085 > what IP address should the local LAN
1086 > computers have ? I guess their default gateway
1087 > should be the linux box ? and does the linux box need
1088 > to be a 2 NIC card box or one is fine.
1090 As someone else stated, yes, the Linux box would usually be the default
1091 IP gateway for the local lan.
1095 If you mobile user has software that *must* use a virtual IP address,
1096 the whole picture changes. Nobody has put much effort into getting
1097 FreeS/WAN to play well in this environment, but here's a sketch of one
1100 Local Lan 1.0.0.0/24
1102 +- Linux FreeS/WAN 1.0.0.2
1112 Virtual Address: 1.0.0.3
1114 Note that the Local Lan network (1.0.0.x) can be registered, routable
1117 Now, the Mobile User sets up an IPSec security association with the
1118 Linux box (1.0.0.2); it should ESP encapsulate all traffic to the
1119 network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key
1120 negotiation, which needs to work outside of the IPSec tunnel.
1122 On the Linux side, there's a bunch of stuff you need to do by hand (for
1123 now). FreeS/WAN should correctly handle setting up the IPSec SA and
1124 routes, but I haven't tested it so this may not work...
1126 The FreeS/WAN conn should look like:
1130 rightsubnet=1.0.0.0/24
1131 rightnexthop=1.0.0.1
1132 left=0.0.0.0 # The infamous "road warrior"
1133 leftsubnet=1.0.0.3/32
1135 Note that the left subnet contains *only* the remote host's virtual
1138 Hopefully the routing table on the FreeS/WAN box ends up looking like
1142 Kernel IP routing table
1143 Destination Gateway Genmask Flags MSS Window irtt Iface
1144 1.0.0.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0
1145 127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo
1146 0.0.0.0 1.0.0.1 0.0.0.0 UG 1500 0 0 eth0
1147 1.0.0.3 1.0.0.1 255.255.255.255 UG 1433 0 0 ipsec0
1149 So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should
1150 get bundled up and sent through the tunnel. To get the packets for
1151 1.0.0.3 to the Linux box in the first place, you need to use "proxy
1154 How this works is: when a host or router on the local Ethernet segment
1155 wants to send a packet to 1.0.0.3, it sends out an Ethernet level
1156 broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would
1157 reply, saying "send IP packets for 1.0.0.3 to my Ethernet address".
1159 Instead, you need to set up the Linux box so that _it_ answers ARP
1160 requests for 1.0.0.3, even though that isn't its IP address. That
1161 convinces everyone else on the lan to send 1.0.0.3 packets to the Linux
1162 box, where the usual FreeS/WAN processing and routing take over.
1164 % arp -i eth0 -s 1.0.0.3 -D eth0 pub
1166 This says, if you see an ARP request on interface eth0 asking for
1167 1.0.0.3, respond with the Ethernet address of interface eth0.
1169 Now, as I said at the very beginning, if it is *at all* possible to
1170 configure your client *not* to use the virtual IP address, you can avoid
1171 this whole mess.</pre>
1173 <h2><a name="dynamic">Dynamic Network Interfaces</a></h2>
1175 <p>Sometimes you have to cope with a situation where the network interface(s)
1176 aren't all there at boot. The common example is notebooks with PCMCIA.</p>
1178 <h3><a name="basicdyn">Basics</a></h3>
1180 <p>The key issue here is that the <var>config setup</var> section of the
1181 <var>/etc/ipsec.conf</var> configuration file lists the connection between
1182 ipsecN and hardware interfaces, in the <var>interfaces=</var> variable. At
1183 any time when <var>ipsec setup start</var> or <var>ipsec setup restart</var>
1184 is run this variable <strong>must</strong> correspond to the current real
1185 situation. More precisely, it <strong>must not</strong> mention any hardware
1186 interfaces which don't currently exist. The difficulty is that an <var>ipsec
1187 setup start</var> command is normally run at boot time so interfaces that are
1188 not up then are mis-handled.</p>
1190 <h3><a name="bootdyn">Boot Time</a></h3>
1192 <p>Normally, an <var>ipsec setup start</var> is run at boot time. However, if
1193 the hardware situation at boot time is uncertain, one of two things must be
1196 <li>One possibility is simply not to have IPsec brought up at boot time. To
1198 <pre> chkconfig --level 2345 ipsec off</pre>
1199 That's for modern Red Hats or other Linuxes with chkconfig. Systems which
1200 lack this will require fiddling with symlinks in /etc/rc.d/rc?.d or the
1202 <li>Another possibility is to bring IPsec up with no interfaces, which is
1203 less aesthetically satisfying but simpler. Just put
1204 <pre> interfaces=</pre>
1205 in the configuration file. KLIPS and Pluto will be started, but won't do
1209 <h3><a name="changedyn">Change Time</a></h3>
1211 <p>When the hardware *is* in place, IPsec has to be made aware of it. Someday
1212 there may be a nice way to do this.</p>
1214 <p>Right now, the way to do it is to fix the <var>/etc/ipsec.conf</var> file
1215 appropriately, so <var>interfaces</var> reflects the new situation, and then
1216 restart the IPsec subsystem. This does break any existing IPsec
1219 <p>If IPsec wasn't brought up at boot time, do</p>
1220 <pre> ipsec setup start</pre>
1222 <pre> ipsec setup restart</pre>
1223 which won't be as quick.
1225 <p>If some of the hardware is to be taken out, before doing that, amend the
1226 configuration file so interfaces no longer includes it, and do</p>
1227 <pre> ipsec setup restart</pre>
1229 <p>Again, this breaks any existing connections.</p>
1231 <h2><a name="unencrypted">Unencrypted tunnels</a></h2>
1233 <p>Sometimes you might want to create a tunnel without encryption. Often this
1234 is a bad idea, even if you have some data which need not be private. See this
1235 <a href="ipsec.html#traffic.resist">discussion</a>.</p>
1237 <p>The IPsec protocols provide two ways to do build such tunnels:</p>
1239 <dt>using ESP with null encryption</dt>
1240 <dd>not supported by FreeS/WAN</dd>
1241 <dt>using <a href="glossary.html#AH">AH</a> without <a
1242 href="glossary.html#ESP">ESP</a></dt>
1243 <dd>supported for manually keyed connections</dd>
1244 <dd>possible with explicit commands via <a
1245 href="manpage.d/ipsec_whack.8.html">ipsec_whack(8)</a> (see this <a
1246 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00190.html">list
1248 <dd>not supported in the <a
1249 href="manpage.d/ipsec_auto.8.html">ipsec_auto(8)</a> scripts.</dd>
1251 One situation in which this comes up is when otherwise some data would be
1252 encrypted twice. Alice wants a secure tunnel from her machine to Bob's. Since
1253 she's behind one security gateway and he's behind another, part of the tunnel
1254 that they build passes through the tunnel that their site admins have built
1255 between the gateways. All of Alice and Bob's messages are encrypted twice.
1257 <p>There are several ways to handle this.</p>
1259 <li>Just accept the overhead of double encryption. The site admins might
1260 choose this if any of the following apply:
1262 <li>policy says encrypt everything (usually, it should)</li>
1263 <li>they don't entirely trust Alice and Bob (usually, if they don't
1264 have to, they shouldn't)</li>
1265 <li>if they don't feel the saved cycles are worth the time they'd need
1266 to build a non-encrypted tunnel for Alice and Bob's packets (often,
1270 <li>Use a plain IP-in-IP tunnel. These are not well documented. A good
1271 starting point is in the Linux kernel source tree, in
1272 /usr/src/linux/drivers/net/README.tunnel.</li>
1273 <li>Use a manually-keyed AH-only tunnel.</li>
1276 <p>Note that if Alice and Bob want end-to-end security, they must build a
1277 tunnel end-to-end between their machines or use some other end-to-end tool
1278 such as PGP or SSL that suits their data. The only question is whether the
1279 admins build some special unencrypted tunnel for those already-encrypted
OSDN Git Service
