summaryrefslogtreecommitdiff
path: root/doc/src/adv_config.html
diff options
context:
space:
mode:
Diffstat (limited to 'doc/src/adv_config.html')
-rw-r--r--doc/src/adv_config.html1412
1 files changed, 1412 insertions, 0 deletions
diff --git a/doc/src/adv_config.html b/doc/src/adv_config.html
new file mode 100644
index 000000000..ab6901b5e
--- /dev/null
+++ b/doc/src/adv_config.html
@@ -0,0 +1,1412 @@
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html">
+ <title>Advanced FreeS/WAN configuration</title>
+ <meta name="keywords"
+ content="Linux, IPsec, VPN, security, FreeSWAN, configuration">
+ <!--
+
+ Written by Sandy Harris for the Linux FreeS/WAN project
+ Maintained by Claudia Schmeing for same.
+ Freely distributable under the GNU General Public License
+
+ More information at www.freeswan.org
+ Feedback to users@lists.freeswan.org
+
+ CVS information:
+ RCS ID: $Id: adv_config.html,v 1.1 2004/03/15 20:35:24 as Exp $
+ Last changed: $Date: 2004/03/15 20:35:24 $
+ Revision number: $Revision: 1.1 $
+
+ CVS revision numbers do not correspond to FreeS/WAN release numbers.
+ -->
+</head>
+
+<body>
+<h1><a name="adv_config">Other configuration possibilities</a></h1>
+
+<p>This document describes various options for FreeS/WAN configuration which
+are less used or more complex (often both) than the standard cases described
+in our <a href="config.html#config">config</a> and
+<a href="quickstart.html#quick_guide">quickstart</a> documents.</p>
+
+<h2><a name="thumb">Some rules of thumb about configuration</a></h2>
+
+<h3><a name="cheap.tunnel">Tunnels are cheap</a></h3>
+
+<p>Nearly all of the overhead in IPsec processing is in the encryption and
+authentication of packets. Our <a href="performance.html">performance</a>
+document discusses these overheads.</p>
+
+<p>Beside those overheads, the cost of managing additional tunnels is
+trivial. Whether your gateway supports one tunnel or ten just does not
+matter. A hundred might be a problem; there is a <a
+href="performance.html#biggate">section</a> on this in the performance
+document.</p>
+
+<p>So, in nearly all cases, if using multiple tunnels gives you a reasonable
+way to describe what you need to do, you should describe it that way in your
+configuration files.</p>
+
+<p>For example, one user recently asked on a mailing list about this network
+configuration:</p>
+<pre> netA---gwA---gwB---netB
+ |----netC
+
+ netA and B are secured netC not.
+ netA and gwA can not access netC</pre>
+
+<p>The user had constructed only one tunnel, netA to netB, and wanted to know
+how to use ip-route to get netC packets into it. This is entirely
+unnecessary. One of the replies was:</p>
+<pre> The simplest way and indeed the right way to
+ solve this problem is to set up two connections:
+
+ leftsubnet=NetA
+ left=gwA
+ right=gwB
+ rightsubnet=NetB
+ and
+ leftsubnet=NetA
+ left=gwA
+ right=gwB
+ rightsubnet=NetC</pre>
+
+<p>This would still be correct even if we added nets D, E, F,
+... to the above diagram and needed twenty tunnels.</p>
+
+<p>Of course another possibility would be to just use one tunnel, with a
+subnet mask that includes both netB and netC (or B, C, D, ...). See next
+section.</p>
+
+<p>In general, you can construct as many tunnels as you need. Networks like
+netC in this example that do not connect directly to the gateway are fine, as
+long as the gateway can route to them.</p>
+
+<p>The number of tunnels can become an issue if it reaches 50 or so. This is
+discussed in the <a href="performance.html#biggate">performance</a> document.
+Look there for information on supporting hundreds of Road Warriors from one
+gateway.</p>
+
+<p>If you find yourself with too many tunnels for some reason like having
+eight subnets at one location and nine at another so you end up with
+9*8=72 tunnels, read the next section here.</p>
+
+<h3><a name="subnet.size">Subnet sizes</a></h3>
+
+<p>The subnets used in <var>leftsubnet</var> and <var>rightsubnet</var> can
+be of any size that fits your needs, and they need not correspond to physical
+networks.</p>
+
+<p>You adjust the size by changing the <a href="glossary.html#subnet">subnet
+mask</a>, the number after the slash in the subnet description. For
+example</p>
+<ul>
+ <li>in 192.168.100.0/24 the /24 mask says 24 bits are used to designate the
+ network. This leave 8 bits to label machines. This subnet has 256
+ addresses. .0 and .255 are reserved, so it can have 254 machines.</li>
+ <li>A subnet with a /23 mask would be twice as large, 512 addresses.</li>
+ <li>A subnet with a /25 mask would be half the size, 128 addresses.</li>
+ <li>/0 is the whole Internet</li>
+ <li>/32 is a single machine</li>
+</ul>
+
+<p>As an example of using these in connection descriptions, suppose your
+company's head office has four physical networks using the address ranges:</p>
+<dl>
+ <dt>192.168.100.0/24</dt>
+ <dd>development</dd>
+ <dt>192.168.101.0/24</dt>
+ <dd>production</dd>
+ <dt>192.168.102.0/24</dt>
+ <dd>marketing</dd>
+ <dt>192.168.103.0/24</dt>
+ <dd>administration</dd>
+</dl>
+
+<p>You can use exactly those subnets in your connection descriptions, or use
+larger subnets to grant broad access if required:</p>
+<dl>
+ <dt>leftsubnet=192.168.100.0/24</dt>
+ <dd>remote hosts can access only development</dd>
+ <dt>leftsubnet=192.168.100.0/23</dt>
+ <dd>remote hosts can access development or production</dd>
+ <dt>leftsubnet=192.168.102.0/23</dt>
+ <dd>remote hosts can access marketing or administration</dd>
+ <dt>leftsubnet=192.168.100.0/22</dt>
+ <dd>remote hosts can access any of the four departments</dd>
+</dl>
+
+<p>or use smaller subnets to restrict access:</p>
+<dl>
+ <dt>leftsubnet=192.168.103.0/24</dt>
+ <dd>remote hosts can access any machine in administration</dd>
+ <dt>leftsubnet=192.168.103.64/28</dt>
+ <dd>remote hosts can access only certain machines in administration.</dd>
+ <dt>leftsubnet=192.168.103.42/32</dt>
+ <dd>remote hosts can access only one particular machine in
+ administration</dd>
+</dl>
+
+<p>To be exact, 192.68.103.64/28 means all addresses whose top 28 bits match
+192.168.103.64. There are 16 of these because there are 16 possibilities for
+the remainingg 4 bits. Their addresses are 192.168.103.64 to
+192.168.103.79.</p>
+
+<p>Each connection description can use a different subnet if required.</p>
+
+<p>It is possible to use all the examples above on the same FreeS/WAN
+gateway, each in a different connection description, perhaps for different
+classes of user or for different remote offices.</p>
+
+<p>It is also possible to have multiple tunnels using different
+<var>leftsubnet</var> descriptions with the same <var>right</var>. For
+example, when the marketing manager is on the road he or she might have
+access to:</p>
+<dl>
+ <dt>leftsubnet=192.168.102.0/24</dt>
+ <dd>all machines in marketing</dd>
+ <dt>192.168.101.32/29</dt>
+ <dd>some machines in production</dd>
+ <dt>leftsubnet=192.168.103.42/32</dt>
+ <dd>one particular machine in administration</dd>
+</dl>
+
+<p>This takes three tunnels, but tunnels are cheap. If the laptop is set up
+to build all three tunnels automatically, then he or she can access all these
+machines concurrently, perhaps from different windows.</p>
+
+<h3><a name="example.more">Other network layouts</a></h3>
+
+<p>Here is the usual network picture for a site-to-site VPN::</p>
+<pre> Sunset==========West------------------East=========Sunrise
+ local net untrusted net local net</pre>
+
+<p>and for the Road Warrior::</p>
+<pre> telecommuter's PC or
+ traveller's laptop
+ Sunset==========West------------------East
+ corporate LAN untrusted net</pre>
+
+<p>Other configurations are also possible.</p>
+
+<h4><a name="internet.subnet">The Internet as a big subnet</a></h4>
+
+<p>A telecommuter might have:</p>
+<pre> Sunset==========West------------------East ================= firewall --- the Internet
+ home network untrusted net corporate network</pre>
+
+<p>This can be described as a special case of the general subnet-to-subnet
+connection. The subnet on the right is 0.0.0.0/0, the whole Internet.</p>
+
+<p>West (the home gateway) can have its firewall rules set up so that only
+IPsec packets to East are allowed out. It will then behave as if its only
+connection to the world was a wire to East.</p>
+
+<p>When machines on the home network need to reach the Internet, they do so
+via the tunnel, East and the corporate firewall. From the viewpoint of the
+Internet (perhaps of some EvilDoer trying to break in!), those home office
+machines are behind the firewall and protected by it.</p>
+
+<h4><a name="wireless.config">Wireless</a></h4>
+
+<p>Another possible configuration comes up when you do not trust the local
+network, either because you have very high security standards or because your
+are using easily-intercepted wireless signals.</p>
+
+<p>Some wireless networks have built-in encryption called <a
+href="glossary.html#WEP">WEP</a>, but its security is dubious. It is a fairly
+common practice to use IPsec instead.</p>
+
+<p>In this case, part of your network may look like this:</p>
+<pre> West-----------------------------East == the rest of your network
+ workstation untrusted wireless net</pre>
+
+<p>Of course, there would likely be several wireless workstations, each with
+its own IPsec tunnel to the East gateway.</p>
+
+<p>The connection descriptions look much like Road Warrior descriptions:</p>
+<ul>
+ <li>each workstation should have its own unique
+ <ul>
+ <li>identifier for IPsec</li>
+ <li>RSA key</li>
+ <li>connection description.</li>
+ </ul>
+ </li>
+ <li>on the gateway, use <var>left=%any</var>, or the workstation IP
+ address</li>
+ <li>on workstations, <var>left=%defaultroute</var>, or the workstation IP
+ address</li>
+ <li><var>leftsubnet=</var> is not used.</li>
+</ul>
+
+<p>The <var>rightsubnet=</var> parameter might be set in any of several
+ways:</p>
+<dl>
+ <dt>rightsubnet=0.0.0.0/0</dt>
+ <dd>allowing workstations to access the entire Internet (see <a
+ href="#internet.subnet">above</a>)</dd>
+ <dt>rightsubnet=a.b.c.0/24</dt>
+ <dd>allowing access to your entire local network</dd>
+ <dt>rightsubnet=a.b.c.d/32</dt>
+ <dd>restricting the workstation to connecting to a particular server</dd>
+</dl>
+
+<p>Of course you can mix and match these as required. For example, a
+university might allow faculty full Internet access while letting student
+laptops connect only to a group of lab machines.</p>
+
+<h2><a name="choose">Choosing connection types</a></h2>
+
+<p>One choice you need to make before configuring additional connections is
+what type or types of connections you will use. There are several options,
+and you can use more than one concurrently.</p>
+
+<h3><a name="man-auto">Manual vs. automatic keying</a></h3>
+
+<p>IPsec allows two types of connections, with manual or automatic keying.
+FreeS/WAN starts them with commands such as:</p>
+<pre> ipsec manual --up <var>name</var>
+ ipsec auto --up <var>name</var></pre>
+
+<p>The difference is in how they are keyed.</p>
+<dl>
+ <dt><a href="glossary.html#manual">Manually keyed</a> connections</dt>
+ <dd>use keys stored in <a
+ href="manpage.d/ipsec.conf.5.html">ipsec.conf</a>.</dd>
+ <dt><a href="glossary.html#auto">Automatically keyed</a> connections</dt>
+ <dd>use keys automatically generated by the Pluto key negotiation daemon.
+ The key negotiation protocol, <a href="glossary.html#IKE">IKE</a>, must
+ authenticate the other system. (It is vulnerable to a <a
+ href="glossary.html#middle">man-in-the-middle attack</a> if used
+ without authentication.) We currently support two authentication
+ methods:
+ <ul>
+ <li>using shared secrets stored in <a
+ href="manpage.d/ipsec.secrets.5.html">ipsec.secrets</a>.</li>
+ <li>RSA <a href="glossary.html#public">public key</a> authentication,
+ with our machine's private key in <a
+ href="manpage.d/ipsec.secrets.5.html">ipsec.secrets</a>. Public
+ keys for other machines may either be placed in <a
+ href="manpage.d/ipsec.conf.5.html">ipsec.conf</a> or provided via
+ DNS.</li>
+ </ul>
+ <p>A third method, using RSA keys embedded in <a
+ href="glossary.html#X509">X.509</a> certtificates, is provided by
+ user <a href="web.html#patch">patches</a>.</p>
+ </dd>
+</dl>
+
+<p><a href="glossary.html#manual">Manually keyed</a> connections provide
+weaker security than <a href="glossary.html#auto">automatically keyed</a>
+connections. An opponent who reads ipsec.secrets(5) gets your encryption key
+and can read all data encrypted by it. If he or she has an archive of old
+messages, all of them back to your last key change are also readable.</p>
+
+<p>With automatically-(re)-keyed connections, an opponent who reads
+ipsec.secrets(5) gets the key used to authenticate your system in IKE -- the
+shared secret or your private key, depending what authentication mechanism is
+in use. However, he or she does not automatically gain access to any
+encryption keys or any data.</p>
+
+<p>An attacker who has your authentication key can mount a <a
+href="glossary.html#middle">man-in-the-middle attack</a> and, if that
+succeeds, he or she will get encryption keys and data. This is a serious
+danger, but it is better than having the attacker read everyting as soon as
+he or she breaks into ipsec.secrets(5).. Moreover, the keys change often so
+an opponent who gets one key does not get a large amount of data. To read all
+your data, he or she would have to do a man-in-the-middle attack at every key
+change.</p>
+
+<p>We discuss using <a href="#prodman">manual keying in production</a> below,
+but this is <strong>not recommended</strong> except in special circumstances,
+such as needing to communicate with some implementation that offers no
+auto-keyed mode compatible with FreeS/WAN.</p>
+
+<p>Manual keying may also be useful for testing. There is some discussion of
+this in our <a href="faq.html#man4debug">FAQ</a>.</p>
+
+<h3><a name="auto-auth">Authentication methods for auto-keying</a></h3>
+
+<p>The IKE protocol which Pluto uses to negotiate connections between
+gateways must use some form of authentication of peers. A gateway must know
+who it is talking to before it can create a secure connection. We support two
+basic methods for this authentication:</p>
+<ul>
+ <li>shared secrets, stored in <a
+ href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a></li>
+ <li>RSA authentication</li>
+</ul>
+
+<p>There are, howver, several variations on the RSA theme, using different
+methods of managing the RSA keys:</p>
+<ul>
+ <li>our RSA private key in <a
+ href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a> with other
+ gateways' public keys
+ <dl>
+ <dt>either</dt>
+ <dd>stored in <a
+ href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a></dd>
+ <dt>or</dt>
+ <dd>looked up via <a href="glossary.html#DNS">DNS</a></dd>
+ </dl>
+ </li>
+ <li>authentication with <a href="glossary.html#x509">x.509</a>
+ certificates.; See our <a href="web.html#patch">links section</a> for
+ information on user-contributed patches for this.:</li>
+</ul>
+
+<p>Public keys in <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5</a>)
+give a reasonably straightforward method of specifying keys for explicitly
+configured connections.</p>
+
+<p>Putting public keys in DNS allows us to support <a
+href="glossary.html#carpediem">opportunistic encryption</a>. Any two
+FreeS/WAN gateways can provide secure communication, without either of them
+having any preset information about the other.</p>
+
+<p>X.509 certificates may be required to interface to various <a
+href="glossary.html#PKI">PKI</a>s.</p>
+
+<h3><a name="adv-pk">Advantages of public key methods</a></h3>
+
+<p>Authentication with a <a href="glossary.html#public">public key</a> method
+such as <a href="glossary.html#RSA">RSA</a> has some important advantages
+over using shared secrets.</p>
+<ul>
+ <li>no problem of secure transmission of secrets
+ <ul>
+ <li>A shared secret must be shared, so you have the problem of
+ transmitting it securely to the other party. If you get this wrong,
+ you have no security.</li>
+ <li>With a public key technique, you transmit only your public key. The
+ system is designed to ensure that it does not matter if an enemy
+ obtains public keys. The private key never leaves your machine.</li>
+ </ul>
+ </li>
+ <li>easier management
+ <ul>
+ <li>Suppose you have 20 branch offices all connecting to one gateway at
+ head office, and all using shared secrets. Then the head office admin
+ has 20 secrets to manage. Each of them must be kept secret not only
+ from outsiders, but also from 19 of the branch office admins. The
+ branch office admins have only one secret each to manage.
+ <p>If the branch offices need to talk to each other, this becomes
+ problematic. You need another 20*19/2 = 190 secrets for
+ branch-to-branch communication, each known to exactly two branches.
+ Now all the branch admins have the headache of handling 20 keys, each
+ shared with exactly one other branch or with head office.</p>
+ <p>For larger numbers of branches, the number of connections and
+ secrets increases quadratically and managing them becomes a
+ nightmare. A 1000-gateway fully connected network needs 499,500
+ secrets, each known to exactly two players. There are ways to reduce
+ this problem, for example by introducing a central key server, but
+ these involve additional communication overheads, more administrative
+ work, and new threats that must be carefully guarded against.</p>
+ </li>
+ <li>With public key techniques, the <em>only</em> thing you have to
+ keep secret is your private key, and <em>you keep that secret from
+ everyone</em>.
+ <p>As network size increaes, the number of public keys used increases
+ linearly with the number of nodes. This still requires careful
+ administration in large applications, but is nothing like the
+ disaster of a quadratic increase. On a 1000-gateway network, you have
+ 1000 private keys, each of which must be kept secure on one machine,
+ and 1000 public keys which must be distributed. This is not a trivial
+ problem, but it is manageable.</p>
+ </li>
+ </ul>
+ </li>
+ <li>does not require fixed IP addresses
+ <ul>
+ <li>When shared secrets are used in IPsec, the responder must be able
+ to tell which secret to use by looking at the IP address on the
+ incoming packets. When the other parties do not have a fixed IP
+ address to be identified by (for example, on nearly all dialup ISP
+ connections and many cable or ADSL links), this does not work well --
+ all must share the same secret!</li>
+ <li>When RSA authentication is in use, the initiator can identify
+ itself by name before the key must be determined. The responder then
+ checks that the message is signed with the public key corresponding
+ to that name.</li>
+ </ul>
+ </li>
+</ul>
+
+<p>There is also a disadvantage:</p>
+<ul>
+ <li>your private key is a single point of attack, extremely valuable to an
+ enemy
+ <ul>
+ <li>with shared secrets, an attacker who steals your ipsec.secrets file
+ can impersonate you or try <a
+ href="glossary.html#middle">man-in-the-middle</a> attacks, but can
+ only attack connections described in that file</li>
+ <li>an attacker who steals your private key gains the chance to attack
+ not only existing connections <em>but also any future
+ connections</em> created using that key</li>
+ </ul>
+ </li>
+</ul>
+
+<p>This is partly counterbalanced by the fact that the key is never
+transmitted and remains under your control at all times. It is likely
+necessary, however, to take account of this in setting security policy. For
+example, you should change gateway keys when an administrator leaves the
+company, and should change them periodically in any case.</p>
+
+<p>Overall, public key methods are <strong>more secure, more easily managed
+and more flexible</strong>. We recommend that they be used for all
+connections, unless there is a compelling reason to do otherwise.</p>
+
+<h2><a name="prodsecrets">Using shared secrets in production</a></h2>
+
+<p>Generally, public key methods are preferred for reasons given above, but
+shared secrets can be used with no loss of security, just more work and
+perhaps more need to take precautions.</p>
+
+<p>What I call "shared secrets" are sometimes also called "pre-shared keys".
+They are used only for for authentication, never for encryption. Calling them
+"pre-shared keys" has confused some users into thinking they were encryption
+keys, so I prefer to avoid the term..</p>
+
+<p>If you are interoperating with another IPsec implementation, you may find
+its documentation calling them "passphrases".</p>
+
+<h3><a name="secrets">Putting secrets in ipsec.secrets(5)</a></h3>
+
+<p>If shared secrets are to be used to <a
+href="glossary.html#authentication">authenticate</a> communication for the <a
+href="glossary.html#DH">Diffie-Hellman</a> key exchange in the <a
+href="glossary.html#IKE">IKE</a> protocol, then those secrets must be stored
+in <var>/etc/ipsec.secrets</var>. For details, see the <a
+href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a> man page.</p>
+
+<p>A few considerations are vital:</p>
+<ul>
+ <li>make the secrets long and unguessable. Since they need not be
+ remembered by humans, very long ugly strings may be used. We suggest
+ using our <a href="manpage.d/ipsec_ranbits.8.html">ipsec_ranbits(8)</a>
+ utility to generate long (128 bits or more) random strings.</li>
+ <li>transmit secrets securely. You have to share them with other systems,
+ but you lose if they are intercepted and used against you. Use <a
+ href="glossary.html#PGP">PGP</a>, <a href="glossary.html#SSH">SSH</a>,
+ hand delivery of a floppy disk which is then destroyed, or some other
+ trustworthy method to deliver them.</li>
+ <li>store secrets securely, in root-owned files with permissions
+ rw------.</li>
+ <li>limit sharing of secrets. Alice, Bob, Carol and Dave may all talk to
+ each other, but only Alice and Bob should know the secret for an
+ Alice-Bob link.</li>
+ <li><strong>do not share private keys</strong>. The private key for RSA
+ authentication of your system is stored in <a
+ href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a>, but it is a
+ different class of secret from the pre-shared keys used for the "shared
+ secret" authentication. No-one but you should have the RSA private
+ key.</li>
+</ul>
+
+<p>Each line has the IP addresses of the two gateways plus the secret. It
+should look something like this:</p>
+<pre> 10.0.0.1 11.0.0.1 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"</pre>
+
+<p><var>PSK</var> indicates the use of a
+<strong>p</strong>re-<strong>s</strong>hared <strong>k</strong>ey. The quotes
+and the whitespace shown are required.</p>
+
+<p>You can use any character string as your secret. For security, it should
+be both long and extremely hard to guess. We provide a utility to generate
+such strings, <a
+href="manpage.d/ipsec_ranbits.8.html">ipsec_ranbits(8)</a>.</p>
+
+<p>You want the same secret on the two gateways used, so you create a line
+with that secret and the two gateway IP addresses. The installation process
+supplies an example secret, useful <em>only</em> for testing. You must change
+it for production use.</p>
+
+<h3><a name="securing.secrets">File security</a></h3>
+
+<p>You must deliver this file, or the relevant part of it, to the other
+gateway machine by some <strong>secure</strong> means. <em>Don't just FTP or
+mail the file!</em> It is vital that the secrets in it remain secret. An
+attacker who knew those could easily have <em>all the data on your "secure"
+connection</em>.</p>
+
+<p>This file must be owned by root and should have permissions
+<var>rw-------</var>.</p>
+
+<h3><a name="notroadshared">Shared secrets for road warriors</a></h3>
+
+<p>You can use a shared secret to support a single road warrior connecting to
+your gateway, and this is a reasonable thing to do in some circumstances.
+Public key methods have advantages, discussed <a href="#choose">above</a>,
+but they are not critical in this case.</p>
+
+<p>To do this, the line in ipsec.secrets(5) is something like:</p>
+<pre> 10.0.0.1 0.0.0.0 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"</pre>
+where the <var>0.0.0.0</var> means that any IP address is acceptable.
+
+<p><strong>For more than one road warrior, shared secrets are <em>not</em>
+recommended.</strong> If shared secrets are used, then when the responder
+needs to look up the secret, all it knows about the sender is an IP address.
+This is fine if the sender is at a fixed IP address specified in the config
+file. It is also fine if only one road warrior uses the wildcard
+<var>0.0.0.0</var> address. However, if you have more than one road warrior
+using shared secret authentication, then they must all use that wildcard and
+therefore <strong>all road warriors using PSK autentication must use the same
+secret</strong>. Obviously, this is insecure.</p>
+
+<p><strong>For multiple road warriors, use public key
+authentication.</strong> Each roadwarrior can then have its own identity (our
+<var>leftid=</var> or <var>rightid=</var> parameters), its own public/private
+key pair, and its own secure connection.</p>
+
+<h2><a name="prodman">Using manual keying in production</a></h2>
+
+<p>Generally, <a href="glossary.html#auto">automatic keying</a> is preferred
+over <a href="glossary.html#manual">manual keying</a> for production use
+because it is both easier to manage and more secure. Automatic keying frees
+the admin from much of the burden of managing keys securely, and can provide
+<a href="glossary.html#PFS">perfect forward secrecy</a>. This is discussed in
+more detail <a href="#man-auto">above</a>.</p>
+
+<p>However, it is possible to use manual keying in production if that is what
+you want to do. This might be necessary, for example, in order to
+interoperate with some device that either does not provide automatic keying
+or provides it in some version we cannot talk to.</p>
+
+<p>Note that with manual keying <strong>all security rests with the
+keys</strong>. If an adversary acquires your keys, you've had it. He or she
+can read everything ever sent with those keys, including old messages he or
+she may have archived.</p>
+
+<p>You need to <strong>be really paranoid about keys</strong> if you're going
+to rely on manual keying for anything important.</p>
+<ul>
+ <li>keep keys in files with 600 permissions, owned by root</li>
+ <li>be extremely careful about security of your gateway systems. Anyone who
+ breaks into a gateway and gains root privileges can get all your keys and
+ read everything ever encrypted with those keys, both old messages he has
+ archived and any new ones you may send.</li>
+ <li>change keys regularly. This can be a considerable bother, (and provides
+ an excellent reason to consider automatic keying instead), but it is
+ <em>absolutely essential</em> for security. Consider a manually keyed
+ system in which you leave the same key in place for months:
+ <ul>
+ <li>an attacker can have a very large sample of text sent with that key
+ to work with. This makes various cryptographic attacks much more
+ likely to succeed.</li>
+ <li>The chances of the key being compromised in some non-cryptographic
+ manner -- a spy finds it on a discarded notepad, someone breaks into
+ your server or your building and steals it, a staff member is bribed,
+ tricked, seduced or coerced into revealing it, etc. -- also increase
+ over time.</li>
+ <li>a successful attacker can read everything ever sent with that key.
+ This makes any successful attack extremely damaging.</li>
+ </ul>
+ It is clear that you must change keys often to have any useful security.
+ The only question is how often.</li>
+ <li>use <a href="glossary.html#PGP">PGP</a> or <a
+ href="glossary.html#SSH">SSH</a> for all key transfers</li>
+ <li>don't edit files with keys in them when someone can look over your
+ shoulder</li>
+ <li>worry about network security; could someone get keys by snooping
+ packets on the LAN between your X desktop and the gateway?</li>
+ <li>lock up your backup tapes for the gateway system</li>
+ <li>... and so on</li>
+</ul>
+
+<p>Linux FreeS/WAN provides some facilities to help with this. In particular,
+it is good policy to <strong>keep keys in separate files</strong> so you can
+edit configuration information in /etc/ipsec.conf without exposing keys to
+"shoulder surfers" or network snoops. We support this with the
+<var>also=</var> and <var>include</var> syntax in <a
+href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</p>
+
+<p>See the last example in our <a href="examples">examples</a> file. In the
+/etc/ipsec.conf <var>conn samplesep</var> section, it has the line:</p>
+<pre> also=samplesep-keys</pre>
+
+<p>which tells the "ipsec manual" script to insert the configuration
+description labelled "samplesep-keys" if it can find it. The /etc/ipsec.conf
+file must also have a line such as:</p>
+<pre>include ipsec.*.conf</pre>
+
+<p>which tells it to read other files. One of those other files then might
+contain the additional data:</p>
+<pre>conn samplesep-keys
+ spi=0x200
+ esp=3des-md5-96
+ espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
+ espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf</pre>
+
+<p>The first line matches the label in the "also=" line, so the indented
+lines are inserted. The net effect is exactly as if the inserted lines had
+occurred in the original file in place of the "also=" line.</p>
+
+<p>Variables set here are:</p>
+<dl>
+ <dt>spi</dt>
+ <dd>A number needed by the manual keying code. Any 3-digit hex number
+ will do, but if you have more than one manual connection then
+ <strong>spi must be different</strong> for each connection.</dd>
+ <dt>esp</dt>
+ <dd>Options for <a href="glossary.html#ESP">ESP</a> (Encapsulated
+ Security Payload), the usual IPsec encryption mode. Settings here are
+ for <a href="glossary.html#encryption">encryption</a> using <a
+ href="glossary.html#3DES">triple DES</a> and <a
+ href="glossary.html#authentication">authentication</a> using <a
+ href="glossary.html#MD5">MD5</a>. Note that encryption without
+ authentication should not be used; it is insecure.</dd>
+ <dt>espenkey</dt>
+ <dd>Key for ESP encryption. Here, a 192-bit hex number for triple
+ DES.</dd>
+ <dt>espauthkey</dt>
+ <dd>Key for ESP authentication. Here, a 128-bit hex number for MD5.</dd>
+</dl>
+
+<p><strong>Note</strong> that the <strong>example keys we supply</strong> are
+intended <strong>only for testing</strong>. For real use, you should go to
+automatic keying. If that is not possible, create your own keys for manual
+mode and keep them secret</p>
+
+<p>Of course, any files containing keys <strong>must</strong> have 600
+permissions and be owned by root.</p>
+
+<p>If you connect in this way to multiple sites, we recommend that you keep
+keys for each site in a separate file and adopt some naming convention that
+lets you pick them all up with a single "include" line. This minimizes the
+risk of losing several keys to one error or attack and of accidentally giving
+another site admin keys which he or she has no business knowing.</p>
+
+<p>Also note that if you have multiple manually keyed connections on a single
+machine, then the <var>spi</var> parameter must be different for each one.
+Any 3-digit hex number is OK, provided they are different for each
+connection. We reserve the range 0x100 to 0xfff for manual connections. Pluto
+assigns SPIs from 0x1000 up for automatically keyed connections.</p>
+
+<p>If <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> contains keys
+for manual mode connections, then it too must have permissions
+<var>rw-------</var>. We recommend instead that, if you must manual keying in
+production, you keep the keys in separate files.</p>
+
+<p>Note also that <a href="manpage.d/ipsec.conf.5.html">ipsec.conf</a> is
+installed with permissions <var>rw-r--r--</var>. If you plan to use manually
+keyed connections for anything more than initial testing, you <b>must</b>:</p>
+<ul>
+ <li>either change permissions to <var>rw-------</var></li>
+ <li>or store keys separately in secure files and access them via include
+ statements in <a href="manpage.d/ipsec.conf.5.html">ipsec.conf</a>.</li>
+</ul>
+
+<p>We recommend the latter method for all but the simplest configurations.</p>
+
+<h3><a name="ranbits">Creating keys with ranbits</a></h3>
+
+<p>You can create new <a href="glossary.html#random">random</a> keys with the
+<a href="manpage.d/ipsec_ranbits.8.html">ranbits(8)</a> utility. For example,
+the commands:</p>
+<pre> umask 177
+ ipsec ranbits 192 &gt; temp
+ ipsec ranbits 128 &gt;&gt; temp</pre>
+
+<p>create keys in the sizes needed for our default algorithms:</p>
+<ul>
+ <li>192-bit key for <a href="glossary.html#3DES">3DES</a> encryption <br>
+ (only 168 bits are used; parity bits are ignored)</li>
+ <li>128-bit key for keyed <a href="glossary.html#MD5">MD5</a>
+ authentication</li>
+</ul>
+
+<p>If you want to use <a href="glossary.html#SHA">SHA</a> instead of <a
+href="glossary.html#MD5">MD5</a>, that requires a 160-bit key</p>
+
+<p>Note that any <strong>temporary files</strong> used must be kept
+<strong>secure</strong> since they contain keys. That is the reason for the
+umask command above. The temporary file should be deleted as soon as you are
+done with it. You may also want to change the umask back to its default value
+after you are finished working on keys.</p>
+
+<p>The ranbits utility may pause for a few seconds if not enough entropy is
+available immediately. See ipsec_ranbits(8) and random(4) for details. You
+may wish to provide some activity to feed entropy into the system. For
+example, you might move the mouse around, type random characters, or do
+<var>du /usr &gt; /dev/null</var> in the background.</p>
+
+<h2><a name="boot">Setting up connections at boot time</a></h2>
+
+<p>You can tell the system to set up connections automatically at boot time
+by putting suitable stuff in /etc/ipsec.conf on both systems. The relevant
+section of the file is labelled by a line reading <var>config setup</var>.</p>
+
+<p>Details can be found in the <a
+href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> man page. We also
+provide a file of <a href="examples">example configurations</a>.</p>
+
+<p>The most likely options are something like:</p>
+<dl>
+ <dt>interfaces="ipsec0=eth0 ipsec1=ppp0"</dt>
+ <dd>Tells KLIPS which interfaces to use. Up to four interfaces numbered
+ ipsec[0-3] are supported. Each interface can support an arbitrary
+ number of tunnels.
+ <p>Note that for PPP, you give the ppp[0-9] device name here, not the
+ underlying device such as modem (or eth1 if you are using PPPoE).</p>
+ </dd>
+ <dt>interfaces=%defaultroute</dt>
+ <dd>Alternative setting, useful in simple cases. KLIPS will pick up both
+ its interface and the next hop information from the settings of the
+ Linux default route.</dd>
+ <dt>forwardcontrol=no</dt>
+ <dd>Normally "no". Set to "yes" if the IP forwarding option is disabled
+ in your network configuration. (This can be set as a kernel
+ configuration option or later. e.g. on Redhat, it's in
+ /etc/sysconfig/network and on SuSE you can adjust it with Yast.) Linux
+ FreeS/WAN will then enable forwarding when starting up and turn it off
+ when going down. This is used to ensure that no packets will be
+ forwarded before IPsec comes up and takes control.</dd>
+ <dt>syslog=daemon.error</dt>
+ <dd>Used in messages to the system logging daemon (syslogd) to specify
+ what type of software is sending the messages. If the settings are
+ "daemon.error" as in our example, then syslogd treats the messages as
+ error messages from a daemon.
+ <p>Note that <a href="glossary.html#Pluto">Pluto</a> does not currently
+ pay attention to this variable. The variable controls setup messages
+ only.</p>
+ </dd>
+ <dt>klipsdebug=</dt>
+ <dd>Debug settings for <a href="glossary.html#KLIPS">KLIPS</a>.</dd>
+ <dt>plutodebug=</dt>
+ <dd>Debug settings for <a href="glossary.html#Pluto">Pluto</a>.</dd>
+ <dt>... for both the above DEBUG settings</dt>
+ <dd>Normally, leave empty as shown above for no debugging output.<br>
+ Use "all" for maximum information.<br>
+ See ipsec_klipsdebug(8) and ipsec_pluto(8) man page for other options.
+ Beware that if you set /etc/ipsec.conf to enable debug output, your
+ system's log files may get large quickly.</dd>
+ <dt>dumpdir=/safe/directory</dt>
+ <dd>Normally, programs started by ipsec setup don't crash. If they do, by
+ default, no core dump will be produced because such dumps would contain
+ secrets. If you find you need to debug such crashes, you can set
+ dumpdir to the name of a directory in which to collect the core
+ file.</dd>
+ <dt>manualstart=</dt>
+ <dd>List of manually keyed connections to be automatically started at
+ boot time. Useful for testing, but not for long term use. Connections
+ which are automatically started should also be automatically
+ re-keyed.</dd>
+ <dt>pluto=yes</dt>
+ <dd>Whether to start <a href="glossary.html#Pluto">Pluto</a> when ipsec
+ startup is done.<br>
+ This parameter is optional and defaults to "yes" if not present.
+ <p>"yes" is strongly recommended for production use so that the keying
+ daemon (Pluto) will automatically re-key the connections regularly. The
+ ipsec-auto parameters ikelifetime, ipseclifetime and reykeywindow give
+ you control over frequency of rekeying.</p>
+ </dd>
+ <dt>plutoload="reno-van reno-adam reno-nyc"</dt>
+ <dd>List of tunnels (by name, e.g. fred-susan or reno-van in our
+ examples) to be loaded into Pluto's internal database at startup. In
+ this example, Pluto loads three tunnels into its database when it is
+ started.
+ <p>If plutoload is "%search", Pluto will load any connections whose
+ description includes "auto=add" or "auto=start".</p>
+ </dd>
+ <dt>plutostart="reno-van reno-adam reno-nyc"</dt>
+ <dd>List of tunnels to attempt to negotiate when Pluto is started.
+ <p>If plutostart is "%search", Pluto will start any connections whose
+ description includes "auto=start".</p>
+ <p>Note that, for a connection intended to be permanent, <strong>both
+ gateways should be set try to start</strong> the tunnel. This allows
+ quick recovery if either gateway is rebooted or has its IPsec
+ restarted. If only one gateway is set to start the tunnel and the other
+ gateway restarts, the tunnel may not be rebuilt.</p>
+ </dd>
+ <dt>plutowait=no</dt>
+ <dd>Controls whether Pluto waits for one tunnel to be established before
+ starting to negotiate the next. You might set this to "yes"
+ <ul>
+ <li>if your gateway is a very limited machine and you need to
+ conserve resources.</li>
+ <li>for debugging; the logs are clearer if only one connection is
+ brought up at a time</li>
+ </ul>
+ For a busy and resource-laden production gateway, you likely want "no"
+ so that connections are brought up in parallel and the whole process
+ takes less time.</dd>
+</dl>
+
+<p>The example assumes you are at the Reno office and will use IPsec to
+Vancouver, New York City and Amsterdam.</p>
+
+<h2><a name="multitunnel">Multiple tunnels between the same two
+gateways</a></h2>
+
+<p>Consider a pair of subnets, each with a security gateway, connected via
+the Internet:</p>
+<pre> 192.168.100.0/24 left subnet
+ |
+ 192.168.100.1
+ North Gateway
+ 101.101.101.101 left
+ |
+ 101.101.101.1 left next hop
+ [Internet]
+ 202.202.202.1 right next hop
+ |
+ 202.202.202.202 right
+ South gateway
+ 192.168.200.1
+ |
+ 192.168.200.0/24 right subnet</pre>
+
+<p>A tunnel specification such as:</p>
+<pre>conn northnet-southnet
+ left=101.101.101.101
+ leftnexthop=101.101.101.1
+ leftsubnet=192.168.100.0/24
+ leftfirewall=yes
+ right=202.202.202.202
+ rightnexthop=202.202.202.1
+ rightsubnet=192.168.200.0/24
+ rightfirewall=yes</pre>
+will allow machines on the two subnets to talk to each other. You might test
+this by pinging from polarbear (192.168.100.7) to penguin (192.168.200.5).
+
+<p>However, <strong>this does not cover other traffic you might want to
+secure</strong>. To handle all the possibilities, you might also want these
+connection descriptions:</p>
+<pre>conn northgate-southnet
+ left=101.101.101.101
+ leftnexthop=101.101.101.1
+ right=202.202.202.202
+ rightnexthop=202.202.202.1
+ rightsubnet=192.168.200.0/24
+ rightfirewall=yes
+
+conn northnet-southgate
+ left=101.101.101.101
+ leftnexthop=101.101.101.1
+ leftsubnet=192.168.100.0/24
+ leftfirewall=yes
+ right=202.202.202.202
+ rightnexthop=202.202.202.1</pre>
+
+<p>Without these, neither gateway can do IPsec to the remote subnet. There is
+no IPsec tunnel or eroute set up for the traffic.</p>
+
+<p>In our example, with the non-routable 192.168.* addresses used, packets
+would simply be discarded. In a different configuration, with routable
+addresses for the remote subnet, <strong>they would be sent
+unencrypted</strong> since there would be no IPsec eroute and there would be
+a normal IP route.</p>
+
+<p>You might also want:</p>
+<pre>conn northgate-southgate
+ left=101.101.101.101
+ leftnexthop=101.101.101.1
+ right=202.202.202.202
+ rightnexthop=202.202.202.1</pre>
+
+<p>This is required if you want the two gateways to speak IPsec to each
+other.</p>
+
+<p>This requires a lot of duplication of details. Judicious use of
+<var>also=</var> and <var>include</var> can reduce this problem.</p>
+
+<p>Note that, while FreeS/WAN supports all four tunnel types, not all
+implementations do. In particular, some versions of Windows 2000 and the
+freely downloadable version of PGP provide only "client" functionality. You
+cannot use them as gateways with a subnet behind them. To get that
+functionality, you must upgrade to Windows 2000 server or the commercially
+available PGP products.</p>
+
+<h3><a name="advroute">One tunnel plus advanced routing</a></h3>
+It is also possible to use the new routing features in 2.2 and later kernels
+to avoid most needs for multple tunnels. Here is one mailing list message on
+the topic:
+<pre>Subject: Re: linux-ipsec: IPSec packets not entering tunnel?
+ Date: Mon, 20 Nov 2000
+ From: Justin Guyett &lt;jfg@sonicity.com&gt;
+
+On Mon, 20 Nov 2000, Claudia Schmeing wrote:
+
+&gt; Right Left
+&gt; "home" "office"
+&gt; 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24
+&gt;
+&gt; I've created all four tunnels, and can ping to test each of them,
+&gt; *except* homegate-officenet.
+
+I keep wondering why people create all four tunnels. Why not route
+traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
+And 99% of the time you don't need to access "office" directly, which
+means you can eliminate all but the subnet&lt;-&gt;subnet connection.</pre>
+and FreeS/WAN technical lead Henry Spencer's comment:
+<pre>&gt; I keep wondering why people create all four tunnels. Why not route
+&gt; traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
+
+This is feasible, given some iproute2 attention to source addresses, but
+it isn't something we've documented yet... (partly because we're still
+making some attempt to support 2.0.xx kernels, which can't do this, but
+mostly because we haven't caught up with it yet).
+
+&gt; And 99% of the time you don't need to access "office" directly, which
+&gt; means you can eliminate all but the subnet&lt;-&gt;subnet connection.
+
+Correct in principle, but people will keep trying to ping to or from the
+gateways during testing, and sometimes they want to run services on the
+gateway machines too.</pre>
+
+
+<!-- Is this in the right spot in this document? -->
+<H2><A name="opp.gate">An Opportunistic Gateway</A></H2>
+
+<H3>Start from full opportunism</H3>
+
+<P>Full opportunism
+allows you to initiate and receive opportunistic connections on your
+machine. The remaining instructions in this section assume
+you have first set up full opportunism on your gateway using
+<A HREF="quickstart.html#opp.incoming">these instructions</A>.
+Both sets of instructions require mailing DNS records to your ISP. Collect
+DNS records for both the gateway (above) and the
+subnet nodes (below) before contacting your ISP.</P>
+
+
+<H3>Reverse DNS TXT records for each protected machine</H3>
+
+<P>You need these so that your Opportunistic peers can:
+<UL>
+<LI>discover the gateway's address, knowing only the IP address
+ that packets are bound for</LI>
+<LI>verify that the gateway is authorised to encrypt for that endpoint</LI>
+</UL>
+
+<P>On the gateway, generate a TXT record with:
+<PRE> ipsec showhostkey --txt 192.0.2.11</PRE>
+<P>Use your gateway address in place of 192.0.2.11.</P>
+
+<P>You should see (keys are trimmed for clarity throughout our example):</P>
+<PRE> ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
+ IN TXT &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;</PRE>
+
+<P><B>This MUST BE the same key as in your gateway's TXT record, or nothing
+will work.</B></P>
+
+<P>In a text file, make one copy of this TXT record for each subnet
+ node:</P>
+<PRE> ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
+ IN TXT &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
+
+ ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
+ IN TXT &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
+
+ ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
+ IN TXT &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;</PRE>
+
+<P>Above each entry, insert a line like this:</P>
+<PRE> 98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.</PRE>
+
+<P>It must include:</P>
+<UL>
+<LI>The subnet node's address in reverse map format. For example, 192.0.2.120
+becomes <VAR>120.2.0.192.in-addr.arpa.</VAR>. Note the final period.</LI>
+<LI><VAR>IN PTR</VAR></LI>
+<LI>The node's name, ie. <VAR>arthur.example.com.</VAR>. Note
+the final period.</LI>
+</UL>
+
+<P>The result will be a file of TXT records, like this:</P>
+<PRE> 98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
+ ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
+ IN TXT &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
+
+ 99.2.0.192.in-addr.arpa. IN PTR ford.example.com.
+ ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
+ IN TXT &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
+
+ 100.2.0.192.in-addr.arpa. IN PTR trillian.example.com.
+ ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
+ IN TXT &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;</PRE>
+
+
+<H3>Publish your records</H3>
+
+<P>Ask your ISP to publish all the reverse DNS records you have collected.
+There may be a delay of up to 48 hours as the records propagate.</P>
+
+
+<H3>...and test them</H3>
+
+<P>Check a couple of records with commands like this one:</P>
+
+<PRE> ipsec verify --host ford.example.com
+ ipsec verify --host trillian.example.com</PRE>
+
+<P>The <var>verify</var> command checks for TXT records for both the
+subnet host and its gateway. You should see output like:</P>
+<PRE> ...
+ Looking for TXT in reverse map: 99.2.0.192.in-addr.arpa [OK]
+ ...
+ Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
+ ...
+ Looking for TXT in reverse map: 100.2.0.192.in-addr.arpa [OK]
+ ...
+ Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
+ ...</PRE>
+<H3>No Configuration Needed</H3>
+
+<P>FreeS/WAN 2.x ships with a built-in, automatically
+enabled OE connection <VAR>conn packetdefault</VAR>
+which applies OE, if possible, to all outbound traffic routed
+through the FreeS/WAN box.
+
+The
+<A HREF="manpage.d/ipsec.conf.5.html">ipsec.conf(5) manual</A>
+describes this connection in detail.
+While the effect is much the same as <VAR>private-or-clear</VAR>,
+the implementation is different: notably, it does not use policy
+groups.</P>
+
+<P>You can create more complex OE configurations
+for traffic forwarded through a FreeS/WAN box, as explained in our
+<A HREF="policygroups.html#policygroups">policy groups document</A>,
+or disable OE using
+<A HREF="policygroups.html#disable_policygroups">these instructions</A>.</P>
+
+
+
+<h2><a name="extruded.config">Extruded Subnets</a></h2>
+
+<p>What we call <a href="glossary.html#extruded">extruded subnets</a> are a
+special case of <a href="glossary.html#VPN.gloss">VPNs</a>.</p>
+
+<p>If your buddy has some unused IP addresses, in his subnet far off at the
+other side of the Internet, he can loan them to you... provided that the
+connection between you and him is fast enough to carry all the traffic
+between your machines and the rest of the Internet. In effect, he "extrudes"
+a part of his address space over the network to you, with your Internet
+traffic appearing to originate from behind his Internet gateway.</p>
+
+<p>As far as the Internet is concerned, your new extruded net is behind your
+buddy's gateway. You route all your packets for the Internet at large
+out his gateway, and receive return packets the same way. You route your
+local packets locally.</p>
+
+<p>Suppose your friend has a.b.c.0/24 and wants to give you a.b.c.240/28. The
+initial situation is:</p>
+<pre> subnet gateway Internet
+ a.b.c.0/24 a.b.c.1 p.q.r.s</pre>
+where anything from the Internet destined for any machine in a.b.c.0/24 is
+routed via p.q.r.s and that gateway knows what to do from there.
+
+<p>Of course it is quite normal for various smaller subnets to exist behind
+your friend's gateway. For example, your friend's company might have
+a.b.c.16/28=development, a.b.c.32/28=marketing and so on. The Internet
+neither knows not cares about this; it just delivers packets to the p.q.r.s
+and lets the gateway do whatever needs to be done from there.</p>
+
+<p>What we want to do is take a subnet, perhaps a.b.c.240/28, out of your
+friend's physical location <em>while still having your friend's gateway route
+to it</em>. As far as the Internet is concerned, you remain behind that
+gateway.</p>
+<pre> subnet gateway Internet your gate extruded
+
+ a.b.c.0/24 a.b.c.1 p.q.r.s d.e.f.g a.b.c.240/28
+
+ ========== tunnel ==========</pre>
+
+<p>The extruded addresses have to be a complete subnet.</p>
+
+<p>In our example, the friend's security gateway is also his Internet
+gateway, but this is not necessary. As long as all traffic from the Internet
+to his addresses passes through the Internet gate, the security gate could be
+a machine behind that. The IG would need to route all traffic for the
+extruded subnet to the SG, and the SG could handle the rest.</p>
+
+<p>First, configure your subnet using the extruded addresses. Your security
+gateway's interface to your subnet needs to have an extruded address
+(possibly using a Linux <a href="glossary.html#virtual">virtual
+interface</a>, if it also has to have a different address). Your gateway
+needs to have a route to the extruded subnet, pointing to that interface. The
+other machines at your site need to have addresses in that subnet, and
+default routes pointing to your gateway.</p>
+
+<p>If any of your friend's machines need to talk to the extruded subnet,
+<em>they</em> need to have a route for the extruded subnet, pointing at his
+gateway.</p>
+
+<p>Then set up an IPsec subnet-to-subnet tunnel between your gateway and his,
+with your subnet specified as the extruded subnet, and his subnet specified
+as "0.0.0.0/0".</p>
+
+<p>The tunnel description should be:</p>
+<pre>conn extruded
+ left=p.q.r.s
+ leftsubnet=0.0.0.0/0
+ right=d.e.f.g
+ rightsubnet=a.b.c.0/28</pre>
+
+<p>If either side was doing firewalling for the extruded subnet before the
+IPsec connection is set up, you'll need to poke holes in your
+<A HREF="firewall.html#firewall">firewall</A> to allow packets through.
+</p>
+
+<p>And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that is,
+the whole Internet -- through the tunnel to his SG, which then sends it
+onward as if it came from his subnet. When traffic for the extruded subnet
+arrives at his SG, it gets sent through the tunnel to your SG, which passes
+it to the right machine.</p>
+
+<p>Remember that when ipsec_manual or ipsec_auto takes a connection down, it
+<em>does not undo the route</em> it made for that connection. This lets you
+take a connection down and bring up a new one, or a modified version of the
+old one, without having to rebuild the route it uses and without any risk of
+packets which should use IPsec accidentally going out in the clear. Because
+the route always points into KLIPS, the packets will always go there. Because
+KLIPS temporarily has no idea what to do with them (no eroute for them), they
+will be discarded.</p>
+
+<p>If you <em>do</em> want to take the route down, this is what the "unroute"
+operation in manual and auto is for. Just do an unroute after doing the
+down.</p>
+
+<p>Note that the route for a connection may have replaced an existing
+non-IPsec route. Nothing in Linux FreeS/WAN will put that pre-IPsec route
+back. If you need it back, you have to create it with the route command.</p>
+
+<h2><a name="roadvirt">Road Warrior with virtual IP address</a></h2>
+
+<p>Please note that <A HREF="http://www.freeswan.ca/download.php">Super
+FreeS/WAN</A> now features DHCP-over-IPsec, which is an alternate procedure
+for Virtual IP address assignment.
+<p>
+
+<p>Here is a mailing list message about another way to configure for road
+warrior support:</p>
+<pre>Subject: Re: linux-ipsec: understanding the vpn
+ Date: Thu, 28 Oct 1999 10:43:22 -0400
+ From: Irving Reid &lt;irving@nevex.com&gt;
+
+&gt; local-------linux------internet------mobile
+&gt; LAN box user
+&gt; ...
+
+&gt; now when the mobile user connects to the linux box
+&gt; it is given a virtual IP address, i have configured it to
+&gt; be in the 10.x.x.x range. mobile user and linux box
+&gt; have a tunnel between them with these IP addresses.
+
+&gt; Uptil this all is fine.
+
+If it is possible to configure your mobile client software *not* to
+use a virtual IP address, that will make your life easier. It is easier
+to configure FreeS/WAN to use the actual address the mobile user gets
+from its ISP.
+
+Unfortunately, some Windows clients don't let you choose.
+
+&gt; what i would like to know is that how does the mobile
+&gt; user communicate with other computers on the local
+&gt; LAN , of course with the vpn ?
+
+&gt; what IP address should the local LAN
+&gt; computers have ? I guess their default gateway
+&gt; should be the linux box ? and does the linux box need
+&gt; to be a 2 NIC card box or one is fine.
+
+As someone else stated, yes, the Linux box would usually be the default
+IP gateway for the local lan.
+
+However...
+
+If you mobile user has software that *must* use a virtual IP address,
+the whole picture changes. Nobody has put much effort into getting
+FreeS/WAN to play well in this environment, but here's a sketch of one
+approach:
+
+Local Lan 1.0.0.0/24
+ |
+ +- Linux FreeS/WAN 1.0.0.2
+ |
+ | 1.0.0.1
+ Router
+ | 2.0.0.1
+ |
+Internet
+ |
+ | 3.0.0.1
+Mobile User
+ Virtual Address: 1.0.0.3
+
+Note that the Local Lan network (1.0.0.x) can be registered, routable
+addresses.
+
+Now, the Mobile User sets up an IPSec security association with the
+Linux box (1.0.0.2); it should ESP encapsulate all traffic to the
+network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key
+negotiation, which needs to work outside of the IPSec tunnel.
+
+On the Linux side, there's a bunch of stuff you need to do by hand (for
+now). FreeS/WAN should correctly handle setting up the IPSec SA and
+routes, but I haven't tested it so this may not work...
+
+The FreeS/WAN conn should look like:
+
+conn mobile
+ right=1.0.0.2
+ rightsubnet=1.0.0.0/24
+ rightnexthop=1.0.0.1
+ left=0.0.0.0 # The infamous "road warrior"
+ leftsubnet=1.0.0.3/32
+
+Note that the left subnet contains *only* the remote host's virtual
+address.
+
+Hopefully the routing table on the FreeS/WAN box ends up looking like
+this:
+
+% netstat -rn
+Kernel IP routing table
+Destination Gateway Genmask Flags MSS Window irtt Iface
+1.0.0.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0
+127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo
+0.0.0.0 1.0.0.1 0.0.0.0 UG 1500 0 0 eth0
+1.0.0.3 1.0.0.1 255.255.255.255 UG 1433 0 0 ipsec0
+
+So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should
+get bundled up and sent through the tunnel. To get the packets for
+1.0.0.3 to the Linux box in the first place, you need to use "proxy
+ARP".
+
+How this works is: when a host or router on the local Ethernet segment
+wants to send a packet to 1.0.0.3, it sends out an Ethernet level
+broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would
+reply, saying "send IP packets for 1.0.0.3 to my Ethernet address".
+
+Instead, you need to set up the Linux box so that _it_ answers ARP
+requests for 1.0.0.3, even though that isn't its IP address. That
+convinces everyone else on the lan to send 1.0.0.3 packets to the Linux
+box, where the usual FreeS/WAN processing and routing take over.
+
+% arp -i eth0 -s 1.0.0.3 -D eth0 pub
+
+This says, if you see an ARP request on interface eth0 asking for
+1.0.0.3, respond with the Ethernet address of interface eth0.
+
+Now, as I said at the very beginning, if it is *at all* possible to
+configure your client *not* to use the virtual IP address, you can avoid
+this whole mess.</pre>
+
+<h2><a name="dynamic">Dynamic Network Interfaces</a></h2>
+
+<p>Sometimes you have to cope with a situation where the network interface(s)
+aren't all there at boot. The common example is notebooks with PCMCIA.</p>
+
+<h3><a name="basicdyn">Basics</a></h3>
+
+<p>The key issue here is that the <var>config setup</var> section of the
+<var>/etc/ipsec.conf</var> configuration file lists the connection between
+ipsecN and hardware interfaces, in the <var>interfaces=</var> variable. At
+any time when <var>ipsec setup start</var> or <var>ipsec setup restart</var>
+is run this variable <strong>must</strong> correspond to the current real
+situation. More precisely, it <strong>must not</strong> mention any hardware
+interfaces which don't currently exist. The difficulty is that an <var>ipsec
+setup start</var> command is normally run at boot time so interfaces that are
+not up then are mis-handled.</p>
+
+<h3><a name="bootdyn">Boot Time</a></h3>
+
+<p>Normally, an <var>ipsec setup start</var> is run at boot time. However, if
+the hardware situation at boot time is uncertain, one of two things must be
+done.</p>
+<ul>
+ <li>One possibility is simply not to have IPsec brought up at boot time. To
+ do this:
+ <pre> chkconfig --level 2345 ipsec off</pre>
+ That's for modern Red Hats or other Linuxes with chkconfig. Systems which
+ lack this will require fiddling with symlinks in /etc/rc.d/rc?.d or the
+ equivalent.</li>
+ <li>Another possibility is to bring IPsec up with no interfaces, which is
+ less aesthetically satisfying but simpler. Just put
+ <pre> interfaces=</pre>
+ in the configuration file. KLIPS and Pluto will be started, but won't do
+ anything.</li>
+</ul>
+
+<h3><a name="changedyn">Change Time</a></h3>
+
+<p>When the hardware *is* in place, IPsec has to be made aware of it. Someday
+there may be a nice way to do this.</p>
+
+<p>Right now, the way to do it is to fix the <var>/etc/ipsec.conf</var> file
+appropriately, so <var>interfaces</var> reflects the new situation, and then
+restart the IPsec subsystem. This does break any existing IPsec
+connections.</p>
+
+<p>If IPsec wasn't brought up at boot time, do</p>
+<pre> ipsec setup start</pre>
+while if it was, do
+<pre> ipsec setup restart</pre>
+which won't be as quick.
+
+<p>If some of the hardware is to be taken out, before doing that, amend the
+configuration file so interfaces no longer includes it, and do</p>
+<pre> ipsec setup restart</pre>
+
+<p>Again, this breaks any existing connections.</p>
+
+<h2><a name="unencrypted">Unencrypted tunnels</a></h2>
+
+<p>Sometimes you might want to create a tunnel without encryption. Often this
+is a bad idea, even if you have some data which need not be private. See this
+<a href="ipsec.html#traffic.resist">discussion</a>.</p>
+
+<p>The IPsec protocols provide two ways to do build such tunnels:</p>
+<dl>
+ <dt>using ESP with null encryption</dt>
+ <dd>not supported by FreeS/WAN</dd>
+ <dt>using <a href="glossary.html#AH">AH</a> without <a
+ href="glossary.html#ESP">ESP</a></dt>
+ <dd>supported for manually keyed connections</dd>
+ <dd>possible with explicit commands via <a
+ href="manpage.d/ipsec_whack.8.html">ipsec_whack(8)</a> (see this <a
+ href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00190.html">list
+ message</a>)</dd>
+ <dd>not supported in the <a
+ href="manpage.d/ipsec_auto.8.html">ipsec_auto(8)</a> scripts.</dd>
+</dl>
+One situation in which this comes up is when otherwise some data would be
+encrypted twice. Alice wants a secure tunnel from her machine to Bob's. Since
+she's behind one security gateway and he's behind another, part of the tunnel
+that they build passes through the tunnel that their site admins have built
+between the gateways. All of Alice and Bob's messages are encrypted twice.
+
+<p>There are several ways to handle this.</p>
+<ul>
+ <li>Just accept the overhead of double encryption. The site admins might
+ choose this if any of the following apply:
+ <ul>
+ <li>policy says encrypt everything (usually, it should)</li>
+ <li>they don't entirely trust Alice and Bob (usually, if they don't
+ have to, they shouldn't)</li>
+ <li>if they don't feel the saved cycles are worth the time they'd need
+ to build a non-encrypted tunnel for Alice and Bob's packets (often,
+ they aren't)</li>
+ </ul>
+ </li>
+ <li>Use a plain IP-in-IP tunnel. These are not well documented. A good
+ starting point is in the Linux kernel source tree, in
+ /usr/src/linux/drivers/net/README.tunnel.</li>
+ <li>Use a manually-keyed AH-only tunnel.</li>
+</ul>
+
+<p>Note that if Alice and Bob want end-to-end security, they must build a
+tunnel end-to-end between their machines or use some other end-to-end tool
+such as PGP or SSL that suits their data. The only question is whether the
+admins build some special unencrypted tunnel for those already-encrypted
+packets.</p>
+</body>
+</html>