Initial prep work on NAT gateway section. Still a WIP.

Sponsored by: iXsystems

en_US.ISO8859-1/books/handbook/firewalls/chapter.xml

@@ -628,25 +628,14 @@ pass proto udp to any port $udp_services keep state</programlisting>
       <sect3 xml:id="pftut-gateway">
 	<title>A Simple Gateway with NAT</title>
 
-	<para>To most users, a single machine setup will be of limited
+	<para>This section demonstrates how to configure a &os; system
-	  interest, and at this point we move on to more realistic or
-	  at least more common setups, concentrating on a machine
 	  which is running <application>PF</application> and also acts
-	  as a gateway for at least one other machine.</para>
+	  as a gateway for at least one other machine.  The gateway
+	  has at least two network interfaces, each connected to a
+	  separate network.  For example, one connection is to the
+	  Internet and the other is to the internal network.</para>
 
-	  <para>In the single machine setup, life is relatively
+	  <para>It is reasonable to think that for stateful traffic to
-	    simple.  Traffic created on it should either pass out to
-	    the rest of the world or not, and the administrator
-	    decides what to let in from elsewhere.</para>
-
-	  <para>On a gateway, the perspective changes from
-	    <quote>me versus the network out there</quote> to
-	    <quote>I am the one who decides what to pass to or from
-	      all the networks I am connected to</quote>.  The machine
-	    has at least two network interfaces, each connected to a
-	    separate net.</para>
-
-	  <para>It is very reasonable to think that for traffic to
 	    pass from the network connected to
 	    <filename>xl1</filename> to hosts on the network
 	    connected to <filename>xl0</filename>, a rule like
@@ -654,46 +643,32 @@ pass proto udp to any port $udp_services keep state</programlisting>
 
 	  <programlisting>pass in on xl1 from xl1:network to xl0:network port $ports keep state</programlisting>
 
-	  <para>This rule keeps track of states as well.</para>
+	  <para>However, the <quote>to</quote> keyword does
-
+	    guarantee passage all the way from source to destination.  This rule
-	  <para>However, one of the most common and most
+	    only lets the traffic pass in to the gateway on
-	    complained-about mistakes in firewall configuration is not
+	    the internal interface.  To let the packets go
-	    realizing that the <quote>to</quote> keyword does not in
+	    further, a matching rule is needed:</para>
-	    itself guarantee passage all the way there.  The rule we
-	    just wrote only lets the traffic pass in to the gateway on
-	    the internal interface.  To let the packets get a bit
-	    further, a matching rule is needed which says</para>
 
 	  <programlisting>pass out on xl0 from xl1:network to xl0:network port $ports keep state</programlisting>
 
 	  <para>These rules will work, but they will not necessarily
 	    achieve the desired effect.</para>
 
-	  <para>Rules this specific are rarely needed.  For the basic
+	  <para>Rules this specific are rarely needed.  A
-	    gateway configurations we will be dealing with here, a
+	    better rule says:</para>
-	    better rule says</para>
 
 	  <programlisting>pass from xl1:network to any port $ports keep state</programlisting>
 
-	  <para>This provides local net access to the Internet and
+	  <para>This provides local network access to the Internet and
 	    leaves the detective work to the
 	    <firstterm>antispoof</firstterm> and
-	    <firstterm>scrub</firstterm> code.  They are both pretty
+	    <firstterm>scrub</firstterm> code.</para>
-	    good these days, and we will get back to them later.  For
-	    now we just accept the fact that for simple setups,
-	    interface-bound rules with in/out rules tend to add more
-	    clutter than they are worth to rulesets.</para>
 
 	  <para>For a busy network admin, a readable ruleset is a
-	    safer ruleset.</para>
+	    safer ruleset.  For the remainder of this section, with some
-
-	  <para>For the remainder of this section, with some
 	    exceptions, we will keep the rules as simple as possible
 	    for readability.</para>
 
-	<sect4 xml:id="pftut-whatsthelocalnet">
-	  <title>What is the Local Network, Anyway?</title>
-
 	  <para>Above, we introduced the
 	    <literal>interface:network</literal> notation.  That is a
 	    nice piece of shorthand, but the ruleset can be made even
@@ -720,21 +695,6 @@ pass proto udp to any port $udp_services keep state</programlisting>
 
 	  <para>could end up saving you a few headaches.  We will
 	    stick to that convention from here on.</para>
-	</sect4>
-
-	<sect4 xml:id="pftut-gwsimplesetup">
-	  <title>Setting Up</title>
-
-	  <para>We assume that the machine has acquired another
-	    network card or at any rate there is a network
-	    connection from the local network, via PPP or other
-	    means.  We will not consider the specific interface
-	    configurations.</para>
-
-	  <para>For the discussion and examples below, only the
-	    interface names will differ between a PPP setup and an
-	    Ethernet one, and we will do our best to get rid of the
-	    actual interface names as quickly as possible.</para>
 
 	  <para>First, we need to turn on gatewaying in order to let
 	    the machine forward the network traffic it receives on one
