svn commit: r43998 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Wed Feb 19 21:58:49 UTC 2014
Author: dru
Date: Wed Feb 19 21:58:48 2014
New Revision: 43998
URL: http://svnweb.freebsd.org/changeset/doc/43998
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 19 21:22:40 2014 (r43997)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 21:58:48 2014 (r43998)
@@ -1508,26 +1508,28 @@ block drop out quick on $ext_if from any
</indexterm>
<para><application>IPFILTER</application>, also known as
- <application>IPF</application>, is a cross-platform, open source firewall which
- has been ported to several operating systems, including &os;, NetBSD, OpenBSD, and
- &solaris;.</para>
-
- <para><application>IPFILTER</application> is a kernel-side firewall and
- <acronym>NAT</acronym> mechanism that can be controlled and
- monitored by userland programs. Firewall rules
+ <application>IPF</application>, is a cross-platform, open source
+ firewall which has been ported to several operating systems,
+ including &os;, NetBSD, OpenBSD, and &solaris;.</para>
+
+ <para><application>IPFILTER</application> is a kernel-side
+ firewall and <acronym>NAT</acronym> mechanism that can be
+ controlled and monitored by userland programs. Firewall rules
can be set or deleted using <application>ipf</application>,
<acronym>NAT</acronym> rules can be set or deleted using
- <application>ipnat</application>, run-time statistics for the kernel parts of
- <application>IPFILTER</application> can be printed using
- <application>ipfstat</application>, and
- <application>ipmon</application> can be used to log <application>IPFILTER</application>
- actions to the system log files.</para>
-
- <para><application>IPF</application> was originally written using a rule processing logic
- of <quote>the last matching rule wins</quote> and only used
- stateless rules. Since then, <application>IPF</application> has been enhanced to include
- the <literal>quick</literal> and
- <literal>keep state</literal> options.</para>
+ <application>ipnat</application>, run-time statistics for the
+ kernel parts of <application>IPFILTER</application> can be
+ printed using <application>ipfstat</application>, and
+ <application>ipmon</application> can be used to log
+ <application>IPFILTER</application> actions to the system log
+ files.</para>
+
+ <para><application>IPF</application> was originally written using
+ a rule processing logic of <quote>the last matching rule
+ wins</quote> and only used stateless rules. Since then,
+ <application>IPF</application> has been enhanced to include the
+ <literal>quick</literal> and <literal>keep state</literal>
+ options.</para>
<para>For a detailed explanation of the legacy rules processing
method, refer to <uri
@@ -1535,15 +1537,16 @@ block drop out quick on $ext_if from any
<para>The <application>IPF</application> FAQ is at <uri
xlink:href="http://www.phildev.net/ipf/index.html">http://www.phildev.net/ipf/index.html</uri>.
- A searchable archive of the IPFilter mailing list is
- available at <uri
+ A searchable archive of the IPFilter mailing list is available
+ at <uri
xlink:href="http://marc.info/?l=ipfilter">http://marc.info/?l=ipfilter</uri>.</para>
<para>This section of the Handbook focuses on
- <application>IPF</application> as it pertains to FreeBSD.
- It provides examples which uses
- rules that contain the <literal>quick</literal> and
- <literal>keep state</literal> options.</para>
+ <application>IPF</application> as it pertains to FreeBSD. It
+ provides examples which uses rules that contain the
+ <literal>quick</literal> and <literal>keep state</literal>
+ options.</para>
+
<sect2>
<title>Enabling <application>IPF</application></title>
@@ -1553,9 +1556,10 @@ block drop out quick on $ext_if from any
<secondary>enabling</secondary>
</indexterm>
- <para><application>IPF</application> is included in the basic &os; install as a kernel
- loadable module, meaning that a custom kernel is not needed in
- order to enable <application>IPF</application>.</para>
+ <para><application>IPF</application> is included in the basic
+ &os; install as a kernel loadable module, meaning that a
+ custom kernel is not needed in order to enable
+ <application>IPF</application>.</para>
<indexterm>
<primary>kernel options</primary>
@@ -1581,35 +1585,37 @@ block drop out quick on $ext_if from any
<secondary>kernel options</secondary>
</indexterm>
- <para>For users who prefer to statically compile <application>IPF</application> support
- into a custom kernel, refer to the instructions in <xref
- linkend="kernelconfig"/>. The following kernel options are
- available:</para>
+ <para>For users who prefer to statically compile
+ <application>IPF</application> support into a custom kernel,
+ refer to the instructions in <xref linkend="kernelconfig"/>.
+ The following kernel options are available:</para>
<programlisting>options IPFILTER
options IPFILTER_LOG
options IPFILTER_LOOKUP
options IPFILTER_DEFAULT_BLOCK</programlisting>
- <para>where <literal>options IPFILTER</literal> enables support for
- <application>IPFILTER</application>, <literal>options IPFILTER_LOG</literal> enables <application>IPF</application>
- logging using the <filename>ipl</filename> packet logging
- pseudo device for every rule that has the
- <literal>log</literal> keyword,
- <literal>IPFILTER_LOOKUP</literal> enables <acronym>IP</acronym> pools in
- order to speed up <acronym>IP</acronym> lookups, and <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>To configure the system to enable <application>IPF</application>
- at boot time, add
- the following entries to
- <filename>/etc/rc.conf</filename>. These entries will also enable logging and
- <literal>default pass all</literal>. To change the
- default policy to <literal>block all</literal> without
- compiling a custom kernel, remember to add a
- <literal>block all</literal> rule at the end of the
- ruleset.</para>
+ <para>where <literal>options IPFILTER</literal> enables support
+ for <application>IPFILTER</application>,
+ <literal>options IPFILTER_LOG</literal> enables
+ <application>IPF</application> logging using the
+ <filename>ipl</filename> packet logging pseudo device for
+ every rule that has the <literal>log</literal> keyword,
+ <literal>IPFILTER_LOOKUP</literal> enables
+ <acronym>IP</acronym> pools in order to speed up
+ <acronym>IP</acronym> lookups, and <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>To configure the system to enable
+ <application>IPF</application> at boot time, add the following
+ entries to <filename>/etc/rc.conf</filename>. These entries
+ will also enable logging and <literal>default pass
+ all</literal>. To change the default policy to
+ <literal>block all</literal> without compiling a custom
+ kernel, remember to add a <literal>block all</literal> rule at
+ the end of the ruleset.</para>
<programlisting>ipfilter_enable="YES" # Start ipf firewall
ipfilter_rules="/etc/ipf.rules" # loads rules definition text file
@@ -1619,17 +1625,16 @@ ipmon_flags="-Ds" # D =
# v = log tcp window, ack, seq
# n = map IP & port to names</programlisting>
- <para>If <acronym>NAT</acronym>
- functionality is needed, also add these lines:</para>
+ <para>If <acronym>NAT</acronym> functionality is needed, also
+ add these lines:</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>
<para>Then, to start <application>IPF</application> now:</para>
-
+
<programlisting>&prompt.root; <command>service ipfilter start</command></programlisting>
-
</sect2>
<sect2>
@@ -1640,8 +1645,8 @@ ipnat_rules="/etc/ipnat.rules" # rule
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
+ 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
@@ -1693,7 +1698,7 @@ ipnat_rules="/etc/ipnat.rules" # rule
<para>There is a way to build IPF rules that utilize the power
of script symbolic substitution. For more information, see
- <xref linkend="firewalls-ipf-rules-script"/>.</para>
+ <xref linkend="firewalls-ipf-rules-script"/>.</para>
<indexterm>
<primary><application>IPFILTER</application></primary>
@@ -1728,196 +1733,205 @@ ipnat_rules="/etc/ipnat.rules" # rule
<variablelist>
<varlistentry>
- <term>ACTION</term>
- <listitem>
- <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>
- </listitem>
- </varlistentry>
+ <term>ACTION</term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>IN-OUT</term>
- <listitem>
- <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>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>IN-OUT</term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>OPTIONS</term>
- <listitem>
- <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>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>OPTIONS</term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>SELECTION</term>
- <listitem>
- <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>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>SELECTION</term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>PROTO</term>
- <listitem>
- <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>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>PROTO</term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>SRC_ADDR/DST_ADDR</term>
- <listitem>
- <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
- <package>net-mgmt/ipcalc</package> port may be used to ease
- the calculation. Additional information is available at the
- utility's web page: <uri
- xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>SRC_ADDR/DST_ADDR</term>
+ <listitem>
+ <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
+ <package>net-mgmt/ipcalc</package> port may be used to
+ ease the calculation. Additional information is
+ available at the utility's web page: <uri
+ xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>PORT</term>
- <listitem>
- <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><</literal>, <literal>></literal>,
- <literal><=</literal>, <literal>>=</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><></literal> or
- <literal>><</literal></para>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>PORT</term>
+ <listitem>
+ <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><</literal>,
+ <literal>></literal>, <literal><=</literal>,
+ <literal>>=</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><></literal> or
+ <literal>><</literal></para>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term><acronym>TCP</acronym>_FLAG</term>
- <listitem>
- <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>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term><acronym>TCP</acronym>_FLAG</term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>STATEFUL</term>
- <listitem>
- <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>
- </listitem>
- </varlistentry>
- </variablelist>
+ <varlistentry>
+ <term>STATEFUL</term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</sect2>
<sect2>
@@ -2332,8 +2346,9 @@ EOF
</listitem>
<listitem>
- <para>Disable <application>IPFILTER</application> in the system startup scripts by
- adding <literal>ipfilter_enable="NO"</literal>to
+ <para>Disable <application>IPFILTER</application> 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
@@ -2383,7 +2398,7 @@ sh /etc/ipf.rules.script</programlisting
having to pay the ISP for multiple Internet accounts or IP
addresses.</para>
- <para>In IPF, when a packet arrives at the firewall from the LAN
+ <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
@@ -2402,7 +2417,7 @@ sh /etc/ipf.rules.script</programlisting
private IP address and then passed to the filter rules for
processing.</para>
- <para><acronym>NAT</acronym> will automatically translate the
+ <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
@@ -2510,18 +2525,19 @@ sh /etc/ipf.rules.script</programlisting
<literal>0/32</literal> which uses the IP address assigned to
<replaceable>IF</replaceable>.</para>
- <sect3>
- <title><acronym>NAT</acronym> for a Large LAN</title>
+ <sect3>
+ <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. This section describes two ways to
- relieve this resource problem.</para>
+ <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. This section
+ describes two ways to relieve this resource problem.</para>
- <para>The first method is to assign ports to use. A normal NAT rule would look like:</para>
+ <para>The first method is to assign ports to use. A normal
+ NAT rule would look like:</para>
<programlisting>map dc0 192.168.1.0/24 -> 0/32</programlisting>
@@ -2541,7 +2557,8 @@ sh /etc/ipf.rules.script</programlisting
<programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto</programlisting>
- <para>The second method is to use a pool of public addresses. In very large LANs there comes a point where there are
+ <para>The second method is to use a pool of public addresses.
+ 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
@@ -2564,19 +2581,20 @@ sh /etc/ipf.rules.script</programlisting
<programlisting>map dc0 192.168.1.0/24 -> 204.134.75.0/24</programlisting>
</sect3>
- <sect3>
- <title>Port Redirection</title>
+ <sect3>
+ <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 <systemitem class="ipaddress">10.0.10.25</systemitem>
- and using a single public IP address of
- <systemitem class="ipaddress">20.20.20.5</systemitem>, would
- use this rule:</para>
+ <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 <systemitem
+ class="ipaddress">10.0.10.25</systemitem> and using a
+ single public IP address of <systemitem
+ class="ipaddress">20.20.20.5</systemitem>, would use this
+ rule:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80</programlisting>
@@ -2589,17 +2607,17 @@ sh /etc/ipf.rules.script</programlisting
needs to receive public DNS requests:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp</programlisting>
- </sect3>
+ </sect3>
- <sect3>
- <title>FTP and <acronym>NAT</acronym></title>
+ <sect3>
+ <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 <uri
- xlink:href="http://www.slacksite.com/other/ftp.html">http://www.slacksite.com/other/ftp.html</uri>.</para>
+ <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 <uri
+ xlink:href="http://www.slacksite.com/other/ftp.html">http://www.slacksite.com/other/ftp.html</uri>.</para>
<para>IP<acronym>NAT</acronym> has a built in FTP proxy option
which can be specified on the <acronym>NAT</acronym> map
@@ -2797,9 +2815,9 @@ LOG_ERR - packets which have been logged
<!-- XXX: "can be considered short" == "with incomplete header" -->
- <para>In order to setup <application>IPFILTER</application> to log all data to
- <filename>/var/log/ipfilter.log</filename>, first
- create the empty file:</para>
+ <para>In order to setup <application>IPFILTER</application> 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>
@@ -2896,7 +2914,7 @@ LOG_ERR - packets which have been logged
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>
</sect1>
<sect1 xml:id="firewalls-ipfw">
More information about the svn-doc-all
mailing list