svn commit: r44083 - head/en_US.ISO8859-1/books/handbook/firewalls

From: Dru Lavigne <dru_at_FreeBSD.org>
Date: Wed, 26 Feb 2014 23:44:34 +0000 (UTC)
Author: dru
Date: Wed Feb 26 23:44:33 2014
New Revision: 44083
URL: http://svnweb.freebsd.org/changeset/doc/44083

Log:
  White space fix only. Translators can ignore.
  
  Sponsored by: iXsystems

Modified:
  head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml	Wed Feb 26 23:14:36 2014	(r44082)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml	Wed Feb 26 23:44:33 2014	(r44083)
_at__at_ -1708,40 +1708,39 _at__at_ options    IPDIVERT			# enables NAT</pro
       </itemizedlist>
 
       <para>If <literal>firewall_type</literal> is set to either
-	  <literal>client</literal> or <literal>simple</literal>,
-	  modify the default rules found in
-	  <filename>/etc/rc.firewall</filename> to fit the
-	  configuration of the system.</para>
+	<literal>client</literal> or <literal>simple</literal>,
+	modify the default rules found in
+	<filename>/etc/rc.firewall</filename> to fit the
+	configuration of the system.</para>
 
-      <para>Note that the
-	<literal>filename</literal> type is used to load a custom ruleset.</para>
+      <para>Note that the <literal>filename</literal> type is used to
+	load a custom ruleset.</para>
 
       <para>An alternate way to load a custom ruleset is to set the
 	<literal>firewall_script</literal> variable to the absolute
-	  path of an <emphasis>executable script</emphasis> that includes
-	<application>IPFW</application> commands.    The examples used in this
-	section assume that the <literal>firewall_script</literal>
-	is set to <filename>/etc/ipfw.rules</filename>:</para>
+	path of an <emphasis>executable script</emphasis> that
+	includes <application>IPFW</application> commands.    The
+	examples used in this section assume that the
+	<literal>firewall_script</literal> is set to
+	<filename>/etc/ipfw.rules</filename>:</para>
 
-	<programlisting>firewall_script="/etc/ipfw.rules"</programlisting>
+      <programlisting>firewall_script="/etc/ipfw.rules"</programlisting>
 
       <para>To enable logging, include this line:</para>
 
       <programlisting>firewall_logging="YES"</programlisting>
 
-	<para>There is no
-	  <filename>/etc/rc.conf</filename> variable to set logging
-	  limits.  To limit the number of times a rule is logged
-	  per connection attempt, specify the number using this line
-	  in
-	  <filename>/etc/sysctl.conf</filename>:</para>
+      <para>There is no <filename>/etc/rc.conf</filename> variable to
+	set logging limits.  To limit the number of times a rule is
+	logged per connection attempt, specify the number using this
+	line in <filename>/etc/sysctl.conf</filename>:</para>
 
      <programlisting>net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></programlisting>
-       
+
      <para>After saving the needed edits, start the firewall.  To
        enable logging limits now, also set the
        <command>sysctl</command> value specified above:</para>
- 
+
      <screen>&prompt.root; <userinput>service ipfw start</userinput>
 &prompt.root; <userinput>sysctl net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></userinput></screen>
     </sect2>
_at__at_ -1755,13 +1754,12 _at__at_ options    IPDIVERT			# enables NAT</pro
 	<secondary>rule processing order</secondary>
       </indexterm>
 
-      <para>When a packet enters the <application>IPFW</application> firewall,
-	it is compared against the first rule in the ruleset and
-	progresses one rule at a time, moving from top to bottom in
-	sequence.  When the
-	packet matches the selection parameters of a rule, the rule's
-	action is executed and the search of the ruleset
-	terminates for that packet.  This is referred to as
+      <para>When a packet enters the <application>IPFW</application>
+	firewall, it is compared against the first rule in the ruleset
+	and progresses one rule at a time, moving from top to bottom
+	in sequence.  When the packet matches the selection parameters
+	of a rule, the rule's action is executed and the search of the
+	ruleset terminates for that packet.  This is referred to as
 	<quote>first match wins</quote>.  If the packet does not match
 	any of the rules, it gets caught by the mandatory
 	<application>IPFW</application> default rule number 65535,
_at__at_ -1781,19 +1779,20 _at__at_ options    IPDIVERT			# enables NAT</pro
       <para>When creating an
 	<application>IPFW</application> rule, keywords must be
 	written in the following order.  Some keywords are mandatory
-	while other keywords are optional.  The words shown in uppercase
-	represent a variable and the words shown in lowercase must
-	precede the variable that follows it.  The <literal>#</literal> symbol is used
-	to mark the start of a comment and may appear at the end of a
-	rule or on its own line.  Blank lines are ignored.</para>
+	while other keywords are optional.  The words shown in
+	uppercase represent a variable and the words shown in
+	lowercase must precede the variable that follows it.  The
+	<literal>#</literal> symbol is used to mark the start of a
+	comment and may appear at the end of a rule or on its own
+	line.  Blank lines are ignored.</para>
 
       <para><replaceable>CMD RULE_NUMBER set SET_NUMBER ACTION log
-	  LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT 
+	  LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT
 	  OPTIONS</replaceable></para>
 
       <para>This section provides an overview of these keywords and
-	their options. It is not an exhaustive list of every possible 
-	option. Refer to  &man.ipfw.8; for a complete description of
+	their options.  It is not an exhaustive list of every possible
+	option.  Refer to  &man.ipfw.8; for a complete description of
 	the rule syntax that can be used when creating
 	<application>IPFW</application> rules.</para>
 
