1233 lines
61 KiB
HTML
1233 lines
61 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Introduction to FreeS/WAN</TITLE>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
|
|
<STYLE TYPE="text/css"><!--
|
|
BODY { font-family: serif }
|
|
H1 { font-family: sans-serif }
|
|
H2 { font-family: sans-serif }
|
|
H3 { font-family: sans-serif }
|
|
H4 { font-family: sans-serif }
|
|
H5 { font-family: sans-serif }
|
|
H6 { font-family: sans-serif }
|
|
SUB { font-size: smaller }
|
|
SUP { font-size: smaller }
|
|
PRE { font-family: monospace }
|
|
--></STYLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="kernel.html">Previous</A>
|
|
<A HREF="install.html">Next</A>
|
|
<HR>
|
|
<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 > temp
|
|
ipsec ranbits 128 >> 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 > /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 <jfg@sonicity.com>
|
|
|
|
On Mon, 20 Nov 2000, Claudia Schmeing wrote:
|
|
|
|
> Right Left
|
|
> "home" "office"
|
|
> 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24
|
|
>
|
|
> I've created all four tunnels, and can ping to test each of them,
|
|
> *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<->subnet connection.</PRE>
|
|
and FreeS/WAN technical lead Henry Spencer's comment:
|
|
<PRE>> 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?
|
|
|
|
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).
|
|
|
|
> And 99% of the time you don't need to access "office" directly, which
|
|
> means you can eliminate all but the subnet<->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><A NAME="14_7_1">Start from full opportunism</A></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><A NAME="14_7_2">Reverse DNS TXT records for each protected machine</A>
|
|
</H3>
|
|
<P>You need these so that your Opportunistic peers can:</P>
|
|
<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:</P>
|
|
<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 "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"</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 "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"</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 "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
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 "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
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 "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"</PRE>
|
|
<H3><A NAME="14_7_3">Publish your records</A></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><A NAME="14_7_4">...and test them</A></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><A NAME="14_7_5">No Configuration Needed</A></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></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 <irving@nevex.com>
|
|
|
|
> local-------linux------internet------mobile
|
|
> LAN box user
|
|
> ...
|
|
|
|
> now when the mobile user connects to the linux box
|
|
> it is given a virtual IP address, i have configured it to
|
|
> be in the 10.x.x.x range. mobile user and linux box
|
|
> have a tunnel between them with these IP addresses.
|
|
|
|
> 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.
|
|
|
|
> what i would like to know is that how does the mobile
|
|
> user communicate with other computers on the local
|
|
> LAN , of course with the vpn ?
|
|
|
|
> what IP address should the local LAN
|
|
> computers have ? I guess their default gateway
|
|
> should be the linux box ? and does the linux box need
|
|
> 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>
|
|
<HR>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="kernel.html">Previous</A>
|
|
<A HREF="install.html">Next</A>
|
|
</BODY>
|
|
</HTML>
|