@@ -820,25 +780,13 @@ pass from { lo0, $localnet } to any keep state</programlisting>
 	  <programlisting>pass inet proto tcp from $localnet to any port $client_out \
     flags S/SA keep state</programlisting>
 
-	  <para>This may be a somewhat peculiar selection of ports,
+	  <para>In addition, we have a few other pass rules. One pass rule which is useful for
-	    but it is based on a real life example.  Individual needs
+	    administering machines remotely
-	    probably differ at least in some specifics, but this
+	    is:</para>
-	    should cover at least some of the more useful
-	    services.</para>
-
-	  <para>In addition, we have a few other pass rules.  We will
-	    be returning to some of the more interesting ones rather
-	    soon.  One pass rule which is useful to those of us who
-	    want the ability to administer our machines from elsewhere
-	    is</para>
-
-	  <programlisting>pass in inet proto tcp to port ssh</programlisting>
-
-	  <para>or for that matter</para>
 
 	  <programlisting>pass in inet proto tcp to $ext_if port ssh</programlisting>
 
-	  <para>whichever is preferred.  Lastly we need to make the
+	  <para>Lastly we need to make the
 	    name service work for our clients:</para>
 
 	  <programlisting>udp_services = "{ domain, ntp }"</programlisting>
@@ -870,11 +818,10 @@ pass from { lo0, $localnet } to any keep state</programlisting>
 	    to both protocols is that they may under certain
 	    circumstances communicate alternately over TCP and
 	    UDP.</para>
-	</sect4>
       </sect3>
 
       <sect3 xml:id="pftut-ftp">
-	<title>That Sad Old <acronym>FTP</acronym> Thing</title>
+	<title>Creating an <acronym>FTP</acronym> Proxy</title>
 
 	<para>The short list of real life <acronym>TCP</acronym> ports
 	  above contained, among other things, <acronym>FTP</acronym>.
@@ -923,10 +870,6 @@ pass from { lo0, $localnet } to any keep state</programlisting>
 	  program which is written specifically for this
 	  purpose.</para>
 
-	<sect4 xml:id="pftut-ftp-proxy">
-	  <title><acronym>FTP</acronym> Via Redirect:
-	    <application>ftp-proxy</application></title>
-
 	  <para>Enabling <acronym>FTP</acronym> transfers through your
 	    gateway is amazingly simple, thanks to the
 	    <acronym>FTP</acronym> proxy program (called
@@ -1015,11 +958,10 @@ rdr-anchor "ftp-proxy/*"</programlisting>
 	    <command>ftp-proxy</command> in reverse mode (using
 	    <option>-R</option>), on a separate port with its own
 	    redirecting pass rule.</para>
-	</sect4>
       </sect3>
 
       <sect3 xml:id="pftut-icmp">
-	<title>Easing Troubleshooting</title>
+	<title>Managing <acronym>ICMP</acronym></title>
 
 	<para>Making network troubleshooting friendly is a potentially
 	  large subject.  At most times, the debugging or
@@ -1069,9 +1011,6 @@ rdr-anchor "ftp-proxy/*"</programlisting>
 	  these rulesets have been around for roughly fifteen years,
 	  and the people who put them there are still scared.</para>
 
-	<sect4 xml:id="pftut-dowepass">
-	  <title>Then, Do We Let it All Through?</title>
-
 	  <para>The obvious question then becomes, if
 	    <acronym>ICMP</acronym> is such a good and useful thing,
 	    should we not let it all through, all the time?  The
@@ -1090,10 +1029,6 @@ rdr-anchor "ftp-proxy/*"</programlisting>
 	    <acronym>ICMP</acronym> traffic might be found quite
 	    harmlessly riding piggyback on
 	    <literal>keep state</literal> rules.</para>
-	</sect4>
-
-	<sect4 xml:id="pftut-icmpstopatgw">
-	  <title>The Easy Way Out: the Buck Stops Here</title>
 
 	  <para>The easiest solution could very well be to let all
 	    <acronym>ICMP</acronym> traffic from the local net through
@@ -1106,7 +1041,6 @@ pass inet proto icmp from any to $ext_if keep state</programlisting>
 	    option anyway, but let us have a look at a few other
 	    options which will show some of
 	    <application>PF</application>'s flexibility.</para>
-	</sect4>
 
 	<sect4 xml:id="pftut-letpingthru">
 	  <title>Letting <command>ping</command> Through</title>