_at__at_ -1812,9 +1811,10 _at__at_ options    IPDIVERT			# enables NAT</pro
 	    <para>Each rule is associated with a number in the
 	      range of <literal>1</literal> to
 	      <literal>65534</literal>.  The number is used to
-	      indicate the order of rule processing.  Multiple rules can have the same
-              number, in which case they are checked according to
-              the order in which they have been added.</para>
+	      indicate the order of rule processing.  Multiple rules
+	      can have the same number, in which case they are checked
+	      according to the order in which they have been
+	      added.</para>
 	  </listitem>
 	</varlistentry>
 
_at__at_ -1822,13 +1822,12 _at__at_ options    IPDIVERT			# enables NAT</pro
 	  <term>SET_NUMBER</term>
 	  <listitem>
 	    <para>Each rule is associated with a set number in the
-	      range of <literal>0</literal> to
-	      <literal>31</literal>.  Sets can be individually
-	      disabled or enabled, making it possible to quickly add
-	      or delete a set of rules.  If a SET_NUMBER is not
-	      specified, the rule will be added to set <literal>0</literal>.</para>
-
-           </listitem>
+	      range of <literal>0</literal> to <literal>31</literal>.
+	      Sets can be individually disabled or enabled, making it
+	      possible to quickly add or delete a set of rules.  If a
+	      SET_NUMBER is not specified, the rule will be added to
+	      set <literal>0</literal>.</para>
+	  </listitem>
 	</varlistentry>
 
 	<varlistentry>
_at__at_ -1840,14 +1839,15 _at__at_ options    IPDIVERT			# enables NAT</pro
 	      rule.</para>
 
 	    <para><parameter>allow | accept | pass |
-		permit</parameter>: these keywords are equivalent and allow packets
-	      that match the rule.</para>
+		permit</parameter>: these keywords are equivalent and
+	      allow packets that match the rule.</para>
 
-	    <para><parameter>check-state</parameter>: checks the packet against the dynamic state table.
-	      If a match is found, execute the action associated with
-	      the rule which generated this dynamic rule, otherwise
-	      move to the next rule.  A <literal>check-state</literal>
-	      rule does not have selection criterion.  If no
+	    <para><parameter>check-state</parameter>: checks the
+	      packet against the dynamic state table.  If a match is
+	      found, execute the action associated with the rule which
+	      generated this dynamic rule, otherwise move to the next
+	      rule.  A <literal>check-state</literal> rule does not
+	      have selection criterion.  If no
 	      <literal>check-state</literal> rule is present in the
 	      ruleset, the dynamic rules table is checked at the first
 	      <literal>keep-state</literal> or
_at__at_ -1857,9 +1857,9 _at__at_ options    IPDIVERT			# enables NAT</pro
 	      all packets that match rule.  The search continues with
 	      the next rule.</para>
 
-	    <para><parameter>deny | drop</parameter>: either word discards
-	      packets that match this rule.</para>
-	      
+	    <para><parameter>deny | drop</parameter>: either word
+	      discards packets that match this rule.</para>
+
 	    <para>Additional actions are available.  Refer to
 	      &man.ipfw.8; for details.</para>
 	  </listitem>
_at__at_ -1873,15 +1873,14 _at__at_ options    IPDIVERT			# enables NAT</pro
 	      to &man.syslogd.8; with a facility name of
 	      <literal>SECURITY</literal>.  Logging only occurs if the
 	      number of packets logged for that particular rule does
-	      not exceed the optional specified LOG_AMOUNT.
-	      If no LOG_AMOUNT is specified, the
-	      limit is taken from the value
-	      of <varname>net.inet.ip.fw.verbose_limit</varname>.  A
-	      value of zero removes the logging limit.
-	      Once the limit is reached, logging can be re-enabled by
-	      clearing the logging counter or the packet counter for
-	      that rule, using <command>ipfw reset
-		log</command>.</para>
+	      not exceed the optional specified LOG_AMOUNT.  If no
+	      LOG_AMOUNT is specified, the limit is taken from the
+	      value of
+	      <varname>net.inet.ip.fw.verbose_limit</varname>.  A
+	      value of zero removes the logging limit.  Once the limit
+	      is reached, logging can be re-enabled by clearing the
+	      logging counter or the packet counter for that rule,
+	      using <command>ipfw reset log</command>.</para>
 
 	    <note>
 	      <para>Logging is done after all other packet matching
_at__at_ -1898,25 +1897,25 _at__at_ options    IPDIVERT			# enables NAT</pro
 	    <para>This optional value can be used to specify any
 	      protocol name or number found in
 	      <filename>/etc/protocols</filename>.</para>
-	    </listitem>
-	  </varlistentry>
+	  </listitem>
+	</varlistentry>
 
 	<varlistentry>
 	  <term>SRC</term>
 	  <listitem>
-	    <para>The <literal>from</literal>
-	      keyword must be followed by the source address or a
-	      keyword that represents the source address.  An address
-	      can be represented by the <literal>any</literal>,
-	      <literal>me</literal> (any address configured on an
-	      interface on this system),
+	    <para>The <literal>from</literal> keyword must be followed
+	      by the source address or a keyword that represents the
+	      source address.  An address can be represented by the
+	      <literal>any</literal>, <literal>me</literal> (any
+	      address configured on an interface on this system),
 	      <literal>me6</literal>, (any <acronym>IPv6</acronym>
 	      address configured on an interface on this system), or
 	      <literal>table</literal> followed by the number of a
 	      lookup table which contains a list of addresses.  When
 	      specifying an <acronym>IP</acronym> address, it can be
 	      optionally followed by its <acronym>CIDR</acronym> mask
