[people/ms/strongswan.git] / doc / src / background.html

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html">
  <title>FreeS/WAN background</title>
  <meta name="keywords" content="Linux, IPSEC, VPN, security, FreeSWAN">
  <!--

  Written by Sandy Harris for the Linux FreeS/WAN project
  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: background.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="background">Linux FreeS/WAN background</a></h1>

<p>This section discusses a number of issues which have three things in
common:</p>
<ul>
  <li>They are not specifically FreeS/WAN problems</li>
  <li>You may have to understand them to get FreeS/WAN working right</li>
  <li>They are not simple questions</li>
</ul>

<p>Grouping them here lets us provide the explanations some users will need
without unduly complicating the main text.</p>

<p>The explanations here are intended to be adequate for FreeS/WAN purposes
(please comment to the <a href="mail.html">users mailing list</a> if you
don't find them so), but they are not trying to be complete or definitive. If
you need more information, see the references provided in each section.</p>

<h2><a name="dns.background">Some DNS background</a></h2>

<p><a href="glossary.html#carpediem">Opportunistic encryption</a> requires
that the gateway systems be able to fetch public keys, and other
IPsec-related information, from each other's DNS (Domain Name Service)
records.</p>

<p><a href="glossary.html#DNS">DNS</a> is a distributed database that maps
names to IP addresses and vice versa.</p>

<p>Much good reference material is available for DNS, including:</p>
<ul>
  <li>the <a href="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html">DNS
  HowTo</a></li>
  <li>the standard <a href="biblio.html#DNS.book">DNS reference</a> book</li>
  <li><a href="http://www.linuxdoc.org/LDP/nag2/index.html">Linux Network
    Administrator's Guide</a></li>
  <li><a
    href="http://www.nominum.com/resources/whitepapers/bind-white-paper.html">BIND
    overview</a></li>
  <li><a
    href="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">BIND 9
    Administrator's Reference</a></li>
</ul>

<p>We give only a brief overview here, intended to help you use DNS for
FreeS/WAN purposes.</p>

<h3><a name="forward.reverse">Forward and reverse maps</a></h3>

<p>Although the implementation is distributed, it is often useful to speak of
DNS as if it were just two enormous tables:</p>
<ul>
  <li>the forward map: look up a name, get an IP address</li>
  <li>the reverse map: look up an IP address, get a name</li>
</ul>

<p>Both maps can optionally contain additional data. For opportunistic
encryption, we insert the data need for IPsec authentication.</p>

<p>A system named gateway.example.com with IP address 10.20.30.40 should have
at least two DNS records, one in each map:</p>
<dl>
  <dt>gateway.example.com. IN A 10.20.30.40</dt>
    <dd>used to look up the name and get an IP address</dd>
  <dt>40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</dt>
    <dd>used for reverse lookups, looking up an address to get the associated
      name. Notice that the digits here are in reverse order; the actual
      address is 10.20.30.40 but we use 40.30.20.10 here.</dd>
</dl>

<h3>Hierarchy and delegation</h3>

<p>For both maps there is a hierarchy of DNS servers and a system of
delegating authority so that, for example:</p>
<ul>
  <li>the DNS administrator for example.com can create entries of the form
    <var>name</var>.example.com</li>
  <li>the example.com admin cannot create an entry for counterexample.com;
    only someone with authority for .com can do that</li>
  <li>an admin might have authority for 20.10.in-addr.arpa.</li>
  <li>in either map, authority can be delegated
    <ul>
      <li>the example.com admin could give you authority for
        westcoast.example.com</li>
      <li>the 20.10.in-addr.arpa admin could give you authority for
        30.20.10.in-addr.arpa</li>
    </ul>
  </li>
</ul>

<p>DNS zones are the units of delegation. There is a hierarchy of zones.</p>

<h3>Syntax of DNS records</h3>

<p>Returning to the example records:</p>
<pre>        gateway.example.com. IN A 10.20.30.40
        40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</pre>

<p>some syntactic details are:</p>
<ul>
  <li>the IN indicates that these records are for <strong>In</strong>ternet
    addresses</li>
  <li>The final periods in '.com.' and '.arpa.' are required. They indicate
    the root of the domain name system.</li>
</ul>

<p>The capitalised strings after IN indicate the type of record. Possible
types include:</p>
<ul>
  <li><strong>A</strong>ddress, for forward lookups</li>
  <li><strong>P</strong>oin<strong>T</strong>e<strong>R</strong>, for reverse
    lookups</li>
  <li><strong>C</strong>anonical <strong>NAME</strong>, records to support
    aliasing, multiple names for one address</li>
  <li><strong>M</strong>ail e<strong>X</strong>change, used in mail
  routing</li>
  <li><strong>SIG</strong>nature, used in <a href="glossary.html#SDNS">secure
    DNS</a></li>
  <li><strong>KEY</strong>, used in <a href="glossary.html#SDNS">secure
    DNS</a></li>
  <li><strong>T</strong>e<strong>XT</strong>, a multi-purpose record type</li>
</ul>

<p>To set up for opportunistic encryption, you add some TXT records
to your DNS data. Details are in our <a href="quickstart.html">quickstart</a>
document.</p>

<h3>Cacheing, TTL and propagation delay</h3>

<p>DNS information is extensively cached. With no caching, a lookup by your
system of "www.freeswan.org" might involve:</p>
<ul>
  <li>your system asks your nameserver for "www.freeswan.org"</li>
  <li>local nameserver asks root server about ".org", gets reply</li>
  <li>local nameserver asks .org nameserver about "freeswan.org", gets
  reply</li>
  <li>local nameserver asks freeswan.org nameserver about "www.freeswan.org",
    gets reply</li>
</ul>

<p>However, this can be a bit inefficient. For example, if you are in the
Phillipines, the closest a root server is in Japan. That might send you to a
.org server in the US, and then to freeswan.org in Holland. If everyone did
all those lookups every time they clicked on a web link, the net would grind
to a halt.</p>

<p>Nameservers therefore cache information they look up. When you click on
another link at www.freeswan.org, your local nameserver has the IP address
for that server in its cache, and no further lookups are required. </p>

<p>Intermediate results are also cached. If you next go to
lists.freeswan.org, your nameserver can just ask the freeswan.org nameserver
for that address; it does not need to query the root or .org nameservers
because it has a cached address for the freeswan.org zone server.</p>

<p>Of course, like any cacheing mechanism, this can create problems of
consistency. What if the administrator for freeswan.org changes the IP
address, or the authentication key, for www.freeswan.org? If you use old
information from the cache, you may get it wrong. On the other hand, you
cannot afford to look up fresh information every time. Nor can you expect the
freeswan.org server to notify you; that isn't in the protocols.</p>

<p>The solution that is in the protocols is fairly simple. Cacheable records
are marked with Time To Live (TTL) information. When the time expires, the
caching server discards the record. The next time someone asks for it, the
server fetches a fresh copy. Of course, a server may also discard records
before their TTL expires if it is running out of cache space.</p>

<p>This implies that there will be some delay before the new version of a
changed record propagates around the net. Until the TTLs on all copies of the
old record expire, some users will see it because that is what is in their
cache. Other users may see the new record immediately because they don't have
an old one cached.</p>

<h2><a name="MTU.trouble">Problems with packet fragmentation</a></h2>

<p>It seems, from mailing list reports, to be moderately common for problems
to crop up in which small packets pass through the IPsec tunnels just fine
but larger packets fail.</p>

<p>These problems are caused by various devices along the way mis-handling
either packet fragments or <a href="glossary.html#pathMTU">path MTU
discovery</a>.</p>

<p>IPsec makes packets larger by adding an ESP or AH header. This can tickle
assorted bugs in fragment handling in routers and firewalls, or in path MTU
discovery mechanisms, and cause a variety of symptoms which are both annoying
and, often, quite hard to diagnose.</p>

<p>An explanation from project technical lead Henry Spencer:</p>
<pre>The problem is IP fragmentation; more precisely, the problem is that the
second, third, etc. fragments of an IP packet are often difficult for
filtering mechanisms to classify.

Routers cannot rely on reassembling the packet, or remembering what was in
earlier fragments, because the fragments may be out of order or may even
follow different routes.  So any general, worst-case filtering decision
pretty much has to be made on each fragment independently.  (If the router
knows that it is the only route to the destination, so all fragments
*must* pass through it, reassembly would be possible... but most routers
don't want to bother with the complications of that.)

All fragments carry roughly the original IP header, but any higher-level
header is (for IP purposes) just the first part of the packet data... so
only the first fragment carries that.  So, for example, on examining the
second fragment of a TCP packet, you could tell that it's TCP, but not
what port number it is destined for -- that information is in the TCP
header, which appears in the first fragment only. 

The result of this classification difficulty is that stupid routers and
over-paranoid firewalls may just throw fragments away.  To get through
them, you must reduce your MTU enough that fragmentation will not occur.
(In some cases, they might be willing to attempt reassembly, but have very
limited resources to devote to it, meaning that packets must be small and
fragments few in number, leading to the same conclusion:  smaller MTU.)</pre>

<p>In addition to the problem Henry describes, you may also have trouble with
<a href="glossary.html#pathMTU">path MTU discovery</a>.</p>

<p>By default, FreeS/WAN uses a large <a href="glossary.html#MTU">MTU</a> for
the ipsec device. This avoids some problems, but may complicate others.
Here's an explanation from Claudia:</p>
<pre>Here are a couple of pieces of background information. Apologies if you
have seen these already. An excerpt from one of my old posts:

    An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this 
    high MTU so that it does not fragment incoming packets before encryption 
    and encapsulation. If after IPSec processing packets are larger than 1500,
    [ie. the mtu of eth0] then eth0 will fragment them. 

    Adding IPSec headers adds a certain number of bytes to each packet. 
    The MTU of the IPSec interface refers to the maximum size of the packet
    before the IPSec headers are added. In some cases, people find it helpful 
    to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.

    That way, the resulting encapsulated packets don't exceed 1500. On most 
    networks, packets less than 1500 will not need to be fragmented.

and... (from Henry Spencer)

    The way it *ought* to work is that the MTU advertised by the ipsecN
    interface should be that of the underlying hardware interface, less a
    pinch for the extra headers needed. 

    Unfortunately, in certain situations this breaks many applications.
    There is a widespread implicit assumption that the smallest MTUs are 
    at the ends of paths, not in the middle, and another that MTUs are 
    never less than 1500.  A lot of code is unprepared to handle paths 
    where there is an "interior minimum" in the MTU, especially when it's 
    less than 1500. So we advertise a big MTU and just let the resulting 
    big packets fragment.

This usually works, but we do get bitten in cases where some intermediate
point can't handle all that fragmentation.  We can't win on this one.</pre>

<p>The MTU can be changed with an <var>overridemtu=</var> statement in the
<var>config setup</var> section of <a
href="manpage.d/ipsec.conf.5.html">ipsec.conf.5</a>.</p>

<p>For a discussion of MTU issues and some possible solutions using Linux
advanced routing facilities, see the <a
href="http://www.linuxguruz.org/iptables/howto/2.4routing-15.html#ss15.6">Linux
2.4 Advanced Routing HOWTO</a>.

For a discussion of MTU and NAT (Network Address Translation), see
<A HREF="http://harlech.math.ucla.edu/services/ipsec.html">James Carter's MTU
notes</A>.</p>

<h2><a name="nat.background">Network address translation (NAT)</a></h2>

<p><strong>N</strong>etwork <strong>A</strong>ddress
<strong>T</strong>ranslation is a service provided by some gateway machines.
Calling it NAPT (adding the word  <strong>P</strong>ort) would be more
precise, but we will follow the widespread usage.</p>

<p>A gateway doing NAT rewrites the headers of packets it is forwarding,
changing one or more of:</p>
<ul>
  <li>source address</li>
  <li>source port</li>
  <li>destination address</li>
  <li>destination port</li>
</ul>

<p>On Linux 2.4, NAT services are provided by the <a
href="http://netfilter.samba.org">netfilter(8)</a> firewall code. There are
several <a
href="http://netfilter.samba.org/documentation/index.html#HOWTO">Netfilter
HowTos</a> including one on NAT.</p>

<p>For older versions of Linux, this was referred to as "IP masquerade" and
different tools were used. See this <a
href="http://www.e-infomax.com/ipmasq/">resource page</a>.</p>

<p>Putting an IPsec gateway behind a NAT gateway is not recommended. See our
<a href="firewall.html#NAT">firewalls document</a>.</p>

<h3>NAT to non-routable addresses</h3>

<p>The most common application of NAT uses private <a
href="glossary.html#non-routable">non-routable</a> addresses.</p>

<p>Often a home or small office network will have:</p>
<ul>
  <li>one connection to the Internet</li>
  <li>one assigned publicly visible IP address</li>
  <li>several machines that all need access to the net</li>
</ul>

<p>Of course this poses a problem since several machines cannot use one
address. The best solution might be to obtain more addresses, but often this
is impractical or uneconomical.</p>

<p>A common solution is to have:</p>
<ul>
  <li><a href="glossary.html#non-routable">non-routable</a> addresses on the
    local network</li>
  <li>the gateway machine doing NAT</li>
  <li>all packets going outside the LAN rewritten to have the gateway as
    their source address</li>
</ul>

<p>The client machines are set up with reserved <a
href="#non-routable">non-routable</a> IP addresses defined in RFC 1918. The
masquerading gateway, the machine with the actual link to the Internet,
rewrites packet headers so that all packets going onto the Internet appear to
come from one IP address, that of its Internet interface. It then gets all
the replies, does some table lookups and more header rewriting, and delivers
the replies to the appropriate client machines.</p>

<p>As far as anyone else on the Internet is concerned, the systems behind the
gateway are completely hidden. Only one machine with one IP address is
visible.</p>

<p>For IPsec on such a gateway, you can entirely ignore the NAT in:</p>
<ul>
  <li><a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a></li>
  <li>firewall rules affecting your Internet-side interface</li>
</ul>

<p>Those can be set up exactly as they would be if your gateway had no other
systems behind it.</p>

<p>You do, however, have to take account of the NAT in firewall rules which
affect packet forwarding.</p>

<h3>NAT to routable addresses</h3>

<p>NAT to routable addresses is also possible, but is less common and may
make for rather tricky routing problems. We will not discuss it here. See the
<a href="http://netfilter.samba.org/documentation/index.html#HOWTO">Netfilter
HowTos</a>.</p>
</body>
</html>
Commit	Line	Data
997358a6 MW	1	<html>
	2	<head>
	3	<meta http-equiv="Content-Type" content="text/html">
	4	<title>FreeS/WAN background</title>
	5	<meta name="keywords" content="Linux, IPSEC, VPN, security, FreeSWAN">
	6	<!--
	7
	8	Written by Sandy Harris for the Linux FreeS/WAN project
	9	Freely distributable under the GNU General Public License
	10
	11	More information at www.freeswan.org
	12	Feedback to users@lists.freeswan.org
	13
	14	CVS information:
	15	RCS ID: $Id: background.html,v 1.1 2004/03/15 20:35:24 as Exp $
	16	Last changed: $Date: 2004/03/15 20:35:24 $
	17	Revision number: $Revision: 1.1 $
	18
	19	CVS revision numbers do not correspond to FreeS/WAN release numbers.
	20	-->
	21	</head>
	22
	23	<body>
	24	<h1><a name="background">Linux FreeS/WAN background</a></h1>
	25
	26	<p>This section discusses a number of issues which have three things in
	27	common:</p>
	28	<ul>
	29	<li>They are not specifically FreeS/WAN problems</li>
	30	<li>You may have to understand them to get FreeS/WAN working right</li>
	31	<li>They are not simple questions</li>
	32	</ul>
	33
	34	<p>Grouping them here lets us provide the explanations some users will need
	35	without unduly complicating the main text.</p>
	36
	37	<p>The explanations here are intended to be adequate for FreeS/WAN purposes
	38	(please comment to the <a href="mail.html">users mailing list</a> if you
	39	don't find them so), but they are not trying to be complete or definitive. If
	40	you need more information, see the references provided in each section.</p>
	41
	42	<h2><a name="dns.background">Some DNS background</a></h2>
	43
	44	<p><a href="glossary.html#carpediem">Opportunistic encryption</a> requires
	45	that the gateway systems be able to fetch public keys, and other
	46	IPsec-related information, from each other's DNS (Domain Name Service)
	47	records.</p>
	48
	49	<p><a href="glossary.html#DNS">DNS</a> is a distributed database that maps
	50	names to IP addresses and vice versa.</p>
	51
	52	<p>Much good reference material is available for DNS, including:</p>
	53	<ul>
	54	<li>the <a href="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html">DNS
	55	HowTo</a></li>
	56	<li>the standard <a href="biblio.html#DNS.book">DNS reference</a> book</li>
	57	<li><a href="http://www.linuxdoc.org/LDP/nag2/index.html">Linux Network
	58	Administrator's Guide</a></li>
	59	<li><a
	60	href="http://www.nominum.com/resources/whitepapers/bind-white-paper.html">BIND
	61	overview</a></li>
	62	<li><a
	63	href="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">BIND 9
	64	Administrator's Reference</a></li>
65	</ul>
66
67	<p>We give only a brief overview here, intended to help you use DNS for
68	FreeS/WAN purposes.</p>
69
70	<h3><a name="forward.reverse">Forward and reverse maps</a></h3>
71
72	<p>Although the implementation is distributed, it is often useful to speak of
73	DNS as if it were just two enormous tables:</p>
74	<ul>
75	<li>the forward map: look up a name, get an IP address</li>
76	<li>the reverse map: look up an IP address, get a name</li>
77	</ul>
78
79	<p>Both maps can optionally contain additional data. For opportunistic
80	encryption, we insert the data need for IPsec authentication.</p>
81
82	<p>A system named gateway.example.com with IP address 10.20.30.40 should have
83	at least two DNS records, one in each map:</p>
84	<dl>
85	<dt>gateway.example.com. IN A 10.20.30.40</dt>
86	<dd>used to look up the name and get an IP address</dd>
87	<dt>40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</dt>
88	<dd>used for reverse lookups, looking up an address to get the associated
89	name. Notice that the digits here are in reverse order; the actual
90	address is 10.20.30.40 but we use 40.30.20.10 here.</dd>
91	</dl>
92
93	<h3>Hierarchy and delegation</h3>
94
95	<p>For both maps there is a hierarchy of DNS servers and a system of
96	delegating authority so that, for example:</p>
97	<ul>
98	<li>the DNS administrator for example.com can create entries of the form
99	<var>name</var>.example.com</li>
100	<li>the example.com admin cannot create an entry for counterexample.com;
101	only someone with authority for .com can do that</li>
102	<li>an admin might have authority for 20.10.in-addr.arpa.</li>
103	<li>in either map, authority can be delegated
104	<ul>
105	<li>the example.com admin could give you authority for
106	westcoast.example.com</li>
107	<li>the 20.10.in-addr.arpa admin could give you authority for
108	30.20.10.in-addr.arpa</li>
109	</ul>
110	</li>
111	</ul>
112
113	<p>DNS zones are the units of delegation. There is a hierarchy of zones.</p>
114
115	<h3>Syntax of DNS records</h3>
116
117	<p>Returning to the example records:</p>
118	<pre> gateway.example.com. IN A 10.20.30.40
119	40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</pre>
120
121	<p>some syntactic details are:</p>
122	<ul>
123	<li>the IN indicates that these records are for <strong>In</strong>ternet
124	addresses</li>
125	<li>The final periods in '.com.' and '.arpa.' are required. They indicate
126	the root of the domain name system.</li>
127	</ul>
128
129	<p>The capitalised strings after IN indicate the type of record. Possible
130	types include:</p>
131	<ul>
132	<li><strong>A</strong>ddress, for forward lookups</li>
133	<li><strong>P</strong>oin<strong>T</strong>e<strong>R</strong>, for reverse
134	lookups</li>
135	<li><strong>C</strong>anonical <strong>NAME</strong>, records to support
136	aliasing, multiple names for one address</li>
137	<li><strong>M</strong>ail e<strong>X</strong>change, used in mail
138	routing</li>
139	<li><strong>SIG</strong>nature, used in <a href="glossary.html#SDNS">secure
140	DNS</a></li>
141	<li><strong>KEY</strong>, used in <a href="glossary.html#SDNS">secure
142	DNS</a></li>
143	<li><strong>T</strong>e<strong>XT</strong>, a multi-purpose record type</li>
144	</ul>
145
146	<p>To set up for opportunistic encryption, you add some TXT records
147	to your DNS data. Details are in our <a href="quickstart.html">quickstart</a>
148	document.</p>
149
150	<h3>Cacheing, TTL and propagation delay</h3>
151
152	<p>DNS information is extensively cached. With no caching, a lookup by your
153	system of "www.freeswan.org" might involve:</p>
154	<ul>
155	<li>your system asks your nameserver for "www.freeswan.org"</li>
156	<li>local nameserver asks root server about ".org", gets reply</li>
157	<li>local nameserver asks .org nameserver about "freeswan.org", gets
158	reply</li>
159	<li>local nameserver asks freeswan.org nameserver about "www.freeswan.org",
160	gets reply</li>
161	</ul>
162
163	<p>However, this can be a bit inefficient. For example, if you are in the
164	Phillipines, the closest a root server is in Japan. That might send you to a
165	.org server in the US, and then to freeswan.org in Holland. If everyone did
166	all those lookups every time they clicked on a web link, the net would grind
167	to a halt.</p>
168
169	<p>Nameservers therefore cache information they look up. When you click on
170	another link at www.freeswan.org, your local nameserver has the IP address
171	for that server in its cache, and no further lookups are required. </p>
172
173	<p>Intermediate results are also cached. If you next go to
174	lists.freeswan.org, your nameserver can just ask the freeswan.org nameserver
175	for that address; it does not need to query the root or .org nameservers
176	because it has a cached address for the freeswan.org zone server.</p>
177
178	<p>Of course, like any cacheing mechanism, this can create problems of
179	consistency. What if the administrator for freeswan.org changes the IP
180	address, or the authentication key, for www.freeswan.org? If you use old
181	information from the cache, you may get it wrong. On the other hand, you
182	cannot afford to look up fresh information every time. Nor can you expect the
183	freeswan.org server to notify you; that isn't in the protocols.</p>
184
185	<p>The solution that is in the protocols is fairly simple. Cacheable records
186	are marked with Time To Live (TTL) information. When the time expires, the
187	caching server discards the record. The next time someone asks for it, the
188	server fetches a fresh copy. Of course, a server may also discard records
189	before their TTL expires if it is running out of cache space.</p>
190
191	<p>This implies that there will be some delay before the new version of a
192	changed record propagates around the net. Until the TTLs on all copies of the
193	old record expire, some users will see it because that is what is in their
194	cache. Other users may see the new record immediately because they don't have
195	an old one cached.</p>
196
197	<h2><a name="MTU.trouble">Problems with packet fragmentation</a></h2>
198
199	<p>It seems, from mailing list reports, to be moderately common for problems
200	to crop up in which small packets pass through the IPsec tunnels just fine
201	but larger packets fail.</p>
202
203	<p>These problems are caused by various devices along the way mis-handling
204	either packet fragments or <a href="glossary.html#pathMTU">path MTU
205	discovery</a>.</p>
206
207	<p>IPsec makes packets larger by adding an ESP or AH header. This can tickle
208	assorted bugs in fragment handling in routers and firewalls, or in path MTU
209	discovery mechanisms, and cause a variety of symptoms which are both annoying
210	and, often, quite hard to diagnose.</p>
211
212	<p>An explanation from project technical lead Henry Spencer:</p>
213	<pre>The problem is IP fragmentation; more precisely, the problem is that the
214	second, third, etc. fragments of an IP packet are often difficult for
215	filtering mechanisms to classify.
216
217	Routers cannot rely on reassembling the packet, or remembering what was in
218	earlier fragments, because the fragments may be out of order or may even
219	follow different routes. So any general, worst-case filtering decision
220	pretty much has to be made on each fragment independently. (If the router
221	knows that it is the only route to the destination, so all fragments
222	must pass through it, reassembly would be possible... but most routers
223	don't want to bother with the complications of that.)
224
225	All fragments carry roughly the original IP header, but any higher-level
226	header is (for IP purposes) just the first part of the packet data... so
227	only the first fragment carries that. So, for example, on examining the
228	second fragment of a TCP packet, you could tell that it's TCP, but not
229	what port number it is destined for -- that information is in the TCP
230	header, which appears in the first fragment only.
231
232	The result of this classification difficulty is that stupid routers and
233	over-paranoid firewalls may just throw fragments away. To get through
234	them, you must reduce your MTU enough that fragmentation will not occur.
235	(In some cases, they might be willing to attempt reassembly, but have very
236	limited resources to devote to it, meaning that packets must be small and
237	fragments few in number, leading to the same conclusion: smaller MTU.)</pre>
238
239	<p>In addition to the problem Henry describes, you may also have trouble with
240	<a href="glossary.html#pathMTU">path MTU discovery</a>.</p>
241
242	<p>By default, FreeS/WAN uses a large <a href="glossary.html#MTU">MTU</a> for
243	the ipsec device. This avoids some problems, but may complicate others.
244	Here's an explanation from Claudia:</p>
245	<pre>Here are a couple of pieces of background information. Apologies if you
246	have seen these already. An excerpt from one of my old posts:
247
248	An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this
249	high MTU so that it does not fragment incoming packets before encryption
250	and encapsulation. If after IPSec processing packets are larger than 1500,
251	[ie. the mtu of eth0] then eth0 will fragment them.
252
253	Adding IPSec headers adds a certain number of bytes to each packet.
254	The MTU of the IPSec interface refers to the maximum size of the packet
255	before the IPSec headers are added. In some cases, people find it helpful
256	to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.
257
258	That way, the resulting encapsulated packets don't exceed 1500. On most
259	networks, packets less than 1500 will not need to be fragmented.
260
261	and... (from Henry Spencer)
262
263	The way it ought to work is that the MTU advertised by the ipsecN
264	interface should be that of the underlying hardware interface, less a
265	pinch for the extra headers needed.
266
267	Unfortunately, in certain situations this breaks many applications.
268	There is a widespread implicit assumption that the smallest MTUs are
269	at the ends of paths, not in the middle, and another that MTUs are
270	never less than 1500. A lot of code is unprepared to handle paths
271	where there is an "interior minimum" in the MTU, especially when it's
272	less than 1500. So we advertise a big MTU and just let the resulting
273	big packets fragment.
274
275	This usually works, but we do get bitten in cases where some intermediate
276	point can't handle all that fragmentation. We can't win on this one.</pre>
277
278	<p>The MTU can be changed with an <var>overridemtu=</var> statement in the
279	<var>config setup</var> section of <a
280	href="manpage.d/ipsec.conf.5.html">ipsec.conf.5</a>.</p>
281
282	<p>For a discussion of MTU issues and some possible solutions using Linux
283	advanced routing facilities, see the <a
284	href="http://www.linuxguruz.org/iptables/howto/2.4routing-15.html#ss15.6">Linux
285	2.4 Advanced Routing HOWTO</a>.
286
287	For a discussion of MTU and NAT (Network Address Translation), see
288	<A HREF="http://harlech.math.ucla.edu/services/ipsec.html">James Carter's MTU
289	notes</A>.</p>
290
291	<h2><a name="nat.background">Network address translation (NAT)</a></h2>
292
293	<p><strong>N</strong>etwork <strong>A</strong>ddress
294	<strong>T</strong>ranslation is a service provided by some gateway machines.
295	Calling it NAPT (adding the word <strong>P</strong>ort) would be more
296	precise, but we will follow the widespread usage.</p>
297
298	<p>A gateway doing NAT rewrites the headers of packets it is forwarding,
299	changing one or more of:</p>
300	<ul>
301	<li>source address</li>
302	<li>source port</li>
303	<li>destination address</li>
304	<li>destination port</li>
305	</ul>
306
307	<p>On Linux 2.4, NAT services are provided by the <a
308	href="http://netfilter.samba.org">netfilter(8)</a> firewall code. There are
309	several <a
310	href="http://netfilter.samba.org/documentation/index.html#HOWTO">Netfilter
311	HowTos</a> including one on NAT.</p>
312
313	<p>For older versions of Linux, this was referred to as "IP masquerade" and
314	different tools were used. See this <a
315	href="http://www.e-infomax.com/ipmasq/">resource page</a>.</p>
316
317	<p>Putting an IPsec gateway behind a NAT gateway is not recommended. See our
318	<a href="firewall.html#NAT">firewalls document</a>.</p>
319
320	<h3>NAT to non-routable addresses</h3>
321
322	<p>The most common application of NAT uses private <a
323	href="glossary.html#non-routable">non-routable</a> addresses.</p>
324
325	<p>Often a home or small office network will have:</p>
326	<ul>
327	<li>one connection to the Internet</li>
328	<li>one assigned publicly visible IP address</li>
329	<li>several machines that all need access to the net</li>
330	</ul>
331
332	<p>Of course this poses a problem since several machines cannot use one
333	address. The best solution might be to obtain more addresses, but often this
334	is impractical or uneconomical.</p>
335
336	<p>A common solution is to have:</p>
337	<ul>
338	<li><a href="glossary.html#non-routable">non-routable</a> addresses on the
339	local network</li>
340	<li>the gateway machine doing NAT</li>
341	<li>all packets going outside the LAN rewritten to have the gateway as
342	their source address</li>
343	</ul>
344
345	<p>The client machines are set up with reserved <a
346	href="#non-routable">non-routable</a> IP addresses defined in RFC 1918. The
347	masquerading gateway, the machine with the actual link to the Internet,
348	rewrites packet headers so that all packets going onto the Internet appear to
349	come from one IP address, that of its Internet interface. It then gets all
350	the replies, does some table lookups and more header rewriting, and delivers
351	the replies to the appropriate client machines.</p>
352
353	<p>As far as anyone else on the Internet is concerned, the systems behind the
354	gateway are completely hidden. Only one machine with one IP address is
355	visible.</p>
356
357	<p>For IPsec on such a gateway, you can entirely ignore the NAT in:</p>
358	<ul>
359	<li><a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a></li>
360	<li>firewall rules affecting your Internet-side interface</li>
361	</ul>
362
363	<p>Those can be set up exactly as they would be if your gateway had no other
364	systems behind it.</p>
365
366	<p>You do, however, have to take account of the NAT in firewall rules which
367	affect packet forwarding.</p>
368
369	<h3>NAT to routable addresses</h3>
370
371	<p>NAT to routable addresses is also possible, but is less common and may
372	make for rather tricky routing problems. We will not discuss it here. See the
373	<a href="http://netfilter.samba.org/documentation/index.html#HOWTO">Netfilter
374	HowTos</a>.</p>
375	</body>
376	</html>