doc/firewall.html

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