-	      or subnet mask.  For example, <literal>1.2.3.4/25</literal> or
+	      or subnet mask.  For example,
+	      <literal>1.2.3.4/25</literal> or
 	      <literal>1.2.3.4:255.255.255.128</literal>.</para>
 	  </listitem>
 	</varlistentry>
_at__at_ -1934,10 +1933,10 _at__at_ options    IPDIVERT			# enables NAT</pro
 	  <term>DST</term>
 	  <listitem>
 	    <para>The <literal>to</literal> keyword must be followed
-	      by the destination address or a
-	      keyword that represents the destination address.  The
-	      same keywords and addresses described in the SRC section
-	      can be used to describe the destination.</para>
+	      by the destination address or a keyword that represents
+	      the destination address.  The same keywords and
+	      addresses described in the SRC section can be used to
+	      describe the destination.</para>
 	  </listitem>
 	</varlistentry>
 
_at__at_ -1956,28 +1955,29 _at__at_ options    IPDIVERT			# enables NAT</pro
 	    <para>Several keywords can follow the source and
 	      destination.  As the name suggests, OPTIONS are
 	      optional.  Commonly used options include
-	      <literal>in</literal> or
-	      <literal>out</literal>, which specify the direction of
-	      packet flow, <literal>icmptypes</literal> followed by
-	      the type of <acronym>ICMP</acronym> message, and
+	      <literal>in</literal> or <literal>out</literal>, which
+	      specify the direction of packet flow,
+	      <literal>icmptypes</literal> followed by the type of
+	      <acronym>ICMP</acronym> message, and
 	      <literal>keep-state</literal>.</para>
 
-	    <para>When a <parameter>keep-state</parameter> rule is matched, the
-	      firewall will create a dynamic rule which
-	      matches bidirectional traffic between the
-	      source and destination addresses and ports using the same
+	    <para>When a <parameter>keep-state</parameter> rule is
+	      matched, the firewall will create a dynamic rule which
+	      matches bidirectional traffic between the source and
+	      destination addresses and ports using the same
 	      protocol.</para>
 
 	    <para>The dynamic rules facility is vulnerable to resource
 	      depletion from a SYN-flood attack which would open a
 	      huge number of dynamic rules.  To counter this type of
 	      attack with  <application>IPFW</application>, use
-	      <literal>limit</literal>.  This option limits the
-	      number of simultaneous sessions by checking the open dynamic rules, counting
-	      the number of times this rule and <acronym>IP</acronym> address
-	      combination occurred.  If this count is greater than the
-	      value specified by <literal>limit</literal>, the packet
-	      is discarded.</para>
+	      <literal>limit</literal>.  This option limits the number
+	      of simultaneous sessions by checking the open dynamic
+	      rules, counting the number of times this rule and
+	      <acronym>IP</acronym> address combination occurred.  If
+	      this count is greater than the value specified by
+	      <literal>limit</literal>, the packet is
+	      discarded.</para>
 
 	    <para>Dozens of OPTIONS are available.  Refer to
 	      &man.ipfw.8; for a description of each available
_at__at_ -1988,38 +1988,38 _at__at_ options    IPDIVERT			# enables NAT</pro
     </sect2>
 
     <sect2>
-	<title>Example Ruleset</title>
+      <title>Example Ruleset</title>
 
-	<para>This section demonstrates how to create an example
-	  stateful firewall ruleset script named
-	  <filename>/etc/ipfw.rules</filename>.  In this example, all
-	  connection rules use <literal>in</literal> or
-	  <literal>out</literal> to clarify the direction.  They also
-	  use <literal>via</literal>
-	  <replaceable>interface-name</replaceable> to specify
-	  the interface the packet is traveling over.</para>
-
-	<note>	  
-      <para>When first creating or testing a firewall ruleset,
-	consider temporarily setting this tunable:</para>
-
-      <programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting>
-
-	<para>This sets the default policy of &man.ipfw.8; to
-	  be more permissive than the default <literal>deny ip from
-	    any to any</literal>, making it slightly more difficult
-	  to get locked out of the system right after a reboot.</para>
+      <para>This section demonstrates how to create an example
+	stateful firewall ruleset script named
+	<filename>/etc/ipfw.rules</filename>.  In this example, all
+	connection rules use <literal>in</literal> or
+	<literal>out</literal> to clarify the direction.  They also
+	use <literal>via</literal>
+	<replaceable>interface-name</replaceable> to specify
+	the interface the packet is traveling over.</para>
+
+      <note>
+	<para>When first creating or testing a firewall ruleset,
+	  consider temporarily setting this tunable:</para>
+
+	<programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting>
+
+	<para>This sets the default policy of &man.ipfw.8; to be more
+	  permissive than the default <literal>deny ip from any to
+	    any</literal>, making it slightly more difficult to get
+	  locked out of the system right after a reboot.</para>
       </note>
 
-	<para>The firewall script begins by indicating that it is a
-	  Bourne shell script and flushes any existing rules.  It then
-	  creates the <literal>cmd</literal> variable so that
-	  <literal>ipfw add</literal> does not have to be typed at the
-	  beginning of every rule.  It also defines the
-	  <literal>pif</literal> variable which represents the name of
-	  the interface that is attached to the Internet.</para>
+      <para>The firewall script begins by indicating that it is a
+	Bourne shell script and flushes any existing rules.  It then
+	creates the <literal>cmd</literal> variable so that
+	<literal>ipfw add</literal> does not have to be typed at the
+	beginning of every rule.  It also defines the
+	<literal>pif</literal> variable which represents the name of
+	the interface that is attached to the Internet.</para>
 
