freeswan/doc/src/firewall.html

   1 <html>
   2 <head>
   3   <meta http-equiv="Content-Type" content="text/html">
   4   <title>FreeS/WAN and firewalls</title>
   5   <meta name="keywords"
   6   content="Linux, IPsec, VPN, security, FreeSWAN, firewall, ipchains, iptables">
   7   <!--
   8
   9   Written by Sandy Harris for the Linux FreeS/WAN project
  10   Freely distributable under the GNU General Public License
  11
  12   More information at www.freeswan.org
  13   Feedback to users@lists.freeswan.org
  14
  15   CVS information:
  16   RCS ID:          $Id: firewall.html,v 1.38 2002/03/24 18:47:35 sandy Exp $
  17   Last changed:    $Date: 2002/03/24 18:47:35 $
  18   Revision number: $Revision: 1.38 $
  19
  20   CVS revision numbers do not correspond to FreeS/WAN release numbers.
  21   -->
  22 </head>
  23
  24 <body>
  25 <h1><a name="firewall">FreeS/WAN and firewalls</a></h1>
  26
  27 <p>FreeS/WAN, or other IPsec implementations, frequently run on gateway
  28 machines, the same machines running firewall or packet filtering code. This
  29 document discusses the relation between the two.</p>
  30
  31 <p>The firewall code in 2.4 and later kernels is called Netfilter. The
  32 user-space utility to manage a firwewall is iptables(8). See the <a
  33 href="http://netfilter.samba.org">netfilter/iptables web site</a> for
  34 details.</p>
  35
  36 <h2><a name="filters">Filtering rules for IPsec packets</a></h2>
  37
  38 <p>The basic constraint is that <strong>an IPsec gateway must have packet
  39 filters that allow IPsec packets</strong>, at least when talking to other
  40 IPsec gateways:</p>
  41 <ul>
  42   <li>UDP port 500 for <a href="glossary.html#IKE">IKE</a> negotiations</li>
  43   <li>protocol 50 if you use <a href="glossary.html#ESP">ESP</a> encryption
  44     and/or authentication (the typical case)</li>
  45   <li>protocol 51 if you use <a href="glossary.html#AH">AH</a> packet-level
  46     authentication</li>
  47 </ul>
  48
  49 <p>Your gateway and the other IPsec gateways it communicates with must be
  50 able to exchange these packets for IPsec to work. Firewall rules must allow
  51 UDP 500 and at least one of <glossary.html#AH>AHor <glossary.html#ESP>ESP on
  52 the interface that communicates with the other gateway.</p>
  53
  54 <p>For nearly all FreeS/WAN applications, you must allow UDP port 500 and the
  55 ESP protocol.</p>
  56
  57 <p>There are two ways to set this up:</p>
  58 <dl>
  59   <dt>easier but less flexible</dt>
  60     <dd>Just set up your firewall scripts at boot time to allow IPsec packets
  61       to and from your gateway. Let FreeS/WAN reject any bogus packets.</dd>
  62   <dt>more work, giving you more precise control</dt>
  63     <dd>Have the <a href="manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</a>
  64       daemon call scripts to adjust firewall rules dynamically as required.
  65       This is done by naming the scripts in the <a
  66       href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> variables
  67       <var>prepluto=</var>, <var>postpluto=</var>, <var>leftupdown=</var> and
  68       <var>rightupdown=</var>.</dd>
  69 </dl>
  70
  71 <p>Both methods are described in more detail below.</p>
  72
  73 <h2><a name="examplefw">Firewall configuration at boot</a></h2>
  74
  75 <p>It is possible to set up both firewalling and IPsec with appropriate
  76 scripts at boot and then not use <var>leftupdown=</var> and
  77 <var>rightupdown=</var>, or use them only for simple up and down
  78 operations.</p>
  79
  80 <p>Basically, the technique is</p>
  81 <ul>
  82   <li>allow IPsec packets (typically, IKE on UDP port 500 plus ESP, protocol
  83     50)
  84     <ul>
  85       <li>incoming, if the destination address is your gateway (and
  86         optionally, only from known senders)</li>
  87       <li>outgoing, with the from address of your gateway (and optionally,
  88         only to known receivers)</li>
  89     </ul>
  90   </li>
  91   <li>let <a href="glossary.html#Pluto">Pluto</a> deal with IKE</li>
  92   <li>let <a href="glossary.html#KLIPS">KLIPS</a> deal with ESP</li>
  93 </ul>
  94
  95 <p>Since Pluto authenticates its partners during the negotiation, and KLIPS
  96 drops packets for which no tunnel has been negotiated, this may be all you
  97 need.</p>
  98
  99 <h3><a name="simple.rules">A simple set of rules</a></h3>
 100
 101 <p>In simple cases, you need only a few rules, as in this example:</p>
 102 <pre># allow IPsec
 103 #
 104 # IKE negotiations
 105 iptables -A INPUT  -p udp --sport 500 --dport 500 -j ACCEPT
 106 iptables -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
 107 # ESP encrypton and authentication
 108 iptables -A INPUT  -p 50 -j ACCEPT
 109 iptables -A OUTPUT -p 50 -j ACCEPT
 110 # uncomment for AH authentication header
 111 # iptables -A INPUT  -p 51 -j ACCEPT
 112 # iptables -A OUTPUT -p 51 -j ACCEPT</pre>
 113
 114 <h3><a name="complex.rules">Other rules</a></h3>
 115 You can add aditional rules, or modify existing ones, to work with IPsec and
 116 with your network and policies. We give a some examples in this section.
 117
 118 <p>However, while it is certainly possible to create an elaborate set of
 119 rules yourself (please let us know via the <a href="mail.html">mailing
 120 list</a> if you do), it may be both easier and more secure to use a set which
 121 has already been published and tested.</p>
 122
 123 <p>The published rule sets we know of are described in the <a
 124 href="#rules.pub">next section</a>.</p>
 125
 126 <h4>Adding additional rules</h4>
 127 If necessary, you can add additional rules to:
 128 <dl>
 129   <dt>reject IPsec packets that are not to or from known gateways</dt>
 130     <dd>This possibility is discussed in more detail <a
 131       href="#unknowngate">later</a></dd>
 132   <dt>allow systems behind your gateway to build IPsec tunnels that pass
 133   through the gateway</dt>
 134     <dd>This possibility is discussed in more detail <a
 135       href="#through">later</a></dd>
 136   <dt>filter incoming packets emerging from KLIPS.</dt>
 137     <dd>Firewall rules can recognise packets emerging from IPsec. They are
 138       marked as arriving on an interface such as <var>ipsec0</var>, rather
 139       than <var>eth0</var>, <var>ppp0</var> or whatever.</dd>
 140 </dl>
 141
 142 <p>It is therefore reasonably straightforward to filter these packets in
 143 whatever way suits your situation.</p>
 144
 145 <h4>Modifying existing rules</h4>
 146
 147 <p>In some cases rules that work fine before you add IPsec may require
 148 modification to work with IPsec.</p>
 149
 150 <p>This is especially likely for rules that deal with interfaces on the
 151 Internet side of your system. IPsec adds a new interface; often the rules
 152 must change to take account of that.</p>
 153
 154 <p>For example, consider the rules given in <a
 155 href="http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-5.html">this
 156 section</a> of the Netfilter documentation:</p>
 157 <pre>Most people just have a single PPP connection to the Internet, and don't
 158 want anyone coming back into their network, or the firewall:
 159
 160     ## Insert connection-tracking modules (not needed if built into kernel).
 161     # insmod ip_conntrack
 162     # insmod ip_conntrack_ftp
 163
 164     ## Create chain which blocks new connections, except if coming from inside.
 165     # iptables -N block
 166     # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
 167     # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
 168     # iptables -A block -j DROP
 169
 170     ## Jump to that chain from INPUT and FORWARD chains.
 171     # iptables -A INPUT -j block
 172     # iptables -A FORWARD -j block</pre>
 173
 174 <p>On an IPsec gateway, those rules may need to be modified. The above allows
 175 new connections from <em>anywhere except ppp0</em>. That means new
 176 connections from ipsec0 are allowed.</p>
 177
 178 <p>Do you want to allow anyone who can establish an IPsec connection to your
 179 gateway to initiate TCP connections to any service on your network? Almost
 180 certainly not if you are using opportunistic encryption. Quite possibly not
 181 even if you have only explicitly configured connections.</p>
 182
 183 <p>To disallow incoming connections from ipsec0, change the middle section
 184 above to:</p>
 185 <pre>    ## Create chain which blocks new connections, except if coming from inside.
 186     # iptables -N block
 187     # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
 188     # iptables -A block -m state --state NEW -i ppp+ -j DROP
 189     # iptables -A block -m state --state NEW -i ipsec+ -j DROP
 190     # iptables -A block -m state --state NEW -i -j ACCEPT
 191     # iptables -A block -j DROP</pre>
 192
 193 <p>The original rules accepted NEW connections from anywhere except ppp0.
 194 This version drops NEW connections from any PPP interface (ppp+) and from any
 195 ipsec interface (ipsec+), then accepts the survivors.</p>
 196
 197 <p>Of course, these are only examples. You will need to adapt them to your
 198 own situation.</p>
 199
 200 <h3><a name="rules.pub">Published rule sets</a></h3>
 201
 202 <p>Several sets of firewall rules that work with FreeS/WAN are available.</p>
 203
 204 <h4><a name="Ranch.trinity">Scripts based on Ranch's work</a></h4>
 205
 206 <p>One user, Rob Hutton, posted his boot time scripts to the mailing list,
 207 and we included them in previous versions of this documentation. They are
 208 still available from our <a
 209 href="http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/firewall.html#examplefw">web
 210 site</a>. However, they were for an earlier FreeS/WAN version so we no longer
 211 recommend them. Also, they had some bugs. See this <a
 212 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00316.html">message</a>.</p>
 213
 214 <p>Those scripts were based on David Ranch's scripts for his "Trinity OS" for
 215 setting up a secure Linux. Check his <a
 216 href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html">home
 217 page</a> for the latest version and for information on his <a
 218 href="biblio.html#ranch">book</a> on securing Linux. If you are going to base
 219 your firewalling on Ranch's scripts, we recommend using his latest version,
 220 and sending him any IPsec modifications you make for incorporation into later
 221 versions.</p>
 222
 223 <h4><a name="seawall">The Seattle firewall</a></h4>
 224
 225 <p>We have had several mailing lists reports of good results using FreeS/WAN
 226 with Seawall (the Seattle Firewall). See that project's <a
 227 href="http://seawall.sourceforge.net/">home page</a> on Sourceforge.</p>
 228
 229 <h4><a name="rcf">The RCF scripts</a></h4>
 230
 231 <p>Another set of firewall scripts with IPsec support are the RCF or
 232 rc.firewall scripts. See their <a
 233 href="http://jsmoriss.mvlan.net/linux/rcf.html">home page</a>.</p>
 234
 235 <h4><a name="asgard">Asgard scripts</a></h4>
 236
 237 <p><a href="http://heimdall.asgardsrealm.net/linux/firewall/">Asgard's
 238 Realm</a> has set of firewall scripts with FreeS/WAN support, for 2.4 kernels
 239 and iptables.</p>
 240
 241 <h4><a name="user.scripts">User scripts from the mailing list</a></h4>
 242
 243 <p>One user gave considerable detail on his scripts, including supporting <a
 244 href="glossary.html#IPX">IPX</a> through the tunnel. His message was too long
 245 to conveniently be quoted here, so I've put it in a <a
 246 href="user_examples.html">separate file</a>.</p>
 247
 248 <h2><a name="updown">Calling firewall scripts, named in ipsec.conf(5)</a></h2>
 249
 250 <p>The <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> configuration
 251 file has three pairs of parameters used to specify an interface between
 252 FreeS/WAN and firewalling code.</p>
 253
 254 <p>Note that using these is not required if you have a static firewall setup.
 255 In that case, you just set your firewall up at boot time (in a way that
 256 permits the IPsec connections you want) and do not change it thereafter. Omit
 257 all the FreeS/WAN firewall parameters and FreeS/WAN will not attempt to
 258 adjust firewall rules at all. See <a href="#examplefw">above</a> for some
 259 information on appropriate scripts.</p>
 260
 261 <p>However, if you want your firewall rules to change when IPsec connections
 262 change, then you need to use these parameters.</p>
 263
 264 <h3><a name="pre_post">Scripts called at IPsec start and stop</a></h3>
 265
 266 <p>One pair of parmeters are set in the <var>config setup</var> section of
 267 the <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> file and affect
 268 all connections:</p>
 269 <dl>
 270   <dt>prepluto=</dt>
 271     <dd>script to be called before <a
 272       href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> IKE daemon is
 273     started.</dd>
 274   <dt>postpluto=</dt>
 275     <dd>script to be called after <a
 276       href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> IKE daemon is
 277     stopped.</dd>
 278 </dl>
 279 These parameters allow you to change firewall parameters whenever IPsec is
 280 started or stopped.
 281
 282 <p>They can also be used in other ways. For example, you might have
 283 <var>prepluto</var> add a module to your kernel for the secure network
 284 interface or make a dialup connection, and then have <var>postpluto</var>
 285 remove the module or take the connection down.</p>
 286
 287 <h3><a name="up_down">Scripts called at connection up and down</a></h3>
 288
 289 <p>The other parameters are set in connection descriptions. They can be set
 290 in individual connection descriptions, and could even call different scripts
 291 for each connection for maximum flexibility. In most applications, however,
 292 it makes sense to use only one script and to call it from <var>conn
 293 %default</var> section so that it applies to all connections.</p>
 294
 295 <p>You can:</p>
 296 <dl>
 297   <dt><strong>either</strong></dt>
 298     <dd>set <var>leftfirewall=yes</var> or <var>rightfirewall=yes</var> to
 299       use our supplied default script</dd>
 300   <dt><strong>or</strong></dt>
 301     <dd>assign a name in a <var>leftupdown=</var> or <var>rightupdown=</var>
 302       line to use your own script</dd>
 303 </dl>
 304
 305 <p>Note that <strong>only one of these should be used</strong>. You cannot
 306 sensibly use both. Since <strong>our default script is obsolete</strong>
 307 (designed for firewalls using <var>ipfwadm(8)</var> on 2.0 kernels), most
 308 users who need this service will <strong>need to write a custom
 309 script</strong>.</p>
 310
 311 <h4><a name="fw.default">The default script</a></h4>
 312
 313 <p>We supply a default script named <var>_updown</var>.</p>
 314 <dl>
 315   <dt>leftfirewall=</dt>
 316     <dd></dd>
 317   <dt>rightfirewall=</dt>
 318     <dd>indicates that the gateway is doing firewalling and that <a
 319       href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> should poke holes in
 320       the firewall as required.</dd>
 321 </dl>
 322
 323 <p>Set these to <var>yes</var> and Pluto will call our default script
 324 <var>_updown</var> with appropriate arguments whenever it:</p>
 325 <ul>
 326   <li>starts or stops IPsec services</li>
 327   <li>brings a connection up or down</li>
 328 </ul>
 329
 330 <p>The supplied default <var>_updown</var> script is appropriate for simple
 331 cases using the <var>ipfwadm(8)</var> firewalling package.</p>
 332
 333 <h4><a name="userscript">User-written scripts</a></h4>
 334
 335 <p>You can also write your own script and have Pluto call it. Just put the
 336 script's name in one of these <a
 337 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> lines:</p>
 338 <dl>
 339   <dt>leftupdown=</dt>
 340     <dd></dd>
 341   <dt>rightupdown=</dt>
 342     <dd>specifies a script to call instead of our default script
 343       <var>_updown</var>.</dd>
 344 </dl>
 345
 346 <p>Your script should take the same arguments and use the same environment
 347 variables as <var>_updown</var>. See the "updown command" section of the <a
 348 href="manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</a> man page for
 349 details.</p>
 350
 351 <p>Note that <strong>you should not modify our _updown script in
 352 place</strong>. If you did that, then upgraded FreeS/WAN, the upgrade would
 353 install a new default script, overwriting your changes.</p>
 354
 355 <h3><a name="ipchains.script">Scripts for ipchains or iptables</a></h3>
 356
 357 <p>Our <var>_updown</var> is for firewalls using <var>ipfwadm(8)</var>, the
 358 firewall code for the 2.0 series of Linux kernels. If you are using the more
 359 recent packages <var>ipchains(8)</var> (for 2.2 kernels) or
 360 <var>iptables(8)</var> (2.4 kernels), then you must do one of:</p>
 361 <ul>
 362   <li>use static firewall rules which are set up at boot time as described <a
 363     href="#examplefw">above</a> and do not need to be changed by Pluto</li>
 364   <li>limit yourself to ipchains(8)'s ipfwadm(8) emulation mode in order to
 365     use our script</li>
 366   <li>write your own script and call it with <var>leftupdown</var> and
 367     <var>rightupdown</var>.</li>
 368 </ul>
 369
 370 <p>You can write a script to do whatever you need with firewalling. Specify
 371 its name in a <var>[left|right]updown=</var> parameter in <a
 372 href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> and Pluto will
 373 automatically call it for you.</p>
 374
 375 <p>The arguments Pluto passes such a script are the same ones it passes to
 376 our default _updown script, so the best way to build yours is to copy ours
 377 and modify the copy.</p>
 378
 379 <p>Note, however, that <strong>you should not modify our _updown script in
 380 place</strong>. If you did that, then upgraded FreeS/WAN, the upgrade would
 381 install a new default script, overwriting your changes.</p>
 382
 383 <h2><a name="NAT">A complication: IPsec vs. NAT</a></h2>
 384
 385 <p><a href="glossary.html#NAT.gloss">Network Address Translation</a>, also
 386 known as IP masquerading, is a method of allocating IP addresses dynamically,
 387 typically in circumstances where the total number of machines which need to
 388 access the Internet exceeds the supply of IP addresses.</p>
 389
 390 <p>Any attempt to perform NAT operations on IPsec packets <em>between the
 391 IPsec gateways</em> creates a basic conflict:</p>
 392 <ul>
 393   <li>IPsec wants to authenticate packets and ensure they are unaltered on a
 394     gateway-to-gateway basis</li>
 395   <li>NAT rewrites packet headers as they go by</li>
 396   <li>IPsec authentication fails if packets are rewritten anywhere between
 397     the IPsec gateways</li>
 398 </ul>
 399
 400 <p>For <a href="glossary.html#AH">AH</a>, which authenticates parts of the
 401 packet header including source and destination IP addresses, this is fatal.
 402 If NAT changes those fields, AH authentication fails.</p>
 403
 404 <p>For <a href="glossary.html#IKE">IKE</a> and <a
 405 href="glossary.html#ESP">ESP</a> it is not necessarily fatal, but is
 406 certainly an unwelcome complication.</p>
 407
 408 <h3><a name="nat_ok">NAT on or behind the IPsec gateway works</a></h3>
 409
 410 <p>This problem can be avoided by having the masquerading take place <em>on
 411 or behind</em> the IPsec gateway.</p>
 412
 413 <p>This can be done physically with two machines, one physically behind the
 414 other. A picture, using SG to indicate IPsec <strong>S</strong>ecurity
 415 <strong>G</strong>ateways, is:</p>
 416 <pre>      clients --- NAT ----- SG ---------- SG
 417                   two machines</pre>
 418
 419 <p>In this configuration, the actual client addresses need not be given in
 420 the <var>leftsubnet=</var> parameter of the FreeS/WAN connection description.
 421 The security gateway just delivers packets to the NAT box; it needs only that
 422 machine's address. What that machine does with them does not affect
 423 FreeS/WAN.</p>
 424
 425 <p>A more common setup has one machine performing both functions:</p>
 426 <pre>      clients ----- NAT/SG ---------------SG
 427                   one machine</pre>
 428
 429 <p>Here you have a choice of techniques depending on whether you want to make
 430 your client subnet visible to clients on the other end:</p>
 431 <ul>
 432   <li>If you want the single gateway to behave like the two shown above, with
 433     your clients hidden behind the NAT, then omit the <var>leftsubnet=</var>
 434     parameter. It then defaults to the gateway address. Clients on the other
 435     end then talk via the tunnel only to your gateway. The gateway takes
 436     packets emerging from the tunnel, applies normal masquerading, and
 437     forwards them to clients.</li>
 438   <li>If you want to make your client machines visible, then give the client
 439     subnet addresses as the <var>leftsubnet=</var> parameter in the
 440     connection description and
 441     <dl>
 442       <dt>either</dt>
 443         <dd>set <var>leftfirewall=yes</var> to use the default
 444           <var>updown</var> script</dd>
 445       <dt>or</dt>
 446         <dd>use your own script by giving its name in a
 447           <var>leftupdown=</var> parameter</dd>
 448     </dl>
 449     These scripts are described in their own <a href="#updown">section</a>.
 450     <p>In this case, no masquerading is done. Packets to or from the client
 451     subnet are encrypted or decrypted without any change to their client
 452     subnet addresses, although of course the encapsulating packets use
 453     gateway addresses in their headers. Clients behind the right security
 454     gateway see a route via that gateway to the left subnet.</p>
 455   </li>
 456 </ul>
 457
 458 <h3><a name="nat_bad">NAT between gateways is problematic</a></h3>
 459
 460 <p>We recommend not trying to build IPsec connections which pass through a
 461 NAT machine. This setup poses problems:</p>
 462 <pre>      clients --- SG --- NAT ---------- SG</pre>
 463
 464 <p>If you must try it, some references are:</p>
 465 <ul>
 466   <li>Jean_Francois Nadeau's document on doing <a
 467     href="http://jixen.tripod.com/#NATed gateways">IPsec behind NAT</a></li>
 468   <li><a href="web.html#VPN.masq">VPN masquerade patches</a> to make a Linux
 469     NAT box handle IPsec packets correctly</li>
 470 </ul>
 471
 472 <h3><a name="NAT.ref">Other references on NAT and IPsec</a></h3>
 473
 474 <p>Other documents which may be relevant include:</p>
 475 <ul>
 476   <li>an Internet Draft on <a
 477     href="http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-04.txt">IPsec
 478     and NAT</a> which may eventually evolve into a standard solution for this
 479     problem.</li>
 480   <li>an informational <a
 481     href="http://www.cis.ohio-state.edu/rfc/rfc2709.txt">RFC</a>,
 482     <cite>Security Model with Tunnel-mode IPsec for NAT Domains</cite>.</li>
 483   <li>an <a
 484     href="http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html">article</a>
 485     in Cisco's <cite>Internet Protocol Journal</cite></li>
 486 </ul>
 487
 488 <h2><a name="complications">Other complications</a></h2>
 489
 490 <p>Of course simply allowing UDP 500 and ESP packets is not the whole story.
 491 Various other issues arise in making IPsec and packet filters co-exist and
 492 even co-operate. Some of them are summarised below.</p>
 493
 494 <h3><a name="through">IPsec <em>through</em></a> the gateway</h3>
 495
 496 <p>Basic IPsec packet filtering rules deal only with packets addressed to or
 497 sent from your IPsec gateway.</p>
 498
 499 <p>It is a separate policy decision whether to permit such packets to pass
 500 through the gateway so that client machines can build end-to-end IPsec
 501 tunnels of their own. This may not be practical if you are using <a
 502 href="#NAT">NAT (IP masquerade)</a> on your gateway, and may conflict with
 503 some corporate security policies.</p>
 504
 505 <p>Where possible, allowing this is almost certainly a good idea. Using IPsec
 506 on an end-to-end basis is more secure than gateway-to-gateway.</p>
 507
 508 <p>Doing it is quite simple. You just need firewall rules that allow UDP port
 509 500 and protocols 50 and 51 to pass through your gateway. If you wish, you
 510 can of course restrict this to certain hosts.</p>
 511
 512 <h3><a name="ipsec_only">Preventing non-IPsec traffic</a></h3>
 513 You can also filter <em>everything but</em> UDP port 500 and ESP or AH to
 514 restrict traffic to IPsec only, either for anyone communicating with your
 515 host or just for specific partners.
 516
 517 <p>One application of this is for the telecommuter who might have:</p>
 518 <pre>     Sunset==========West------------------East ================= firewall --- the Internet
 519          home network      untrusted net        corporate network</pre>
 520
 521 <p>The subnet on the right is 0.0.0.0/0, the whole Internet. The West gateway
 522 is set up so that it allows only IPsec packets to East in or out.</p>
 523
 524 <p>This configuration is used in AT&amp;T Research's network. For details,
 525 see the <a href="intro.html#applied">papers</a> links in our introduction.</p>
 526
 527 <p>Another application would be to set up firewall rules so that an internal
 528 machine, such as an employees-only web server, could not talk to the outside
 529 world except via specific IPsec tunnels.</p>
 530
 531 <h3><a name="unknowngate">Filtering packets from unknown gateways</a></h3>
 532
 533 <p>It is possible to use firewall rules to restrict UDP 500, ESP and AH
 534 packets so that these packets are accepted only from known gateways. This is
 535 not strictly necessary since FreeS/WAN will discard packets from unknown
 536 gateways. You might, however, want to do it for any of a number of reasons.
 537 For example:</p>
 538 <ul>
 539   <li>Arguably, "belt and suspenders" is the sensible approach to security.
 540     If you can block a potential attack in two ways, use both. The only
 541     question is whether to look for a third way after implementing the first
 542     two.</li>
 543   <li>Some admins may prefer to use the firewall code this way because they
 544     prefer firewall logging to FreeS/WAN's logging.</li>
 545   <li>You may need it to implement your security policy. Consider an employee
 546     working at home, and a policy that says traffic from the home system to
 547     the Internet at large must go first via IPsec to the corporate LAN and
 548     then out to the Internet via the corporate firewall. One way to do that
 549     is to make <var>ipsec0</var> the default route on the home gateway and
 550     provide exceptions only for UDP 500 and ESP to the corporate gateway.
 551     Everything else is then routed via the tunnel to the corporate
 552   gateway.</li>
 553 </ul>
 554
 555 <p>It is not possible to use only static firewall rules for this filtering if
 556 you do not know the other gateways' IP addresses in advance, for example if
 557 you have "road warriors" who may connect from a different address each time
 558 or if want to do <a href="glossary.html#carpediem">opportunistic
 559 encryption</a> to arbitrary gateways. In these cases, you can accept UDP 500
 560 IKE packets from anywhere, then use the <a href="#updown">updown</a> script
 561 feature of <a href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> to dynamically
 562 adjust firewalling for each negotiated tunnel.</p>
 563
 564 <p>Firewall packet filtering does not much reduce the risk of a <a
 565 href="glossary.html#DOS">denial of service attack</a> on FreeS/WAN. The
 566 firewall can drop packets from unknown gateways, but KLIPS does that quite
 567 efficiently anyway, so you gain little. The firewall cannot drop otherwise
 568 legitmate packets that fail KLIPS authentication, so it cannot protect
 569 against an attack designed to exhaust resources by making FreeS/WAN perform
 570 many expensive authentication operations.</p>
 571
 572 <p>In summary, firewall filtering of IPsec packets from unknown gateways is
 573 possible but not strictly necessary.</p>
 574
 575 <h2><a name="otherfilter">Other packet filters</a></h2>
 576
 577 <p>When the IPsec gateway is also acting as your firewall, other packet
 578 filtering rules will be in play. In general, those are outside the scope of
 579 this document. See our <a href="web.html#firewall.linux">Linux firewall
 580 links</a> for information. There are a few types of packet, however, which
 581 can affect the operation of FreeS/WAN or of diagnostic tools commonly used
 582 with it. These are discussed below.</p>
 583
 584 <h3><a name="ICMP">ICMP filtering</a></h3>
 585
 586 <p><a href="glossary.html#ICMP.gloss">ICMP</a> is the
 587 <strong>I</strong>nternet <strong>C</strong>ontrol <strong>M</strong>essage
 588 <strong>P</strong>rotocol. It is used for messages between IP implementations
 589 themselves, whereas IP used is used between the clients of those
 590 implementations. ICMP is, unsurprisingly, used for control messages. For
 591 example, it is used to notify a sender that a desination is not reachable, or
 592 to tell a router to reroute certain packets elsewhere.</p>
 593
 594 <p>ICMP handling is tricky for firewalls.</p>
 595 <ul>
 596   <li>You definitely want some ICMP messages to get through; things won't
 597     work without them. For example, your clients need to know if some
 598     destination they ask for is unreachable.</li>
 599   <li>On the other hand, you do equally definitely do not want untrusted folk
 600     sending arbitrary control messages to your machines. Imagine what someone
 601     moderately clever and moderately malicious could do to you, given control
 602     of your network's routing.</li>
 603 </ul>
 604
 605 <p>ICMP does not use ports. Messages are distinguished by a "message type"
 606 field and, for some types, by an additional "code" field. The definitive list
 607 of types and codes is on the <a href="http://www.iana.org">IANA</a> site.</p>
 608
 609 <p>One expert uses this definition for ICMP message types to be dropped at
 610 the firewall.</p>
 611 <pre># ICMP types which lack socially redeeming value.
 612 #  5     Redirect
 613 #  9     Router Advertisement
 614 # 10     Router Selection
 615 # 15     Information Request
 616 # 16     Information Reply
 617 # 17     Address Mask Request
 618 # 18     Address Mask Reply
 619
 620 badicmp='5 9 10 15 16 17 18'</pre>
 621
 622 <p>A more conservative approach would be to make a list of allowed types and
 623 drop everything else.</p>
 624
 625 <p>Whichever way you do it, your ICMP filtering rules on a FreeS/WAN gateway
 626 should allow at least the following ICMP packet types:</p>
 627 <dl>
 628   <dt>echo (type 8)</dt>
 629     <dd></dd>
 630   <dt>echo reply (type 0)</dt>
 631     <dd>These are used by ping(1). We recommend allowing both types through
 632       the tunnel and to or from your gateway's external interface, since
 633       ping(1) is an essential testing tool.
 634       <p>It is fairly common for firewalls to drop ICMP echo packets
 635       addressed to machines behind the firewall. If that is your policy,
 636       please create an exception for such packets arriving via an IPsec
 637       tunnel, at least during intial testing of those tunnels.</p>
 638     </dd>
 639   <dt>destination unreachable (type 3)</dt>
 640     <dd>This is used, with code 4 (Fragmentation Needed and Don't Fragment
 641       was Set) in the code field, to control <a
 642       href="glossary.html#pathMTU">path MTU discovery</a>. Since IPsec
 643       processing adds headers, enlarges packets and may cause fragmentation,
 644       an IPsec gateway should be able to send and receive these ICMP messages
 645       <strong>on both inside and outside interfaces</strong>.</dd>
 646 </dl>
 647
 648 <h3><a name="traceroute">UDP packets for traceroute</a></h3>
 649
 650 <p>The traceroute(1) utility uses UDP port numbers from 33434 to
 651 approximately 33633. Generally, these should be allowed through for
 652 troubleshooting.</p>
 653
 654 <p>Some firewalls drop these packets to prevent outsiders exploring the
 655 protected network with traceroute(1). If that is your policy, consider
 656 creating an exception for such packets arriving via an IPsec tunnel, at least
 657 during intial testing of those tunnels.</p>
 658
 659 <h3><a name="l2tp">UDP for L2TP</a></h3>
 660 <p>
 661 Windows 2000 does, and products designed for compatibility with it may, build
 662 <a href="glossary.html#L2TP">L2TP</a> tunnels over IPsec connections.
 663
 664 <p>For this to work, you must allow UDP protocol 1701 packets coming out of
 665 your tunnels to continue to their destination. You can, and probably should,
 666 block such packets to or from your external interfaces, but allow them from
 667 <var>ipsec0</var>.</p>
 668
 669 <p>See also our Windows 2000 <a href="interop.html#win2k">interoperation
 670 discussion</a>.</p>
 671
 672 <h2><a name="packets">How it all works: IPsec packet details</a></h2>
 673
 674 <p>IPsec uses three main types of packet:</p>
 675 <dl>
 676   <dt><a href="glossary.html#IKE">IKE</a> uses <strong>the UDP protocol and
 677   port 500</strong>.</dt>
 678     <dd>Unless you are using only (less secure, not recommended) manual
 679       keying, you need IKE to negotiate connection parameters, acceptable
 680       algorithms, key sizes and key setup. IKE handles everything required to
 681       set up, rekey, repair or tear down IPsec connections.</dd>
 682   <dt><a href="glossary.html#ESP">ESP</a> is <strong>protocol number
 683   50</strong></dt>
 684     <dd>This is required for encrypted connections.</dd>
 685   <dt><a href="glossary.html#AH">AH</a> is <strong>protocol number
 686   51</strong></dt>
 687     <dd>This can be used where only authentication, not encryption, is
 688       required.</dd>
 689 </dl>
 690
 691 <p>All of those packets should have appropriate IPsec gateway addresses in
 692 both the to and from IP header fields. Firewall rules can check this if you
 693 wish, though it is not strictly necessary. This is discussed in more detail
 694 <a href="#unknowngate">later</a>.</p>
 695
 696 <p>IPsec processing of incoming packets authenticates them then removes the
 697 ESP or AH header and decrypts if necessary. Successful processing exposes an
 698 inner packet which is then delivered back to the firewall machinery, marked
 699 as having arrived on an <var>ipsec[0-3]</var> interface. Firewall rules can
 700 use that interface label to distinguish these packets from unencrypted
 701 packets which are labelled with the physical interface they arrived on (or
 702 perhaps with a non-IPsec virtual interface such as <var>ppp0</var>).</p>
 703
 704 <p>One of our users sent a mailing list message with a <a
 705 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00006.html">diagram</a>
 706 of the packet flow.</p>
 707
 708 <h3><a name="noport">ESP and AH do not have ports</a></h3>
 709
 710 <p>Some protocols, such as TCP and UDP, have the notion of ports. Others
 711 protocols, including ESP and AH, do not. Quite a few IPsec newcomers have
 712 become confused on this point. There are no ports <em>in</em> the ESP or AH
 713 protocols, and no ports used <em>for</em> them. For these protocols, <em>the
 714 idea of ports is completely irrelevant</em>.</p>
 715
 716 <h3><a name="header">Header layout</a></h3>
 717
 718 <p>The protocol numbers for ESP or AH are used in the 'next header' field of
 719 the IP header. On most non-IPsec packets, that field would have one of:</p>
 720 <ul>
 721   <li>1 for ICMP</li>
 722   <li>4 for IP-in-IP encapsulation</li>
 723   <li>6 for TCP</li>
 724   <li>17 for UDP</li>
 725   <li>... or one of about 100 other possibilities listed by <a
 726     href="http://www.iana.org">IANA</a></li>
 727 </ul>
 728
 729 <p>Each header in the sequence tells what the next header will be. IPsec adds
 730 headers for ESP or AH near the beginning of the sequence. The original
 731 headers are kept and the 'next header' fields adjusted so that all headers
 732 can be correctly interpreted.</p>
 733
 734 <p>For example, using <strong>[</strong> <strong>]</strong> to indicate data
 735 protected by ESP and unintelligible to an eavesdropper between the
 736 gateways:</p>
 737 <ul>
 738   <li>a simple packet might have only IP and TCP headers with:
 739     <ul>
 740       <li>IP header says next header --&gt; TCP</li>
 741       <li>TCP header port number --&gt; which process to send data to</li>
 742       <li>data</li>
 743     </ul>
 744   </li>
 745   <li>with ESP <a href="glossary.html#transport">transport mode</a>
 746     encapsulation, that packet would have:
 747     <ul>
 748       <li>IP header says next header --&gt; ESP</li>
 749       <li>ESP header <strong>[</strong> says next --&gt; TCP</li>
 750       <li>TCP header port number --&gt; which process to send data to</li>
 751       <li>data <strong>]</strong></li>
 752     </ul>
 753     Note that the IP header is outside ESP protection, visible to an
 754     attacker, and that the final destination must be the gateway.</li>
 755   <li>with ESP in <a href="glossary.html#tunnel">tunnel mode</a>, we might
 756     have:
 757     <ul>
 758       <li>IP header says next header --&gt; ESP</li>
 759       <li>ESP header <strong>[</strong> says next --&gt; IP</li>
 760       <li>IP header says next header --&gt; TCP</li>
 761       <li>TCP header port number --&gt; which process to send data to</li>
 762       <li>data <strong>]</strong></li>
 763     </ul>
 764     Here the inner IP header is protected by ESP, unreadable by an attacker.
 765     Also, the inner header can have a different IP address than the outer IP
 766     header, so the decrypted packet can be routed from the IPsec gateway to a
 767     final destination which may be another machine.</li>
 768 </ul>
 769
 770 <p>Part of the ESP header itself is encrypted, which is why the
 771 <strong>[</strong> indicating protected data appears in the middle of some
 772 lines above. The next header field of the ESP header is protected. This makes
 773 <a href="glossary.html#traffic">traffic analysis</a> more difficult. The next
 774 header field would tell an eavesdropper whether your packet was UDP to the
 775 gateway, TCP to the gateway, or encapsulated IP. It is better not to give
 776 this information away. A clever attacker may deduce some of it from the
 777 pattern of packet sizes and timings, but we need not make it easy.</p>
 778
 779 <p>IPsec allows various combinations of these to match local policies,
 780 including combinations that use both AH and ESP headers or that nest multiple
 781 copies of these headers.</p>
 782
 783 <p>For example, suppose my employer has an IPsec VPN running between two
 784 offices so all packets travelling between the gateways for those offices are
 785 encrypted. If gateway policies allow it (The admins could block UDP 500 and
 786 protocols 50 and 51 to disallow it), I can build an IPsec tunnel from my
 787 desktop to a machine in some remote office. Those packets will have one ESP
 788 header throughout their life, for my end-to-end tunnel. For part of the
 789 route, however, they will also have another ESP layer for the corporate VPN's
 790 encapsulation. The whole header scheme for a packet on the Internet might
 791 be:</p>
 792 <ul>
 793   <li>IP header (with gateway address) says next header --&gt; ESP</li>
 794   <li>ESP header <strong>[</strong> says next --&gt; IP</li>
 795   <li>IP header (with receiving machine address) says next header --&gt;
 796   ESP</li>
 797   <li>ESP header <strong>[</strong> says next --&gt; TCP</li>
 798   <li>TCP header port number --&gt; which process to send data to</li>
 799   <li>data <strong>]]</strong></li>
 800 </ul>
 801
 802 <p>The first ESP (outermost) header is for the corporate VPN. The inner ESP
 803 header is for the secure machine-to-machine link.</p>
 804
 805 <h3><a name="dhr">DHR on the updown script</a></h3>
 806
 807 <p>Here are some mailing list comments from <a
 808 href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> developer Hugh Redelmeier on
 809 an earlier draft of this document:</p>
 810 <pre>There are many important things left out
 811
 812 - firewalling is important but must reflect (implement) policy.  Since
 813   policy isn't the same for all our customers, and we're not experts,
 814   we should concentrate on FW and MASQ interactions with FreeS/WAN.
 815
 816 - we need a diagram to show packet flow WITHIN ONE MACHINE, assuming
 817   IKE, IPsec, FW, and MASQ are all done on that machine.  The flow is
 818   obvious if the components are run on different machines (trace the
 819   cables).
 820
 821   IKE input:
 822         + packet appears on public IF, as UDP port 500
 823         + input firewalling rules are applied (may discard)
 824         + Pluto sees the packet.
 825
 826   IKE output:
 827         + Pluto generates the packet &amp; writes to public IF, UDP port 500
 828         + output firewalling rules are applied (may discard)
 829         + packet sent out public IF
 830
 831   IPsec input, with encapsulated packet, outer destination of this host:
 832         + packet appears on public IF, protocol 50 or 51.  If this
 833           packet is the result of decapsulation, it will appear
 834           instead on the paired ipsec IF.
 835         + input firewalling rules are applied (but packet is opaque)
 836         + KLIPS decapsulates it, writes result to paired ipsec IF
 837         + input firewalling rules are applied to resulting packet
 838           as input on ipsec IF
 839         + if the destination of the packet is this machine, the
 840           packet is passed on to the appropriate protocol handler.
 841           If the original packet was encapsulated more than once
 842           and the new outer destination is this machine, that
 843           handler will be KLIPS.
 844         + otherwise:
 845           * routing is done for the resulting packet.  This may well
 846             direct it into KLIPS for encoding or encrypting.  What
 847             happens then is described elsewhere.
 848           * forwarding firewalling rules are applied
 849           * output firewalling rules are applied
 850           * the packet is sent where routing specified
 851
 852  IPsec input, with encapsulated packet, outer destination of another host:
 853         + packet appears on some IF, protocol 50 or 51
 854         + input firewalling rules are applied (but packet is opaque)
 855         + routing selects where to send the packet
 856         + forwarding firewalling rules are applied (but packet is opaque)
 857         + packet forwarded, still encapsulated
 858
 859   IPsec output, from this host or from a client:
 860         + if from a client, input firewalling rules are applied as the
 861           packet arrives on the private IF
 862         + routing directs the packet to an ipsec IF (this is how the
 863           system decides KLIPS processing is required)
 864         + if from a client, forwarding firewalling rules are applied
 865         + KLIPS eroute mechanism matches the source and destination
 866           to registered eroutes, yielding a SPI group.  This dictates
 867           processing, and where the resulting packet is to be sent
 868           (the destinations SG and the nexthop).
 869         + output firewalling is not applied to the resulting
 870           encapsulated packet
 871
 872 - Until quite recently, KLIPS would double encapsulate packets that
 873   didn't strictly need to be.  Firewalling should be prepared for
 874   those packets showing up as ESP and AH protocol input packets on
 875   an ipsec IF.
 876
 877 - MASQ processing seems to be done as if it were part of the
 878   forwarding firewall processing (this should be verified).
 879
 880 - If a firewall is being used, it is likely the case that it needs to
 881   be adjusted whenever IPsec SAs are added or removed.  Pluto invokes
 882   a script to do this (and to adjust routing) at suitable times.  The
 883   default script is only suitable for ipfwadm-managed firewalls.  Under
 884   LINUX 2.2.x kernels, ipchains can be managed by ipfwadm (emulation),
 885   but ipchains more powerful if manipulated using the ipchains command.
 886   In this case, a custom updown script must be used.
 887
 888   We think that the flexibility of ipchains precludes us supplying an
 889   updown script that would be widely appropriate.</pre>
 890 </body>
 891 </html>