Index: firewalls/chapter.xml
===================================================================
--- firewalls/chapter.xml	(revision 41427)
+++ firewalls/chapter.xml	(working copy)
@@ -89,11 +89,6 @@
 
       <listitem>
 	<para>How to use and configure the
-	  <application>IPFILTER</application> firewall.</para>
-      </listitem>
-
-      <listitem>
-	<para>How to use and configure the
 	  <application>IPFW</application> firewall.</para>
       </listitem>
     </itemizedlist>
@@ -152,9 +147,8 @@
   <sect1 id="firewalls-apps">
     <title>Firewall Packages</title>
 
-    <para>&os; has three firewalls built into the base system:
-      <emphasis>IPFILTER</emphasis>, also known as
-      <acronym>IPF</acronym>, <emphasis>IPFIREWALL</emphasis>, also
+    <para>&os; has two firewalls built into the base system:
+      <emphasis>IPFIREWALL</emphasis>, also
       known as <acronym>IPFW</acronym>, and <acronym>PF</acronym>).
       &os; also provides two traffic shapers for controlling bandwidth
       usage: &man.altq.4; and &man.dummynet.4;.  Dummynet has
@@ -480,1491 +474,6 @@
     </sect2>
   </sect1>
 
-  <sect1 id="firewalls-ipf">
-    <title>The IPFILTER (IPF) Firewall</title>
-
-    <indexterm>
-      <primary>firewall</primary>
-
-      <secondary>IPFILTER</secondary>
-    </indexterm>
-
-    <para>IPFILTER is a cross-platform, open source firewall which
-      has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and
-      &solaris; operating systems.</para>
-
-    <para>IPFILTER is based on a kernel-side firewall and
-      <acronym>NAT</acronym> mechanism that can be controlled and
-      monitored by userland interface programs.  The firewall rules
-      can be set or deleted using &man.ipf.8;.  The
-      <acronym>NAT</acronym> rules can be set or deleted using
-      &man.ipnat.8;.  Run-time statistics for the kernel parts of
-      IPFILTER can be printed using &man.ipfstat.8;.  To log IPFILTER
-      actions to the system log files, use &man.ipmon.8;.</para>
-
-    <para>IPF was originally written using a rule processing logic
-      of <quote>the last matching rule wins</quote> and only used
-      stateless rules.  Over time, IPF has been enhanced to include a
-      <quote>quick</quote> option and a stateful
-      <quote>keep state</quote> option which modernized the rules
-      processing logic.  IPF's official documentation covers only the
-      legacy rule coding parameters and rule file processing logic and
-      the modernized functions are only included as additional
-      options.</para>
-
-    <para>The instructions contained in this section are based on
-      using rules that contain <quote>quick</quote> and
-      <quote>keep state</quote> as these provide the basic framework
-      for configuring an inclusive firewall ruleset.</para>
-
-    <para>For a detailed explanation of the legacy rules processing
-      method, refer to <ulink
-	url="http://www.munk.me.uk/ipf/ipf-howto.html"></ulink>
-      and <ulink
-	url="http://coombs.anu.edu.au/~avalon/ip-filter.html"></ulink>.</para>
-
-    <para>The IPF FAQ is at <ulink
-	url="http://www.phildev.net/ipf/index.html"></ulink>.</para>
-
-    <para>A searchable archive of the IPFilter mailing list is
-      available at <ulink
-	url="http://marc.theaimsgroup.com/?l=ipfilter"></ulink>.</para>
-
-    <sect2>
-      <title>Enabling IPF</title>
-
-      <indexterm>
-	<primary>IPFILTER</primary>
-
-	<secondary>enabling</secondary>
-      </indexterm>
-
-      <para>IPF is included in the basic &os; install as a kernel
-	loadable module.  The system will dynamically load
-	this module at boot time when
-	<varname>ipfilter_enable="YES"</varname> is added to
-	<filename>rc.conf</filename>.  The module enables logging and
-	<literal>default pass all</literal>.  To change the
-	default to <literal>block all</literal>, add a
-	<literal>block all</literal> rule at the end of the
-	ruleset.</para>
-    </sect2>
-
-    <sect2>
-      <title>Kernel Options</title>
-
-      <indexterm>
-	<primary>kernel options</primary>
-
-	<secondary>IPFILTER</secondary>
-      </indexterm>
-
-      <indexterm>
-	<primary>kernel options</primary>
-
-	<secondary>IPFILTER_LOG</secondary>
-      </indexterm>
-
-      <indexterm>
-	<primary>kernel options</primary>
-
-	<secondary>IPFILTER_DEFAULT_BLOCK</secondary>
-      </indexterm>
-
-      <indexterm>
-	<primary>IPFILTER</primary>
-
-	<secondary>kernel options</secondary>
-      </indexterm>
-
-      <para>For users who prefer to statically compile IPF support
-	into a custom kernel, the following IPF option statements,
-	listed in <filename>/usr/src/sys/conf/NOTES</filename>, are
-	available:</para>
-
-      <programlisting>options IPFILTER
-options IPFILTER_LOG
-options IPFILTER_DEFAULT_BLOCK</programlisting>
-
-      <para><literal>options IPFILTER</literal> enables support for
-	the <quote>IPFILTER</quote> firewall.</para>
-
-      <para><literal>options IPFILTER_LOG</literal> enables IPF
-	logging using the <devicename>ipl</devicename> packet logging
-	pseudo&mdash;device for every rule that has the
-	<literal>log</literal> keyword.</para>
-
-      <para><literal>options IPFILTER_DEFAULT_BLOCK</literal> changes
-	the default behavior so that any packet not matching a
-	firewall <literal>pass</literal> rule gets blocked.</para>
-
-      <para>These settings will take effect only after installing a
-	kernel that has been built with the above options set.</para>
-    </sect2>
-
-    <sect2>
-      <title>Available <filename>rc.conf</filename> Options</title>
-
-      <para>To activate IPF at boot time, the following statements
-	need to be added to <filename>/etc/rc.conf</filename>:</para>
-
-      <programlisting>ipfilter_enable="YES"             # Start ipf firewall
-ipfilter_rules="/etc/ipf.rules"   # loads rules definition text file
-ipmon_enable="YES"                # Start IP monitor log
-ipmon_flags="-Ds"                 # D = start as daemon
-                                  # s = log to syslog
-                                  # v = log tcp window, ack, seq
-                                  # n = map IP &amp; port to names</programlisting>
-
-      <para>If there is a LAN behind the firewall that uses the
-	reserved private IP address ranges, the following lines have
-	to be added to enable <acronym>NAT</acronym>
-	functionality:</para>
-
-      <programlisting>gateway_enable="YES"              # Enable as LAN gateway
-ipnat_enable="YES"                # Start ipnat function
-ipnat_rules="/etc/ipnat.rules"    # rules definition file for ipnat</programlisting>
-    </sect2>
-
-    <sect2>
-      <title>IPF</title>
-
-      <indexterm><primary><command>ipf</command></primary></indexterm>
-
-      <para>To load the ruleset file, use &man.ipf.8;.  Custom rules
-	are normally placed in a file, and the following command can
-	be used to replace the currently running firewall
-	rules:</para>
-
-      <screen>&prompt.root; <userinput>ipf -Fa -f /etc/ipf.rules</userinput></screen>
-
-      <para><option>-Fa</option> flushes all the internal rules
-	tables.</para>
-
-      <para><option>-f</option> specifies the file containing the
-	rules to load.</para>
-
-      <para>This provides the ability to make changes to a custom
-	rules file, run the above IPF command, and thus update the
-	running firewall with a fresh copy of the rules without having
-	to reboot the system.  This method is convenient for testing
-	new rules as the procedure can be executed as many times as
-	needed.</para>
-
-      <para>Refer to &man.ipf.8; for details on the other flags
-	available with this command.</para>
-
-      <para>&man.ipf.8; expects the rules file to be a standard text
-	file.  It will not accept a rules file written as a script
-	with symbolic substitution.</para>
-
-      <para>There is a way to build IPF rules that utilize the power
-	of script symbolic substitution.  For more information, see
-	<link linkend="firewalls-ipf-rules-script"></link>.</para>
-    </sect2>
-
-    <sect2>
-      <title>IPFSTAT</title>
-
-      <indexterm><primary><command>ipfstat</command></primary></indexterm>
-
-      <indexterm>
-	<primary>IPFILTER</primary>
-
-	<secondary>statistics</secondary>
-      </indexterm>
-
-      <para>The default behavior of &man.ipfstat.8; is to retrieve
-	and display the totals of the accumulated statistics gathered
-	by applying the rules against packets going in and out of the
-	firewall since it was last started, or since the last time the
-	accumulators were reset to zero using <command>ipf
-	  -Z</command>.</para>
-
-      <para>Refer to &man.ipfstat.8; for details.</para>
-
-      <para>The default &man.ipfstat.8; output will look something
-	like this:</para>
-
-      <screen>input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0
- output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0
- input packets logged: blocked 99286 passed 0
- output packets logged: blocked 0 passed 0
- packets logged: input 0 output 0
- log failures: input 3898 output 0
- fragment state(in): kept 0 lost 0
- fragment state(out): kept 0 lost 0
- packet state(in): kept 169364 lost 0
- packet state(out): kept 431395 lost 0
- ICMP replies: 0 <acronym>TCP</acronym> RSTs sent: 0
- Result cache hits(in): 1215208 (out): 1098963
- IN Pullups succeeded: 2 failed: 0
- OUT Pullups succeeded: 0 failed: 0
- Fastroute successes: 0 failures: 0
- <acronym>TCP</acronym> cksum fails(in): 0 (out): 0
- Packet log flags set: (0)</screen>
-
-      <para>When supplied with either <option>-i</option> for inbound
-	or <option>-o</option> for outbound, the command will retrieve
-	and display the appropriate list of filter rules currently
-	installed and in use by the kernel.</para>
-
-      <para><command>ipfstat -in</command> displays the inbound
-	internal rules table with rule numbers.</para>
-
-      <para><command>ipfstat -on</command> displays the outbound
-	internal rules table with rule numbers.</para>
-
-      <para>The output will look something like this:</para>
-
-      <screen>@1 pass out on xl0 from any to any
-@2 block out on dc0 from any to any
-@3 pass out quick on dc0 proto tcp/udp from any to any keep state</screen>
-
-      <para><command>ipfstat -ih</command> displays the inbound
-	internal rules table, prefixing each rule with a count of how
-	many times the rule was matched.</para>
-
-      <para><command>ipfstat -oh</command> displays the outbound
-	internal rules table, prefixing each rule with a count of how
-	many times the rule was matched.</para>
-
-      <para>The output will look something like this:</para>
-
-      <screen>2451423 pass out on xl0 from any to any
-354727 block out on dc0 from any to any
-430918 pass out quick on dc0 proto tcp/udp from any to any keep state</screen>
-
-      <para>One of the most important options of
-	<command>ipfstat</command> is <option>-t</option> which
-	displays the state table in a way similar to how &man.top.1;
-	shows the &os; running process table.  When a firewall is
-	under attack, this function provides the ability to identify
-	and see the attacking packets.  The optional sub-flags give
-	the ability to select the destination or source IP, port, or
-	protocol to be monitored in real time.  Refer to
-	&man.ipfstat.8; for details.</para>
-    </sect2>
-
-    <sect2>
-      <title>IPMON</title>
-
-      <indexterm><primary><command>ipmon</command></primary></indexterm>
-
-      <indexterm>
-	<primary>IPFILTER</primary>
-
-	<secondary>logging</secondary>
-      </indexterm>
-
-      <para>In order for <command>ipmon</command> to work properly,
-	the kernel option <literal>IPFILTER_LOG</literal> must be
-	turned on.  This command has two different modes.  Native mode
-	is the default mode when the command is used without
-	<option>-D</option>.</para>
-
-      <para>Daemon mode provides a continuous system log file so that
-	logging of past events may be reviewed.  &os; has a built in
-	facility to automatically rotate system logs.  This is why
-	outputting the log information to &man.syslogd.8; is better
-	than the default of outputting to a regular file.  The default
-	<filename>rc.conf</filename>
-	<literal>ipmon_flags</literal> statement uses
-	<option>-Ds</option>:</para>
-
-      <programlisting>ipmon_flags="-Ds" # D = start as daemon
-                  # s = log to syslog
-                  # v = log tcp window, ack, seq
-                  # n = map IP &amp; port to names</programlisting>
-
-      <para>Logging provides the ability to review, after the fact,
-	information such as which packets were dropped, what addresses
-	they came from and where they were going.  These can all
-	provide a significant edge in tracking down attackers.</para>
-
-      <para>Even with the logging facility enabled, IPF will not
-	generate any rule logging by default.  The firewall
-	administrator decides which rules in the ruleset should be
-	logged and adds the log keyword to those rules.  Normally,
-	only deny rules are logged.</para>
-
-      <para>It is customary to include a <quote>default deny
-	  everything</quote> rule with the log keyword included as the
-	last rule in the ruleset.  This makes it possible to see all
-	the packets that did not match any of the rules in the
-	ruleset.</para>
-    </sect2>
-
-    <sect2>
-      <title>IPMON Logging</title>
-
-      <para>&man.syslogd.8; uses its own method for segregation of log
-	data.  It uses groupings called <quote>facility</quote> and
-	<quote>level</quote>.  By default, IPMON in
-	<option>-Ds</option> mode uses <literal>local0</literal> as
-	the <quote>facility</quote> name.  The following levels can be
-	used to further segregate the logged data:</para>
-
-      <screen>LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block.
-LOG_NOTICE - packets logged which are also passed
-LOG_WARNING - packets logged which are also blocked
-LOG_ERR - packets which have been logged and which can be considered short</screen>
-
-      <!-- XXX: "can be considered short" == "with incomplete header" -->
-
-      <para>In order to setup IPFILTER to log all data to
-	<filename>/var/log/ipfilter.log</filename>, first
-	create the empty file:</para>
-
-       <screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen>
-
-      <para>&man.syslogd.8; is controlled by definition statements in
-	<filename>/etc/syslog.conf</filename>.  This file offers
-	considerable flexibility in how
-	<application>syslog</application> will deal with system
-	messages issued by software applications like IPF.</para>
-
-      <para>To write all logged messages to the specified file,
-	add the following statement to
-	<filename>/etc/syslog.conf</filename>:</para>
-
-      <programlisting>local0.* /var/log/ipfilter.log</programlisting>
-
-      <para>To activate the changes and instruct &man.syslogd.8;
-	to read the modified <filename>/etc/syslog.conf</filename>,
-	run <command>service syslogd reload</command>.</para>
-
-      <para>Do not forget to change
-	<filename>/etc/newsyslog.conf</filename> to rotate the new
-	log file.</para>
-    </sect2>
-
-    <sect2>
-      <title>The Format of Logged Messages</title>
-
-      <para>Messages generated by <command>ipmon</command> consist
-	of data fields separated by white space.  Fields common to
-	all messages are:</para>
-
-      <orderedlist>
-	<listitem>
-	  <para>The date of packet receipt.</para>
-	</listitem>
-
-	<listitem>
-	  <para>The time of packet receipt.  This is in the form
-	    HH:MM:SS.F, for hours, minutes, seconds, and fractions
-	    of a second.</para>
-	</listitem>
-
-	<listitem>
-	  <para>The name of the interface that processed the
-	    packet.</para>
-	</listitem>
-
-	<listitem>
-	  <para>The group and rule number of the rule in the format
-	    <literal>@0:17</literal>.</para>
-	</listitem>
-      </orderedlist>
-
-      <para>These can be viewed with
-	<command>ipfstat -in</command>.</para>
-
-      <orderedlist>
-	<listitem>
-	  <para>The action: <literal>p</literal> for passed,
-	    <literal>b</literal> for blocked, <literal>S</literal> for
-	    a short packet, <literal>n</literal> did not match any
-	    rules, and <literal>L</literal> for a log rule.  The order
-	    of precedence in showing flags is: <literal>S</literal>,
-	    <literal>p</literal>, <literal>b</literal>,
-	    <literal>n</literal>, <literal>L</literal>.  A capital
-	    <literal>P</literal> or <literal>B</literal> means that
-	    the packet has been logged due to a global logging
-	    setting, not a particular rule.</para>
-	</listitem>
-
-	<listitem>
-	  <para>The addresses written as three fields: the source
-	    address and port separated by a comma, the -&gt; symbol,
-	    and the destination address and port.  For example:
-	    <literal>209.53.17.22,80 -&gt;
-	      198.73.220.17,1722</literal>.</para>
-	</listitem>
-
-	<listitem>
-	  <para><literal>PR</literal> followed by the protocol name
-	    or number: for example, <literal>PR tcp</literal>.</para>
-	</listitem>
-
-	<listitem>
-	  <para><literal>len</literal> followed by the header length
-	    and total length of the packet: for example,
-	    <literal>len 20 40</literal>.</para>
-	</listitem>
-      </orderedlist>
-
-      <para>If the packet is a <acronym>TCP</acronym> packet, there
-	will be an additional field starting with a hyphen followed by
-	letters corresponding to any flags that were set.  Refer to
-	&man.ipf.5; for a list of letters and their flags.</para>
-
-      <para>If the packet is an ICMP packet, there will be two fields
-	at the end:  the first always being <quote>ICMP</quote> and
-	the next being the ICMP message and sub-message type,
-	separated by a slash.  For example:  ICMP 3/3 for a port
-	unreachable message.</para>
-    </sect2>
-
-    <sect2 id="firewalls-ipf-rules-script">
-      <title>Building the Rule Script with Symbolic
-	Substitution</title>
-
-      <para>Some experienced IPF users create a file containing the
-	rules and code them in a manner compatible with running them
-	as a script with symbolic substitution.  The major benefit
-	of doing this is that only the value associated with the
-	symbolic name needs to be changed, and when the script is
-	run all the rules containing the symbolic name will have the
-	value substituted in the rules.  Being a script, symbolic
-	substitution can be used to code frequently used values and
-	substitute them in multiple rules.  This can be seen in the
-	following example.</para>
-
-      <para>The script syntax used here is compatible with the
-	&man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells.</para>
-
-      <para>Symbolic substitution fields are prefixed with a
-	<literal>&dollar;</literal>.</para>
-
-      <para>Symbolic fields do not have the &dollar; prefix.</para>
-
-      <para>The value to populate the symbolic field must be enclosed
-	between double quotes (<literal>"</literal>).</para>
-
-      <para>Start the rule file with something like this:</para>
-
-      <programlisting>############# Start of IPF rules script ########################
-
-oif="dc0"            # name of the outbound interface
-odns="192.0.2.11"    # ISP's DNS server IP address
-myip="192.0.2.7"     # my static IP address from ISP
-ks="keep state"
-fks="flags S keep state"
-
-# You can choose between building /etc/ipf.rules file
-# from this script or running this script "as is".
-#
-# Uncomment only one line and comment out another.
-#
-# 1) This can be used for building /etc/ipf.rules:
-#cat &gt; /etc/ipf.rules &lt;&lt; EOF
-#
-# 2) This can be used to run script "as is":
-/sbin/ipf -Fa -f - &lt;&lt; EOF
-
-# Allow out access to my ISP's Domain name server.
-pass out quick on &dollar;oif proto tcp from any to &dollar;odns port = 53 &dollar;fks
-pass out quick on &dollar;oif proto udp from any to &dollar;odns port = 53 &dollar;ks
-
-# Allow out non-secure standard www function
-pass out quick on &dollar;oif proto tcp from &dollar;myip to any port = 80 &dollar;fks
-
-# Allow out secure www function https over TLS SSL
-pass out quick on &dollar;oif proto tcp from &dollar;myip to any port = 443 &dollar;fks
-EOF
-################## End of IPF rules script ########################</programlisting>
-
-      <para>The rules are not important in this example as it instead
-	focuses on how the symbolic substitution fields are populated.
-	If this example was in a file named
-	<filename>/etc/ipf.rules.script</filename>, these rules could
-	be reloaded by running:</para>
-
-      <screen>&prompt.root; <userinput>sh /etc/ipf.rules.script</userinput></screen>
-
-      <para>There is one problem with using a rules file with embedded
-	symbolics: IPF does not understand symbolic substitution, and
-	cannot read such scripts directly.</para>
-
-      <para>This script can be used in one of two ways:</para>
-
-      <itemizedlist>
-	<listitem>
-	  <para>Uncomment the line that begins with
-	    <literal>cat</literal>, and comment out the line that
-	    begins with <literal>/sbin/ipf</literal>.  Place
-	    <literal>ipfilter_enable="YES"</literal> into
-	    <filename>/etc/rc.conf</filename>, and run the script
-	    once after each modification to create or update
-	    <filename>/etc/ipf.rules</filename>.</para>
-	</listitem>
-
-	<listitem>
-	  <para>Disable IPFILTER in the system startup scripts by
-	    adding <literal>ipfilter_enable="NO"</literal>to
-	    <filename>/etc/rc.conf</filename>.</para>
-
-	  <para>Then, add a script like the following to <filename
-	      class="directory">/usr/local/etc/rc.d/</filename>.
-	    The script should have an obvious name like
-	    <filename>ipf.loadrules.sh</filename>, where the
-	    <filename>.sh</filename> extension is mandatory.</para>
-
-	  <programlisting>#!/bin/sh
-sh /etc/ipf.rules.script</programlisting>
-
-	  <para>The permissions on this script file must be read,
-	    write, execute for owner <username>root</username>:</para>
-
-	  <screen>&prompt.root; <userinput>chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh</userinput></screen>
-	</listitem>
-      </itemizedlist>
-
-      <para>Now, when the system boots, the IPF rules will be
-	loaded.</para>
-    </sect2>
-
-    <sect2>
-      <title>IPF Rulesets</title>
-
-      <para>A ruleset contains a group of IPF rules which pass or
-	block packets based on the values contained in the packet.
-	The bi-directional exchange of packets between hosts comprises
-	a session conversation.  The firewall ruleset processes both
-	the packets arriving from the public Internet, as well as the
-	packets produced by the system as a response to them.
-	Each <acronym>TCP/IP</acronym> service is predefined by its
-	protocol and listening port.  Packets destined for a specific
-	service originate from the source address using an
-	unprivileged port and target the specific service port on the
-	destination address.  All the above parameters can be used as
-	selection criteria to create rules which will pass or block
-	services.</para>
-
-      <indexterm>
-	<primary>IPFILTER</primary>
-
-	<secondary>rule processing order</secondary>
-      </indexterm>
-
-      <warning>
-	<para>When working with the firewall rules, be <emphasis>very
-	    careful</emphasis>.  Some configurations <emphasis>can
-	  lock the administrator out</emphasis> of the server.  To be
-	  on the safe side, consider performing the initial firewall
-	  configuration from the local console rather than doing it
-	  remotely over <application>ssh</application>.</para>
-      </warning>
-    </sect2>
-
-    <sect2>
-      <title>Rule Syntax</title>
-
-      <indexterm>
-	<primary>IPFILTER</primary>
-
-	<secondary>rule syntax</secondary>
-      </indexterm>
-
-      <para>The rule syntax presented here has been simplified to
-	only address the modern stateful rule context and <quote>first
-	matching rule wins</quote> logic.  For the complete legacy
-	rule syntax, refer to &man.ipf.8;.</para>
-
-      <para>A <literal>#</literal> character is used to mark the
-	start of a comment and may appear at the end of a rule line
-	or on its own line.  Blank lines are ignored.</para>
-
-      <para>Rules contain keywords which must be written in a specific
-	order from left to right on the line.  Keywords are identified
-	in bold type.  Some keywords have sub-options which may be
-	keywords themselves and also include more sub-options.  Each
-	of the headings in the below syntax has a bold section header
-	which expands on the content.</para>
-
-      <!-- This section is probably wrong. See the OpenBSD flag -->
-      <!-- What is the "OpenBSD flag"?  Reference please -->
-
-      <para><replaceable>ACTION IN-OUT OPTIONS SELECTION STATEFUL
-	  PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG
-	  STATEFUL</replaceable></para>
-
-      <para><replaceable>ACTION</replaceable> = block | pass</para>
-
-      <para><replaceable>IN-OUT</replaceable> = in | out</para>
-
-      <para><replaceable>OPTIONS</replaceable> = log | quick | on
-	interface-name</para>
-
-      <para><replaceable>SELECTION</replaceable> = proto value |
-	source/destination IP | port = number | flags
-	flag-value</para>
-
-      <para><replaceable>PROTO</replaceable> = tcp/udp | udp | tcp |
-	icmp</para>
-
-      <para><replaceable>SRC_ADD,DST_ADDR</replaceable> = all | from
-	object to object</para>
-
-      <para><replaceable>OBJECT</replaceable> = IP address |
-	any</para>
-
-      <para><replaceable>PORT_NUM</replaceable> = port number</para>
-
-      <para><replaceable>TCP_FLAG</replaceable> = S</para>
-
-      <para><replaceable>STATEFUL</replaceable> = keep state</para>
-
-      <sect3>
-	<title>ACTION</title>
-
-	<para>The action keyword indicates what to do with the packet
-	  if it matches the rest of the filter rule.  Each rule
-	  <emphasis>must</emphasis> have an action.  The following
-	  actions are recognized:</para>
-
-	<para><literal>block</literal> indicates that the packet
-	  should be dropped if the selection parameters match the
-	  packet.</para>
-
-	<para><literal>pass</literal> indicates that the packet should
-	  exit the firewall if the selection parameters match the
-	  packet.</para>
-      </sect3>
-
-      <sect3>
-	<title>IN-OUT</title>
-
-	<para>A mandatory requirement is that each filter rule
-	  explicitly state which side of the I/O it is to be used
-	  on.  The next keyword must be either <literal>in</literal>
-	  or <literal>out</literal> and one or the other has to be
-	  included or the rule will not pass syntax checks.</para>
-
-	<para><literal>in</literal> means this rule is being applied
-	  against an inbound packet which has just been received on
-	  the interface facing the public Internet.</para>
-
-	<para><literal>out</literal> means this rule is being applied
-	  against an outbound packet destined for the interface facing
-	  the public Internet.</para>
-      </sect3>
-
-      <sect3>
-	<title>OPTIONS</title>
-
-	<note>
-	  <para>These options must be used in the order shown
-	    here.</para>
-	</note>
-
-	<para><literal>log</literal> indicates that the packet header
-	  will be written to the &man.ipl.4; packet log pseudo-device
-	  if the selection parameters match the packet.</para>
-
-	<para><literal>quick</literal> indicates that if the selection
-	  parameters match the packet, this rule will be the last
-	  rule checked, and no further processing of any following
-	  rules will occur for this packet.</para>
-
-	<para><literal>on</literal> indicates the interface name to
-	  be incorporated into the selection parameters.  Interface
-	  names are as displayed by &man.ifconfig.8;.  Using this
-	  option, the rule will only match if the packet is going
-	  through that interface in the specified direction.</para>
-
-	<para>When a packet is logged, the headers of the packet are
-	  written to the &man.ipl.4; packet logging pseudo-device.
-	  Immediately following the <literal>log</literal> keyword,
-	  the following qualifiers may be used in this order:</para>
-
-	<para><literal>body</literal> indicates that the first 128
-	  bytes of the packet contents will be logged after the
-	  headers.</para>
-
-	<para><literal>first</literal>.  If the <literal>log</literal>
-	  keyword is being used in conjunction with a <literal>keep
-	    state</literal> option, this option is recommended so that
-	  only the triggering packet is logged and not every packet
-	  which matches the stateful connection.</para>
-      </sect3>
-
-      <sect3>
-	<title>SELECTION</title>
-
-	<para>The keywords described in this section are used to
-	  describe attributes of the packet to be checked when
-	  determining whether or not rules match.  There is a
-	  keyword subject, and it has sub-option keywords, one of
-	  which has to be selected.  The following general-purpose
-	  attributes are provided for matching, and must be used in
-	  this order:</para>
-      </sect3>
-
-      <sect3>
-	<title>PROTO</title>
-
-	<para><literal>proto</literal> is the subject keyword which
-	  must include one of its corresponding keyword sub-option
-	  values.  The sub-option indicates a specific protocol to be
-	  matched against.</para>
-
-	<para><literal>tcp/udp | udp | tcp | icmp</literal> or any
-	  protocol names found in <filename>/etc/protocols</filename>
-	  are recognized and may be used.  The special protocol
-	  keyword <literal>tcp/udp</literal> may be used to match
-	  either a <acronym>TCP</acronym> or a <acronym>UDP</acronym>
-	  packet, and has been added as a convenience to save
-	  duplication of otherwise identical rules.</para>
-      </sect3>
-
-      <sect3>
-	<title>SRC_ADDR/DST_ADDR</title>
-
-	<para>The <literal>all</literal> keyword is equivalent to
-	  <quote>from any to any</quote> with no other match
-	  parameters.</para>
-
-	<para><literal>from | to src to dst</literal>: the
-	  <literal>from</literal> and <literal>to</literal>
-	  keywords are used to match against IP addresses.  Rules
-	  must specify <emphasis>both</emphasis> the source and
-	  destination parameters.  <literal>any</literal> is a special
-	  keyword that matches any IP address.  Examples include:
-	  <literal>from any to any</literal>, <literal>from 0.0.0.0/0
-	    to any</literal>, <literal>from any to
-	    0.0.0.0/0</literal>, <literal>from 0.0.0.0 to
-	    any</literal>, and <literal>from any to
-	    0.0.0.0</literal>.</para>
-
-	<para>There is no way to match ranges of IP addresses which
-	  do not express themselves easily using the dotted numeric
-	  form / mask-length notation.  The <filename
-	    role="package">net-mgmt/ipcalc</filename> port may be
-	  used to ease the calculation.  Additional information
-	  is available at the utility's web page: <ulink
-	    url="http://jodies.de/ipcalc"></ulink>.</para>
-      </sect3>
-
-      <sect3>
-	<title>PORT</title>
-
-	<para>If a port match is included, for either or both of
-	  source and destination, it is only applied to
-	  <acronym>TCP</acronym> and <acronym>UDP</acronym> packets.
-	  When composing port comparisons, either the service name
-	  from <filename>/etc/services</filename> or an integer port
-	  number may be used.  When the port appears as part of the
-	  <literal>from</literal> object, it matches the source port
-	  number.  When it appears as part of the
-	  <literal>to</literal> object, it matches the destination
-	  port number.  An example usage is <literal>from any to any
-	    port = 80</literal></para>
-
-	<para>Single port comparisons may be done in a number of ways,
-	  using a number of different comparison operators.  Instead
-	  of the <literal>=</literal> shown in the example above,
-	  the following operators may be used: <literal>!=</literal>,
-	  <literal>&lt;</literal>, <literal>&gt;</literal>,
-	  <literal>&lt;=</literal>, <literal>&gt;=</literal>,
-	  <literal>eq</literal>, <literal>ne</literal>,
-	  <literal>lt</literal>, <literal>gt</literal>,
-	  <literal>le</literal>, and <literal>ge</literal>.</para>
-
-	<para>To specify port ranges, place the two port numbers
-	  between <literal>&lt;&gt;</literal> or
-	  <literal>&gt;&lt;</literal></para>
-      </sect3>
-
-      <sect3>
-	<title><acronym>TCP</acronym>_FLAG</title>
-
-	<para>Flags are only effective for <acronym>TCP</acronym>
-	  filtering.  The letters represent one of the possible flags
-	  that can be matched against the <acronym>TCP</acronym>
-	  packet header.</para>
-
-	<para>The modernized rules processing logic uses the
-	  <literal>flags S</literal> parameter to identify the TCP
-	  session start request.</para>
-      </sect3>
-
-      <sect3>
-	<title>STATEFUL</title>
-
-	<para><literal>keep state</literal> indicates that on a pass
-	  rule, any packets that match the rules selection parameters
-	  should activate the stateful filtering facility.</para>
-      </sect3>
-    </sect2>
-
-    <sect2>
-      <title>Stateful Filtering</title>
-
-      <indexterm>
-	<primary>IPFILTER</primary>
-
-	<secondary>stateful filtering</secondary>
-      </indexterm>
-
-      <!-- XXX: duplicated -->
-
-      <para>Stateful filtering treats traffic as a bi-directional
-	exchange of packets comprising a session.  When activated,
-	<literal>keep-state</literal> dynamically generates
-	internal rules for each anticipated packet being exchanged
-	during the session.  It has sufficient matching capabilities
-	to determine if a packet is valid for a session.  Any packets
-	that do not properly fit the session template are
-	automatically rejected.</para>
-
-      <para>IPF stateful filtering will also allow
-	<acronym>ICMP</acronym> packets related to an existing
-	<acronym>TCP</acronym> or <acronym>UDP</acronym> session.  So,
-	if an <acronym>ICMP</acronym> type 3 code 4 packet is a
-	response in a session started by a keep state rule, it will
-	automatically be allowed.  Any packet that IPF can be certain
-	is part of an active session, even if it is a different
-	protocol, will be allowed.</para>
-
-      <para>Packets destined to go out through the interface connected
-	to the public Internet are first checked against the dynamic
-	state table.  If the packet matches the next expected packet
-	comprising an active session conversation, it exits the
-	firewall and the state of the session conversation flow is
-	updated in the dynamic state table.  Packets that do not
-	belong to an already active session, are checked against the
-	outbound ruleset.</para>
-
-      <para>Packets coming in from the interface connected to the
-	public Internet are first checked against the dynamic state
-	table.  If the packet matches the next expected packet
-	comprising an active session, it exits the firewall and the
-	state of the session conversation flow is updated in the
-	dynamic state table.  Packets that do not belong to an already
-	active session, are checked against the inbound
-	ruleset.</para>
-
-      <para>When the session completes, it is removed from the
-	dynamic state table.</para>
-
-      <para>Stateful filtering allows one to focus on blocking/passing
-	new sessions.  If the new session is passed, all its
-	subsequent packets are allowed automatically and any impostor
-	packets are automatically rejected.  If a new session is
-	blocked, none of its subsequent packets are allowed.  Stateful
-	filtering provides advanced matching abilities capable of
-	defending against the flood of different attack methods
-	employed by attackers.</para>
-    </sect2>
-
-    <sect2>
-      <!-- XXX: This section needs a rewrite -->
-
-      <title>Inclusive Ruleset Example</title>
-
-      <para>The following ruleset is an example of an inclusive type
-	of firewall which only allows services matching
-	<literal>pass</literal> rules and blocks all others by
-	default.  Network firewalls intended to protect other machines
-	should have at least two interfaces, and are generally
-	configured to trust the <acronym>LAN</acronym> and to not
-	trust the public Internet.  Alternatively, a host based
-	firewall might be configured to protect only the system it is
-	running on, and is appropriate for servers on an untrusted
-	network or a desktop system not protected by firewall on the
-	network.</para>
-
-      <para>&os; uses interface <devicename>lo0</devicename> and IP
-	address <hostid role="ipaddr">127.0.0.1</hostid> for internal
-	communication within the operating system.  The firewall rules
-	must contain rules to allow free movement of these internally
-	used packets.</para>
-
-      <para>The interface which faces the public Internet is the one
-	specified in the rules that authorize and control access of
-	the outbound and inbound connections.</para>
-
-      <para>In cases where one or more NICs are cabled to private
-	network segments, those interfaces may require rules to allow
-	packets originating from those LAN interfaces transit to each
-	other or to the Internet.</para>
-
-      <para>The rules should be organized into three major
-	sections: the trusted interfaces, then the public
-	interface outbound, and lastly, the public untrusted interface
-	inbound.</para>
-
-      <para>The rules in each of the public interface sections should
-	have the most frequently matched rules placed before less
-	commonly matched rules, with the last rule in the section
-	blocking and logging all packets on that interface and
-	direction.</para>
-
-      <para>The outbound section in the following ruleset only
-	contains <literal>pass</literal> rules which uniquely identify
-	the services that are authorized for public Internet access.
-	All the rules use <literal>quick</literal>,
-	<literal>on</literal>, <literal>proto</literal>,
-	<literal>port</literal>, and <literal>keep state</literal>.
-	The <literal>proto tcp</literal> rules include
-	<literal>flag</literal> to identify the session start request
-	as the triggering packet to activate the stateful
-	facility.</para>
-
-      <para>The inbound section blocks undesirable packets first, for
-	two different reasons.  The first is that malicious packets
-	may be partial matches for legitimate traffic.  These packets
-	have to be discarded rather than allowed, based on their
-	partial matches against the <literal>allow</literal> rules.
-	The second reason is that known and uninteresting rejects may
-	be blocked silently, rather than being logged by the last rule
-	in the section.</para>
-
-      <para>The ruleset should ensure that there is no response
-	returned for any undesirable traffic.  Invalid packets should
-	be silently dropped so that the attacker has no knowledge if
-	the packets reached the system.  Rules that include a
-	<literal>log first</literal> option, will only log the event
-	the first time they are triggered.  This option is included in
-	the sample <literal>nmap OS fingerprint</literal> rule.  The
-	<filename role="package">security/nmap</filename> utility is
-	commonly used by attackers who attempt to identify the
-	operating system of the server.</para>
-
-      <para>Any time there are logged messages on a rule with
-	the <literal>log first</literal> option,
-	<command>ipfstat -hio</command> should be executed
-	to evaluate how many times the rule has been matched.  A
-	large number of matches usually indicates that the system is
-	being flooded or is under attack.</para>
-
-      <para>To lookup unknown port numbers, refer to
-	<filename>/etc/services</filename>. Alternatively, visit
-	<ulink
-	  url="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers"></ulink>
-	and do a port number lookup to find the purpose of a
-	particular port number.</para>
-
-      <para>Check out this link for port numbers used by Trojans
-	<ulink
-	  url="http://www.sans.org/security-resources/idfaq/oddports.php"></ulink>.</para>
-
-      <para>The following ruleset creates an
-	<literal>inclusive</literal> firewall ruleset which can be
-	easily customized by commenting out
-	<literal>pass</literal> rules for services that should not
-	be authorized.</para>
-
-      <para>To avoid logging unwanted messages, add a
-	<literal>block</literal> rule in the inbound section.</para>
-
-      <para>Change the <devicename>dc0</devicename> interface name in
-	every rule to the interface name that connects the system to
-	the public Internet.</para>
-
-      <para>The following statements were added to
-	<filename>/etc/ipf.rules</filename>:</para>
-
-      <programlisting>#################################################################
-# No restrictions on Inside LAN Interface for private network
-# Not needed unless you have LAN
-#################################################################
-
-#pass out quick on xl0 all
-#pass in quick on xl0 all
-
-#################################################################
-# No restrictions on Loopback Interface
-#################################################################
-pass in quick on lo0 all
-pass out quick on lo0 all
-
-#################################################################
-# Interface facing Public Internet (Outbound Section)
-# Match session start requests originating from behind the
-# firewall on the private network
-# or from this gateway server destined for the public Internet.
-#################################################################
-
-# Allow out access to my ISP's Domain name server.
-# xxx must be the IP address of your ISP's DNS.
-# Dup these lines if your ISP has more than one DNS server
-# Get the IP addresses from /etc/resolv.conf file
-pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state
-pass out quick on dc0 proto udp from any to xxx port = 53 keep state
-
-# Allow out access to my ISP's DHCP server for cable or DSL networks.
-# This rule is not needed for 'user ppp' type connection to the
-# public Internet, so you can delete this whole group.
-# Use the following rule and check log for IP address.
-# Then put IP address in commented out rule &amp; delete first rule
-pass out log quick on dc0 proto udp from any to any port = 67 keep state
-#pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state
-
-
-# Allow out non-secure standard www function
-pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state
-
-# Allow out secure www function https over TLS SSL
-pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state
-
-# Allow out send &amp; get email function
-pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state
-pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state
-
-# Allow out Time
-pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state
-
-# Allow out nntp news
-pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state
-
-# Allow out gateway &amp; LAN users' non-secure FTP ( both passive &amp; active modes)
-# This function uses the IP<acronym>NAT</acronym> built in FTP proxy function coded in
-# the nat rules file to make this single rule function correctly.
-# If you want to use the pkg_add command to install application packages
-# on your gateway system you need this rule.
-pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state
-
-# Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements)
-# This function is using SSH (secure shell)
-pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state
-
-# Allow out insecure Telnet
-pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state
-
-# Allow out FreeBSD CVSup
-pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state
-
-# Allow out ping to public Internet
-pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state
-
-# Allow out whois from LAN to public Internet
-pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state
-
-# Block and log only the first occurrence of everything
-# else that's trying to get out.
-# This rule implements the default block
-block out log first quick on dc0 all
-
-#################################################################
-# Interface facing Public Internet (Inbound Section)
-# Match packets originating from the public Internet
-# destined for this gateway server or the private network.
-#################################################################
-
-# Block all inbound traffic from non-routable or reserved address spaces
-block in quick on dc0 from 192.168.0.0/16 to any    #RFC 1918 private IP
-block in quick on dc0 from 172.16.0.0/12 to any     #RFC 1918 private IP
-block in quick on dc0 from 10.0.0.0/8 to any        #RFC 1918 private IP
-block in quick on dc0 from 127.0.0.0/8 to any       #loopback
-block in quick on dc0 from 0.0.0.0/8 to any         #loopback
-block in quick on dc0 from 169.254.0.0/16 to any    #DHCP auto-config
-block in quick on dc0 from 192.0.2.0/24 to any      #reserved for docs
-block in quick on dc0 from 204.152.64.0/23 to any   #Sun cluster interconnect
-block in quick on dc0 from 224.0.0.0/3 to any       #Class D &amp; E multicast
-
-##### Block a bunch of different nasty things. ############
-# That I do not want to see in the log
-
-# Block frags
-block in quick on dc0 all with frags
-
-# Block short tcp packets
-block in quick on dc0 proto tcp all with short
-
-# block source routed packets
-block in quick on dc0 all with opt lsrr
-block in quick on dc0 all with opt ssrr
-
-# Block nmap OS fingerprint attempts
-# Log first occurrence of these so I can get their IP address
-block in log first quick on dc0 proto tcp from any to any flags FUP
-
-# Block anything with special options
-block in quick on dc0 all with ipopts
-
-# Block public pings
-block in quick on dc0 proto icmp all icmp-type 8
-
-# Block ident
-block in quick on dc0 proto tcp from any to any port = 113
-
-# Block all Netbios service. 137=name, 138=datagram, 139=session
-# Netbios is MS/Windows sharing services.
-# Block MS/Windows hosts2 name server requests 81
-block in log first quick on dc0 proto tcp/udp from any to any port = 137
-block in log first quick on dc0 proto tcp/udp from any to any port = 138
-block in log first quick on dc0 proto tcp/udp from any to any port = 139
-block in log first quick on dc0 proto tcp/udp from any to any port = 81
-
-# Allow traffic in from ISP's DHCP server. This rule must contain
-# the IP address of your ISP's DHCP server as it is the only
-# authorized source to send this packet type. Only necessary for
-# cable or DSL configurations. This rule is not needed for
-# 'user ppp' type connection to the public Internet.
-# This is the same IP address you captured and
-# used in the outbound section.
-pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state
-
-# Allow in standard www function because I have apache server
-pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state
-
-# Allow in non-secure Telnet session from public Internet
-# labeled non-secure because ID/PW passed over public Internet as clear text.
-# Delete this sample group if you do not have telnet server enabled.
-#pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state
-
-# Allow in secure FTP, Telnet, and SCP from public Internet
-# This function is using SSH (secure shell)
-pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state
-
-# Block and log only first occurrence of all remaining traffic
-# coming into the firewall. The logging of only the first
-# occurrence avoids filling up disk with Denial of Service logs.
-# This rule implements the default block.
-block in log first quick on dc0 all
-################### End of rules file #####################################</programlisting>
-    </sect2>
-
-    <sect2>
-      <title><acronym>NAT</acronym></title>
-
-      <indexterm><primary>NAT</primary></indexterm>
-
-      <indexterm>
-	<primary>IP masquerading</primary>
-
-	<see>NAT</see>
-      </indexterm>
-
-      <indexterm>
-	<primary>network address translation</primary>
-
-	<see>NAT</see>
-      </indexterm>
-
-      <para><acronym>NAT</acronym> stands for <emphasis>Network
-	  Address Translation</emphasis>.  In &linux;, NAT is called
-	<quote>IP Masquerading</quote>.  The IPF
-	<acronym>NAT</acronym> function enables the private LAN behind
-	the firewall to share a single ISP-assigned IP address, even
-	if that address is dynamically assigned.  NAT allows each
-	computer in the LAN to have Internet access, without
-	having to pay the ISP for multiple Internet accounts or IP
-	addresses.</para>
-
-      <para><acronym>NAT</acronym> will automatically translate the
-	private LAN IP address for each system on the LAN to the
-	single public IP address as packets exit the firewall bound
-	for the public Internet.  It also performs the reverse
-	translation for returning packets.</para>
-
-      <para>According to RFC 1918, the following IP address ranges are
-	reserved for private networks which will never be routed
-	directly to the public Internet, and therefore are available
-	for use with NAT:</para>
-
-      <itemizedlist>
-	<listitem>
-	  <para><literal>10.0.0.0/8</literal>.</para>
-	</listitem>
-
-	<listitem>
-	  <para><literal>172.16.0.0/12</literal>.</para>
-	</listitem>
-
-	<listitem>
-	  <para><literal>192.168.0.0/16</literal>.</para>
-	</listitem>
-      </itemizedlist>
-
-    </sect2>
-
-    <sect2>
-      <title>IP<acronym>NAT</acronym></title>
-
-      <indexterm>
-	<primary>NAT</primary>
-
-	<secondary>and IPFILTER</secondary>
-      </indexterm>
-
-      <indexterm><primary><command>ipnat</command></primary></indexterm>
-
-      <para><acronym>NAT</acronym> rules are loaded using
-	<command>ipnat</command>.  Typically, the
-	<acronym>NAT</acronym> rules are stored in
-	<filename>/etc/ipnat.rules</filename>.  See &man.ipnat.8; for
-	details.</para>
-
-      <para>When the file containing the <acronym>NAT</acronym> rules
-	is edited after <acronym>NAT</acronym> has been started, run
-	<command>ipnat</command> with <option>-CF</option> to delete
-	the internal in use <acronym>NAT</acronym> rules and flush the
-	contents of the translation table of all active
-	entries.</para>
-
-      <para>To reload the <acronym>NAT</acronym> rules, issue a
-	command like this:</para>
-
-      <screen>&prompt.root; <userinput>ipnat -CF -f
-	  /etc/ipnat.rules</userinput></screen>
-
-      <para>To display some <acronym>NAT</acronym> statistics, use
-	this command:</para>
-
-      <screen>&prompt.root; <userinput>ipnat -s</userinput></screen>
-
-      <para>To list the <acronym>NAT</acronym> table's current
-	mappings, use this command:</para>
-
-      <screen>&prompt.root; <userinput>ipnat -l</userinput></screen>
-
-      <para>To turn verbose mode on and display information relating
-	to rule processing and active rules/table entries:</para>
-
-      <screen>&prompt.root; <userinput>ipnat -v</userinput></screen>
-    </sect2>
-
-    <sect2>
-      <title>IP<acronym>NAT</acronym> Rules</title>
-
-      <para><acronym>NAT</acronym> rules are flexible and can
-	accomplish many different things to fit the needs of
-	commercial and home users.</para>
-
-      <para>The rule syntax presented here has been simplified to
-	what is most commonly used in a non-commercial environment.
-	For a complete rule syntax description, refer to
-	&man.ipnat.5;.</para>
-
-      <para>The syntax for a <acronym>NAT</acronym> rule looks like
-	this:</para>
-
-      <programlisting>map <replaceable>IF</replaceable> <replaceable>LAN_IP_RANGE</replaceable> -&gt; <replaceable>PUBLIC_ADDRESS</replaceable></programlisting>
-
-      <para>The keyword <literal>map</literal> starts the rule.</para>
-
-      <para>Replace <replaceable>IF</replaceable> with the external
-	interface.</para>
-
-      <para>The <replaceable>LAN_IP_RANGE</replaceable> is used by the
-	internal clients use for IP Addressing.  Usually, this is
-	something like <hostid
-	  role="ipaddr">192.168.1.0/24</hostid>.</para>
-
-      <para>The <replaceable>PUBLIC_ADDRESS</replaceable> can either
-	be the static external IP address or the special keyword
-	<literal>0/32</literal> which uses the IP address assigned to
-	<replaceable>IF</replaceable>.</para>
-    </sect2>
-
-    <sect2>
-      <title>How <acronym>NAT</acronym> Works</title>
-
-      <para>In IPF, when a packet arrives at the firewall from the LAN
-	with a public destination, it passes through the outbound
-	filter rules.  <acronym>NAT</acronym> gets its turn at the
-	packet and applies its rules top down, where the first
-	matching rule wins.  <acronym>NAT</acronym> tests each of its
-	rules against the packet's interface name and source IP
-	address.  When a packet's interface name matches a
-	<acronym>NAT</acronym> rule, the packet's source IP address in
-	the private LAN is checked to see if it falls within the IP
-	address range specified to the left of the arrow symbol on the
-	<acronym>NAT</acronym> rule.  On a match, the packet has its
-	source IP address rewritten with the public IP address
-	obtained by the <literal>0/32</literal> keyword.
-	<acronym>NAT</acronym> posts an entry in its internal
-	<acronym>NAT</acronym> table so when the packet returns from
-	the public Internet it can be mapped back to its original
-	private IP address and then passed to the filter rules for
-	processing.</para>
-    </sect2>
-
-    <sect2>
-      <title>Enabling IP<acronym>NAT</acronym></title>
-
-      <para>To enable IP<acronym>NAT</acronym>, add these statements
-	to <filename>/etc/rc.conf</filename>.</para>
-
-      <para>To enable the machine to route traffic between
-	interfaces:</para>
-
-      <programlisting>gateway_enable="YES"</programlisting>
-
-      <para>To start IP<acronym>NAT</acronym> automatically each
-	time:</para>
-
-      <programlisting>ipnat_enable="YES"</programlisting>
-
-      <para>To specify where to load the IP<acronym>NAT</acronym>
-	rules from:</para>
-
-      <programlisting>ipnat_rules="/etc/ipnat.rules"</programlisting>
-    </sect2>
-
-    <sect2>
-      <title><acronym>NAT</acronym> for a Large LAN</title>
-
-      <para>For networks that have large numbers of systems on the LAN
-	or networks with more than a single LAN, the process of
-	funneling all those private IP addresses into a single public
-	IP address becomes a resource problem that may cause problems
-	with the same port numbers being used many times across many
-	connections, causing collisions.  There are two ways to
-	relieve this resource problem.</para>
-
-      <sect3>
-	<title>Assigning Ports to Use</title>
-
-	<para>A normal NAT rule would look like:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32</programlisting>
-
-	<para>In the above rule, the packet's source port is unchanged
-	  as the packet passes through IP<acronym>NAT</acronym>.  By
-	  adding the <literal>portmap</literal> keyword,
-	  IP<acronym>NAT</acronym> can be directed to only use
-	  source ports in the specified range.  For example, the
-	  following rule will tell IP<acronym>NAT</acronym> to modify
-	  the source port to be within the range shown:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp 20000:60000</programlisting>
-
-	<para>Additionally, the <literal>auto</literal> keyword tells
-	  IP<acronym>NAT</acronym> to determine which ports are
-	  available for use:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp auto</programlisting>
-      </sect3>
-
-      <sect3>
-	<title>Using a Pool of Public Addresses</title>
-
-	<para>In very large LANs there comes a point where there are
-	  just too many LAN addresses to fit into a single public
-	  address.  If a block of public IP addresses is available,
-	  these addresses can be used as a <quote>pool</quote>, and
-	  IP<acronym>NAT</acronym> may pick one of the public IP
-	  addresses as packet addresses are mapped on their way
-	  out.</para>
-
-	<para>For example, instead of mapping all packets through a
-	  single public IP address:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.1</programlisting>
-
-	<para>A range of public IP addresses can be specified either
-	  with a netmask:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/255.255.255.0</programlisting>
-
-	<para>or using CIDR notation:</para>
-
-	<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/24</programlisting>
-      </sect3>
-    </sect2>
-
-    <sect2>
-      <title>Port Redirection</title>
-
-      <para>A common practice is to have a web server, email server,
-	database server, and DNS server each segregated to a different
-	system on the LAN.  In this case, the traffic from these
-	servers still has to undergo <acronym>NAT</acronym>, but there
-	has to be some way to direct the inbound traffic to the
-	correct server.  For example, a web server operating on LAN
-	address <hostid
-	  role="ipaddr">10.0.10.25</hostid> and using a single public
-	IP address of <hostid role="ipaddr">20.20.20.5</hostid>, would
-	use this rule:</para>
-
-	<programlisting>rdr dc0 20.20.20.5/32 port 80 -&gt; 10.0.10.25 port 80</programlisting>
-
-	<para>or:</para>
-
-	<programlisting>rdr dc0 0.0.0.0/0 port 80 -&gt; 10.0.10.25 port 80</programlisting>
-
-	<para>For a LAN DNS server on a private address of <hostid
-	    role="ipaddr">10.0.10.33</hostid> that needs to receive
-	  public DNS requests:</para>
-
-	<programlisting>rdr dc0 20.20.20.5/32 port 53 -&gt; 10.0.10.33 port 53 udp</programlisting>
-    </sect2>
-
-    <sect2>
-      <title>FTP and <acronym>NAT</acronym></title>
-
-      <para>FTP has two modes:  active mode and passive mode.  The
-	difference is in how the data channel is acquired.  Passive
-	mode is more secure as the data channel is acquired by the
-	ordinal ftp session requester.  For a good explanation of FTP
-	and the different modes, see <ulink
-	  url="http://www.slacksite.com/other/ftp.html"></ulink>.</para>
-
-      <sect3>
-	<title>IP<acronym>NAT</acronym> Rules</title>
-
-	<para>IP<acronym>NAT</acronym> has a built in FTP proxy option
-	  which can be specified on the <acronym>NAT</acronym> map
-	  rule.  It can monitor all outbound packet traffic for FTP
-	  active or passive start session requests and dynamically
-	  create temporary filter rules containing the port number
-	  being used by the data channel.  This eliminates the
-	  security risk FTP normally exposes the firewall to as it no
-	  longer needs to open large ranges of high order ports for
-	  FTP connections.</para>
-
-	<para>This rule will handle all the traffic for the internal
-	  LAN:</para>
-
-	<programlisting>map dc0 10.0.10.0/29 -&gt; 0/32 proxy port 21 ftp/tcp</programlisting>
-
-	<para>This rule handles the FTP traffic from the
-	  gateway:</para>
-
-	<programlisting>map dc0 0.0.0.0/0 -&gt; 0/32 proxy port 21 ftp/tcp</programlisting>
-
-	<para>This rule handles all non-FTP traffic from the internal
-	  LAN:</para>
-
-	<programlisting>map dc0 10.0.10.0/29 -&gt; 0/32</programlisting>
-
-	<para>The FTP <literal>map</literal> rules go before the
-	  <acronym>NAT</acronym> rule so that when a packet matches an
-	  FTP rule, the FTP proxy creates temporary filter rules to
-	  let the FTP session packets pass and undergo
-	  <acronym>NAT</acronym>.  All LAN packets that are not FTP
-	  will not match the FTP rules but will undergo
-	  <acronym>NAT</acronym> if they match the third rule.</para>
-      </sect3>
-
-      <sect3>
-	<title>IP<acronym>NAT</acronym> FTP Filter Rules</title>
-
-	<para>Only one filter rule is needed for FTP if the
-	  <acronym>NAT</acronym> FTP proxy is used.</para>
-
-	<para>Without the FTP proxy, the following three rules will be
-	  needed:</para>
-
-	<programlisting># Allow out LAN PC client FTP to public Internet
-# Active and passive modes
-pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
-
-# Allow out passive mode data channel high order port numbers
-pass out quick on rl0 proto tcp from any to any port &gt; 1024 flags S keep state
-
-# Active mode let data channel in from FTP server
-pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</programlisting>
-      </sect3>
-    </sect2>
-  </sect1>
-
   <sect1 id="firewalls-ipfw">
     <title>IPFW</title>
 