-	<programlisting>#!/bin/sh
+      <programlisting>#!/bin/sh
 # Flush out the list before we begin.
 ipfw -q -f flush
 
_at__at_ -2027,24 +2027,24 _at__at_ ipfw -q -f flush
 cmd="ipfw -q add"
 pif="dc0"     # interface name of NIC attached to Internet</programlisting>
 
-	<para>The first two rules allow all traffic on the trusted
-	  internal interface and on the loopback interface:</para>
+      <para>The first two rules allow all traffic on the trusted
+	internal interface and on the loopback interface:</para>
 
-	<programlisting># Change xl0 to LAN NIC interface name
+      <programlisting># Change xl0 to LAN NIC interface name
 &dollar;cmd 00005 allow all from any to any via xl0
 
 # No restrictions on Loopback Interface
 &dollar;cmd 00010 allow all from any to any via lo0</programlisting>
 
-	<para>The next rule allows the packet through if it matches
-	  an existing entry in the dynamic rules table:</para>
+      <para>The next rule allows the packet through if it matches an
+	existing entry in the dynamic rules table:</para>
 
-	<programlisting>&dollar;cmd 00015 check-state</programlisting>
+      <programlisting>&dollar;cmd 00015 check-state</programlisting>
 
-	<para>The next set of rules defines which stateful connections
-	  internal systems can create to hosts on the Internet:</para>
+      <para>The next set of rules defines which stateful connections
+	internal systems can create to hosts on the Internet:</para>
 
-	<programlisting># Allow access to public DNS
+      <programlisting># Allow access to public DNS
 # Replace x.x.x.x with the IP address of a public DNS server
 # and repeat for each DNS server in /etc/resolv.conf
 &dollar;cmd 00110 allow tcp from any to x.x.x.x 53 out via &dollar;pif setup keep-state
_at__at_ -2076,14 +2076,14 _at__at_ pif="dc0"     # interface name of NIC at
 # deny and log all other outbound connections
 &dollar;cmd 00299 deny log all from any to any out via &dollar;pif</programlisting>
 
-	<para>The next set of rules controls connections from
-	  Internet hosts to the internal network.  It starts by
-	  denying packets typically associated with attacks and then
-	  explicitly allows specific types of connections.  All the
-	  authorized services that originate from the Internet use
-	  <literal>limit</literal> to prevent flooding.</para>
+      <para>The next set of rules controls connections from Internet
+	hosts to the internal network.  It starts by denying packets
+	typically associated with attacks and then explicitly allows
+	specific types of connections.  All the authorized services
+	that originate from the Internet use <literal>limit</literal>
+	to prevent flooding.</para>
 
-	<programlisting># Deny all inbound traffic from non-routable reserved address spaces
+      <programlisting># Deny all inbound traffic from non-routable reserved address spaces
 &dollar;cmd 00300 deny all from 192.168.0.0/16 to any in via &dollar;pif     #RFC 1918 private IP
 &dollar;cmd 00301 deny all from 172.16.0.0/12 to any in via &dollar;pif      #RFC 1918 private IP
 &dollar;cmd 00302 deny all from 10.0.0.0/8 to any in via &dollar;pif         #RFC 1918 private IP
_at__at_ -2125,50 +2125,49 _at__at_ pif="dc0"     # interface name of NIC at
 # Reject and log all other incoming connections
 &dollar;cmd 00499 deny log all from any to any in via &dollar;pif</programlisting>
 
-	<para>The last rule logs all packets that do not match any of
-	  the rules in the
-	  ruleset:</para>
+      <para>The last rule logs all packets that do not match any of
+	the rules in the ruleset:</para>
 
-	<programlisting># Everything else is denied and logged 
+      <programlisting># Everything else is denied and logged
 &dollar;cmd 00999 deny log all from any to any</programlisting>
-      </sect2>
+    </sect2>
 
-      <sect2 xml:id="network-natd">
-	<info>
+    <sect2 xml:id="network-natd">
+      <info>
 	<title>Configuring <acronym>NAT</acronym></title>
 
 	<authorgroup>
-	<author>
-	  <personname>
-	    <firstname>Chern</firstname>
-	    <surname>Lee</surname>
-	  </personname>
-	  <contrib>Contributed by </contrib>
-	</author>
-      </authorgroup>
-    </info>
-	<indexterm>
-	  <primary>NAT</primary>
+	  <author>
+	    <personname>
+	      <firstname>Chern</firstname>
+	      <surname>Lee</surname>
+	    </personname>
+	    <contrib>Contributed by </contrib>
+	  </author>
+	</authorgroup>
+      </info>
+      <indexterm>
+	<primary>NAT</primary>
 
-	  <secondary>and <application>IPFW</application></secondary>
-	</indexterm>
+	<secondary>and <application>IPFW</application></secondary>
+      </indexterm>
 
-	<para>&os;'s built-in
-	<acronym>NAT</acronym> daemon, &man.natd.8;, works in
-	conjunction with <application>IPFW</application> to provide
-	network address translation.  This can be used to provide an
-	Internet Connection Sharing solution so that
-	several internal computers can connect to the Internet using
-	<acronym>IP</acronym> address.</para>
+      <para>&os;'s built-in <acronym>NAT</acronym> daemon,
+	&man.natd.8;, works in conjunction with
+	<application>IPFW</application> to provide network address
+	translation.  This can be used to provide an Internet
+	Connection Sharing solution so that several internal computers
+	can connect to the Internet using <acronym>IP</acronym>
+	address.</para>
 
-	<para>To do this, the &os; machine connected to the Internet
+      <para>To do this, the &os; machine connected to the Internet
 	must act as a gateway.  This gateway machine must have two
 	<acronym>NIC</acronym>s: one connects to the Internet router
 	and the other connects to a <acronym>LAN</acronym>.  All the
 	machines on the <acronym>LAN</acronym> are connected through
 	a hub or switch.</para>
 
-	<para>Each machine and interface behind the
+      <para>Each machine and interface behind the
 	<acronym>LAN</acronym> should be assigned
 	<acronym>IP</acronym> addresses in the private network space,
 	as defined by <link
_at__at_ -2177,18 +2176,18 _at__at_ pif="dc0"     # interface name of NIC at
 	&man.natd.8; machine's internal <acronym>IP</acronym>
 	address.</para>
 
-	<para>Some additional configuration is
-	  needed in order to activate the <acronym>NAT</acronym>
-	  function of <application>IPFW</application>.  If the system
-	  has a custom kernel, the kernel configuration file needs to
-	  include <literal>option IPDIVERT</literal> with the other
-	  <literal>IPFIREWALL</literal> options.</para>
-
-	<para>To enable firewall and <acronym>NAT</acronym> support at
-	  boot time, the following must be in
-	  <filename>/etc/rc.conf</filename>:</para>
+      <para>Some additional configuration is needed in order to
+	activate the <acronym>NAT</acronym> function of
+	<application>IPFW</application>.  If the system has a custom
+	kernel, the kernel configuration file needs to include
+	<literal>option IPDIVERT</literal> with the other
+	<literal>IPFIREWALL</literal> options.</para>
+
+      <para>To enable firewall and <acronym>NAT</acronym> support at
+	boot time, the following must be in
+	<filename>/etc/rc.conf</filename>:</para>
 
-	<programlisting>gateway_enable="YES"	# enables the gateway function
+      <programlisting>gateway_enable="YES"	# enables the gateway function
 natd_enable="YES"                   # enables the <acronym>NAT</acronym> function
 natd_interface="rl0"                # specify interface name of NIC attached to Internet
 natd_flags="-dynamic -m"            # -m = preserve port numbers if possible</programlisting>
_at__at_ -2213,87 +2212,87 _at__at_ redirect_port tcp 192.168.0.3:80 80</pro
 	  consult &man.natd.8;.</para>
       </note>
 
-        <para>Utilizing stateful rules with a <literal>divert
-	    natd</literal> rule complicates the ruleset logic.  The
-	  positioning of the <literal>check-state</literal>, and
-	  <literal>divert natd</literal> rules in the ruleset is
-	  critical and a new action type is used, called
-	  <literal>skipto</literal>.  When using
-	  <literal>skipto</literal>, it is mandatory that each rule is
-	  numbered, so that the <literal>skipto</literal> rule knows
-	  which rule to jump to.</para>
-
-	<para>The following is an uncommented example of a ruleset
-	  which explains the sequence of the packet flow.</para>
-
-	<para>The processing flow starts with the first rule from the
-	  top of the ruleset and progresses one rule at a time until
-	  the end is reached or the packet matches and the packet is
-	  released out of the firewall.  Take note of the location of
-	  rule numbers 100 101, 450, 500, and 510.  These rules
-	  control the translation of the outbound and inbound packets
-	  so that their entries in the dynamic keep-state table always
-	  register the private LAN IP address.  All the allow and deny
-	  rules specify the direction of the packet and the interface.
-	  All start outbound session requests will
-	  <literal>skipto rule 500</literal> to undergo NAT.</para>
-
-	<para>Consider a web browser which initializes a new HTTP
-	  session over port 80.  When the first outbound packet enters
-	  the firewall, it does not match rule 100 because it is
-	  headed out rather than in.  It passes rule 101 because this
-	  is the first packet, and it has not been posted to the
-	  dynamic keep-state table yet.  The packet finally matches
-	  rule 125 as it is outbound through the NIC facing the
-	  Internet and has a source IP address as a private LAN IP
-	  address.  On matching this rule, two actions take place.
-	  <literal>keep-state</literal> adds this rule to the dynamic
-	  keep-state rules table and the specified action is executed
-	  and posted as part of the info in the dynamic table.  In
-	  this case, the action is <literal>skipto rule 500</literal>.
-	  Rule 500 <acronym>NAT</acronym>s the packet IP address and
-	  sends it out to the Internet.  This packet makes its way to
-	  the destination web server, where a response packet is
-	  generated and sent back.  This new packet enters the top of
-	  the ruleset.  It matches rule 100 and has it destination IP
-	  address mapped back to the corresponding LAN IP address.  It
-	  then is processed by the <literal>check-state</literal>
-	  rule, is found in the table as an existing session, and is
-	  released to the LAN.  It goes to the LAN system that sent it
-	  and a new packet is sent requesting another segment of the
-	  data from the remote server.  This time it matches the
-	  <literal>check-state</literal> rule, its outbound entry is
-	  found,  and the associated action,
-	  <literal>skipto 500</literal>, is executed.  The packet
-	  jumps to rule 500, gets <acronym>NAT</acronym>ed, and is
-	  released to the Internet.</para>
-
-	<para>On the inbound side, everything coming in that is part
-	  of an existing session is automatically handled by the
-	  <literal>check-state</literal> rule and the properly placed
-	  <literal>divert natd</literal> rules.  The ruleset only has
-	  to deny bad packets and allow only authorized services.
-	  Consider a web server running on the firewall where web
-	  requests from the Internet should have access to the local
-	  web site.  An inbound start request packet will match rule
-	  100 and its IP address will be mapped to the LAN IP address
-	  of the firewall.  The packet is then matched against all the
-	  nasty things that need to be checked and finally matches
-	  rule 425 where two actions occur.  The packet rule is posted
-	  to the dynamic keep-state table but this time, any new
-	  session requests originating from that source IP address are
-	  limited to 2.  This defends against DoS attacks against the
-	  service running on the specified port number.  The action is
-	  <literal>allow</literal>, so the packet is released to the
-	  LAN. The packet generated as a response is recognized by the
-	  <literal>check-state</literal> as belonging to an existing
-	  session.  It is then sent to rule 500 for
-	  <acronym>NAT</acronym>ing and released to the outbound
-	  interface.</para>
+      <para>Utilizing stateful rules with a <literal>divert
+	  natd</literal> rule complicates the ruleset logic.  The
+	positioning of the <literal>check-state</literal>, and
+	<literal>divert natd</literal> rules in the ruleset is
+	critical and a new action type is used, called
+	<literal>skipto</literal>.  When using
+	<literal>skipto</literal>, it is mandatory that each rule is
+	numbered, so that the <literal>skipto</literal> rule knows
+	which rule to jump to.</para>
+
+      <para>The following is an uncommented example of a ruleset
+	which explains the sequence of the packet flow.</para>
+
+      <para>The processing flow starts with the first rule from the
+	top of the ruleset and progresses one rule at a time until
+	the end is reached or the packet matches and the packet is
+	released out of the firewall.  Take note of the location of
+	rule numbers 100 101, 450, 500, and 510.  These rules
+	control the translation of the outbound and inbound packets
+	so that their entries in the dynamic keep-state table always
+	register the private LAN IP address.  All the allow and deny
+	rules specify the direction of the packet and the interface.
+	All start outbound session requests will
+	<literal>skipto rule 500</literal> to undergo NAT.</para>
+
+      <para>Consider a web browser which initializes a new HTTP
+	session over port 80.  When the first outbound packet enters
+	the firewall, it does not match rule 100 because it is
+	headed out rather than in.  It passes rule 101 because this
+	is the first packet, and it has not been posted to the
+	dynamic keep-state table yet.  The packet finally matches
+	rule 125 as it is outbound through the NIC facing the
+	Internet and has a source IP address as a private LAN IP
+	address.  On matching this rule, two actions take place.
+	<literal>keep-state</literal> adds this rule to the dynamic
+	keep-state rules table and the specified action is executed
+	and posted as part of the info in the dynamic table.  In
+	this case, the action is <literal>skipto rule 500</literal>.
+	Rule 500 <acronym>NAT</acronym>s the packet IP address and
+	sends it out to the Internet.  This packet makes its way to
+	the destination web server, where a response packet is
+	generated and sent back.  This new packet enters the top of
+	the ruleset.  It matches rule 100 and has it destination IP
+	address mapped back to the corresponding LAN IP address.  It
+	then is processed by the <literal>check-state</literal>
+	rule, is found in the table as an existing session, and is
+	released to the LAN.  It goes to the LAN system that sent it
+	and a new packet is sent requesting another segment of the
+	data from the remote server.  This time it matches the
+	<literal>check-state</literal> rule, its outbound entry is
+	found,  and the associated action,
+	<literal>skipto 500</literal>, is executed.  The packet
+	jumps to rule 500, gets <acronym>NAT</acronym>ed, and is
+	released to the Internet.</para>
+
+      <para>On the inbound side, everything coming in that is part of
+	an existing session is automatically handled by the
+	<literal>check-state</literal> rule and the properly placed
+	<literal>divert natd</literal> rules.  The ruleset only has
+	to deny bad packets and allow only authorized services.
+	Consider a web server running on the firewall where web
+	requests from the Internet should have access to the local
+	web site.  An inbound start request packet will match rule
+	100 and its IP address will be mapped to the LAN IP address
+	of the firewall.  The packet is then matched against all the
+	nasty things that need to be checked and finally matches
+	rule 425 where two actions occur.  The packet rule is posted
+	to the dynamic keep-state table but this time, any new
+	session requests originating from that source IP address are
+	limited to 2.  This defends against DoS attacks against the
+	service running on the specified port number.  The action is
+	<literal>allow</literal>, so the packet is released to the
+	LAN. The packet generated as a response is recognized by the
+	<literal>check-state</literal> as belonging to an existing
+	session.  It is then sent to rule 500 for
+	<acronym>NAT</acronym>ing and released to the outbound
+	interface.</para>
 
-	<para>Example Ruleset #1:</para>
+      <para>Example Ruleset #1:</para>
 
-	<programlisting>#!/bin/sh
+      <programlisting>#!/bin/sh
 cmd="ipfw -q add"
 skip="skipto 500"
 pif=rl0
_at__at_ -2340,13 +2339,13 _at__at_ ipfw -q -f flush
 
 ######################## end of rules  ##################</programlisting>
 
-	<para>The next example is functionally equivalent, but uses
-	  descriptive comments to help the inexperienced IPFW rule
-	  writer to better understand what the rules are doing.</para>
+      <para>The next example is functionally equivalent, but uses
+	descriptive comments to help the inexperienced IPFW rule
+	writer to better understand what the rules are doing.</para>
 
-	<para>Example Ruleset #2:</para>
+      <para>Example Ruleset #2:</para>
 
-	<programlisting>#!/bin/sh
+      <programlisting>#!/bin/sh
 ################ Start of IPFW rules file ###############################
 # Flush out the list before we begin.
 ipfw -q -f flush
_at__at_ -2499,130 +2498,132 _at__at_ pif="rl0"     # public interface name of
 &dollar;cmd 999 deny log all from any to any
 ################ End of IPFW rules file ###############################</programlisting>
 
-    <sect3>
-      <title>Port Redirection</title>
+      <sect3>
+	<title>Port Redirection</title>
 
-      <para>The drawback with &man.natd.8; is that the
-	<acronym>LAN</acronym> clients are not accessible from the
-	Internet.  Clients on the <acronym>LAN</acronym> can make
-	outgoing connections to the world but cannot receive incoming
-	ones.  This presents a problem if trying to run Internet
-	services on one of the <acronym>LAN</acronym> client machines.
-	A simple way around this is to redirect selected Internet
-	ports on the &man.natd.8; machine to a <acronym>LAN</acronym>
-	client.</para>
-
-      <para>For example, an <acronym>IRC</acronym> server runs on
-	client <systemitem>A</systemitem> and a web server runs on
-	client <systemitem>B</systemitem>.  For this to work properly,
-	connections received on ports 6667 (<acronym>IRC</acronym>)
-	and 80 (<acronym>HTTP</acronym>) must be redirected to the
-	respective machines.</para>
+	<para>The drawback with &man.natd.8; is that the
+	  <acronym>LAN</acronym> clients are not accessible from the
+	  Internet.  Clients on the <acronym>LAN</acronym> can make
+	  outgoing connections to the world but cannot receive
+	  incoming ones.  This presents a problem if trying to run
+	  Internet services on one of the <acronym>LAN</acronym>
+	  client machines.  A simple way around this is to redirect
+	  selected Internet ports on the &man.natd.8; machine to a
+	  <acronym>LAN</acronym> client.</para>
+
+	<para>For example, an <acronym>IRC</acronym> server runs on
+	  client <systemitem>A</systemitem> and a web server runs on
+	  client <systemitem>B</systemitem>.  For this to work
+	  properly, connections received on ports 6667
+	  (<acronym>IRC</acronym>) and 80 (<acronym>HTTP</acronym>)
+	  must be redirected to the respective machines.</para>
 
-      <para>The syntax for <option>-redirect_port</option> is as
-	follows:</para>
+	<para>The syntax for <option>-redirect_port</option> is as
+	  follows:</para>
 
-      <programlisting>     -redirect_port proto targetIP:targetPORT[-targetPORT]
+	<programlisting>     -redirect_port proto targetIP:targetPORT[-targetPORT]
                  [aliasIP:]aliasPORT[-aliasPORT]
                  [remoteIP[:remotePORT[-remotePORT]]]</programlisting>
 
-      <para>In the above example, the argument should be:</para>
+	<para>In the above example, the argument should be:</para>
 
-      <programlisting>    -redirect_port tcp 192.168.0.2:6667 6667
+	<programlisting>    -redirect_port tcp 192.168.0.2:6667 6667
     -redirect_port tcp 192.168.0.3:80 80</programlisting>
 
-      <para>This redirects the proper <acronym>TCP</acronym> ports
-	to the <acronym>LAN</acronym> client machines.</para>
+	<para>This redirects the proper <acronym>TCP</acronym> ports
+	  to the <acronym>LAN</acronym> client machines.</para>
 
-      <para>Port ranges over individual ports can be indicated with
-	<option>-redirect_port</option>.  For example,
-	<replaceable>tcp 192.168.0.2:2000-3000 2000-3000</replaceable>
-	would redirect all connections received on ports 2000 to 3000
-	to ports 2000 to 3000 on client
-	<systemitem>A</systemitem>.</para>
-
-      <para>These options can be used when directly running
-	&man.natd.8;, placed within the
-	<literal>natd_flags=""</literal> option in
-	<filename>/etc/rc.conf</filename>, or passed via a
-	configuration file.</para>
-
-      <para>For further configuration options, consult
-	&man.natd.8;</para>
-    </sect3>
+	<para>Port ranges over individual ports can be indicated with
+	  <option>-redirect_port</option>.  For example,
+	  <replaceable>tcp 192.168.0.2:2000-3000
+	    2000-3000</replaceable> would redirect all connections
+	  received on ports 2000 to 3000 to ports 2000 to 3000 on
+	  client <systemitem>A</systemitem>.</para>
+
+	<para>These options can be used when directly running
+	  &man.natd.8;, placed within the
+	  <literal>natd_flags=""</literal> option in
+	  <filename>/etc/rc.conf</filename>, or passed via a
+	  configuration file.</para>
 
-    <sect3>
-      <title>Address Redirection</title>
+	<para>For further configuration options, consult
+	  &man.natd.8;</para>
+      </sect3>
 
-      <indexterm>
-	<primary>address redirection</primary>
-      </indexterm>
+      <sect3>
+	<title>Address Redirection</title>
 
-      <para>Address redirection is useful if more than one
-	<acronym>IP</acronym> address is available.  Each
-	<acronym>LAN</acronym> client can be assigned its own
-	external <acronym>IP</acronym> address by &man.natd.8;,
-	which will then rewrite outgoing packets from the
-	<acronym>LAN</acronym> clients with the proper external
-	<acronym>IP</acronym> address and redirects all traffic
-	incoming on that particular <acronym>IP</acronym> address
-	back to the specific <acronym>LAN</acronym> client.  This is
-	also known as static <acronym>NAT</acronym>.  For example,
-	if <acronym>IP</acronym> addresses <systemitem
-	  class="ipaddress">128.1.1.1</systemitem>, <systemitem
-	  class="ipaddress">128.1.1.2</systemitem>, and <systemitem
-	  class="ipaddress">128.1.1.3</systemitem> are available,
-	<systemitem class="ipaddress">128.1.1.1</systemitem> can be
-	used as the &man.natd.8; machine's external
-	<acronym>IP</acronym> address, while <systemitem
-	  class="ipaddress">128.1.1.2</systemitem> and <systemitem
-	  class="ipaddress">128.1.1.3</systemitem> are forwarded back
-	to <acronym>LAN</acronym> clients <systemitem>A</systemitem>
-	and <systemitem>B</systemitem>.</para>
-
-      <para>The <option>-redirect_address</option> syntax is as
-	follows:</para>
-
-      <programlisting>-redirect_address localIP publicIP</programlisting>
-
-
-      <informaltable frame="none" pgwide="1">
-	<tgroup cols="2">
-	  <tbody>
-	    <row>
-	      <entry>localIP</entry>
-	      <entry>The internal <acronym>IP</acronym> address of
-		the <acronym>LAN</acronym> client.</entry>
-	    </row>
-
-	    <row>
-	      <entry>publicIP</entry>
-	      <entry>The external <acronym>IP</acronym> address
-		corresponding to the <acronym>LAN</acronym>
-		client.</entry>
-	    </row>
-	  </tbody>
-	</tgroup>
-      </informaltable>
+	<indexterm>
+	  <primary>address redirection</primary>
+	</indexterm>
 
-      <para>In the example, this argument would read:</para>
+	<para>Address redirection is useful if more than one
+	  <acronym>IP</acronym> address is available.  Each
+	  <acronym>LAN</acronym> client can be assigned its own
+	  external <acronym>IP</acronym> address by &man.natd.8;,
+	  which will then rewrite outgoing packets from the
+	  <acronym>LAN</acronym> clients with the proper external
+	  <acronym>IP</acronym> address and redirects all traffic
+	  incoming on that particular <acronym>IP</acronym> address
+	  back to the specific <acronym>LAN</acronym> client.  This is
+	  also known as static <acronym>NAT</acronym>.  For example,
+	  if <acronym>IP</acronym> addresses <systemitem
+	    class="ipaddress">128.1.1.1</systemitem>, <systemitem
+	    class="ipaddress">128.1.1.2</systemitem>, and <systemitem
+	    class="ipaddress">128.1.1.3</systemitem> are available,
+	  <systemitem class="ipaddress">128.1.1.1</systemitem> can be
+	  used as the &man.natd.8; machine's external
+	  <acronym>IP</acronym> address, while <systemitem
+	    class="ipaddress">128.1.1.2</systemitem> and <systemitem
+	    class="ipaddress">128.1.1.3</systemitem> are forwarded
+	  back to <acronym>LAN</acronym> clients
+	  <systemitem>A</systemitem> and
+	  <systemitem>B</systemitem>.</para>
+
+	<para>The <option>-redirect_address</option> syntax is as
+	  follows:</para>
+
+	<programlisting>-redirect_address localIP publicIP</programlisting>
+
+
+	<informaltable frame="none" pgwide="1">
+	  <tgroup cols="2">
+	    <tbody>
+	      <row>
+		<entry>localIP</entry>
+		<entry>The internal <acronym>IP</acronym> address of
+		  the <acronym>LAN</acronym> client.</entry>
+	      </row>
+
+	      <row>
+		<entry>publicIP</entry>
+		<entry>The external <acronym>IP</acronym> address
+		  corresponding to the <acronym>LAN</acronym>
+		  client.</entry>
+	      </row>
+	    </tbody>
+	  </tgroup>
+	</informaltable>
 
-      <programlisting>-redirect_address 192.168.0.2 128.1.1.2
+	<para>In the example, this argument would read:</para>
+
+	<programlisting>-redirect_address 192.168.0.2 128.1.1.2
 -redirect_address 192.168.0.3 128.1.1.3</programlisting>
 
-      <para>Like <option>-redirect_port</option>, these arguments are
-	placed within the <literal>natd_flags=""</literal> option
-	of <filename>/etc/rc.conf</filename>, or passed via a
-	configuration file.  With address redirection, there is no
-	need for port redirection since all data received on a
-	particular <acronym>IP</acronym> address is redirected.</para>
-
-      <para>The external <acronym>IP</acronym> addresses on the
-	&man.natd.8; machine must be active and aliased to the
-	external interface.  Refer to &man.rc.conf.5; for
-	details.</para>
-    </sect3>
-</sect2>     
+	<para>Like <option>-redirect_port</option>, these arguments
+	  are placed within the <literal>natd_flags=""</literal>
+	  option of <filename>/etc/rc.conf</filename>, or passed via a
+	  configuration file.  With address redirection, there is no
+	  need for port redirection since all data received on a
+	  particular <acronym>IP</acronym> address is
+	  redirected.</para>
+
+	<para>The external <acronym>IP</acronym> addresses on the
+	  &man.natd.8; machine must be active and aliased to the
+	  external interface.  Refer to &man.rc.conf.5; for
+	  details.</para>
+      </sect3>
+    </sect2>
 
     <sect2 xml:id="firewalls-ipfw-cmd">
       <title>The <application>IPFW</application> Command</title>
Received on Wed Feb 26 2014 - 23:44:34 UTC