Page MenuHomeFreeBSD
Files F137014013

D23426.id68463.diff
No OneTemporary
Actions

D23426.id68463.diff
View Options

Index: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
===================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
@@ -2153,15 +2153,13 @@
</indexterm>
<para>&os;'s <application>IPFW</application> firewall has two
- implementations of <acronym>NAT</acronym>: one being the
- userland &man.natd.8; daemon, and the more recent
- <application>IPFW</application>'s built-in
- <acronym>NAT</acronym> facility also known as in-kernel
- <acronym>NAT</acronym>. Both work 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 a single public
+ implementations of <acronym>NAT</acronym>: the userland
+ implementation &man.natd.8;, and the more recent in-kernel
+ <acronym>NAT</acronym> implementation. Both work 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 a single public
<acronym>IP</acronym> address.</para>
<para>To do this, the &os; machine connected to the Internet
@@ -2176,7 +2174,7 @@
1918</link>.</para>
<para>Some additional configuration is needed in order to enable
- the in-kernel <acronym>NAT</acronym> function of
+ the in-kernel <acronym>NAT</acronym> facility of
<application>IPFW</application>. To enable in-kernel
<acronym>NAT</acronym> support at boot time, the following
must be set in <filename>/etc/rc.conf</filename>:</para>
@@ -2186,9 +2184,9 @@
firewall_nat_enable="YES"</programlisting>
<note>
- <para>When <literal>firewall_enable</literal> is not set,
- but <literal>firewall_nat_enable</literal> is, it will have
- no effect and do nothing, because the in-kernel
+ <para>When <literal>firewall_nat_enable</literal> is set but
+ <literal>firewall_enable</literal> is not, it will have no
+ effect and do nothing. This is because the in-kernel
<acronym>NAT</acronym> implementation is only compatible
with <application>IPFW</application>.</para></note>
@@ -2196,30 +2194,16 @@
of the <acronym>NAT</acronym> rule is critical and the
<literal>skipto</literal> action is used. The
<literal>skipto</literal> action requires a rule number so
- that it knows which rule to jump to. Furthermore, because
- of the architecture of &man.libalias.3;, a library implemented
- as a kernel module used for the in-kernel
- <acronym>NAT</acronym> facility of
- <application>IPFW</application>, it is necessary to disable
- TCP segmentation offloading, or in short
- <acronym>TSO</acronym>. <acronym>TSO</acronym> can be
- disabled on a per network interface basis by using
- &man.ifconfig.8; or on a system wide basis using
- &man.sysctl.8;. To disable <acronym>TSO</acronym> system
- wide, the following must be set in
- <filename>/etc/sysctl.conf</filename>:</para>
+ that it knows which rule to jump to. The example below builds
+ upon the firewall ruleset shown in the previous section. It
+ adds some additional entries and modifies some existing rules
+ in order to configure the firewall for in-kernel
+ <acronym>NAT</acronym>. It starts by adding some additional
+ variables which represent the rule number to skip to, the
+ <literal>keep-state</literal> option, and a list of
+ <acronym>TCP</acronym> ports which will be used to reduce the
+ number of rules.</para>
- <programlisting>net.inet.tcp.tso="0"</programlisting>
-
- <para>The example below builds upon the firewall ruleset
- shown in the previous section. It adds some additional
- entries and modifies some existing rules in order to configure
- the firewall for in-kernel <acronym>NAT</acronym>. It starts
- by adding some additional variables which represent the rule
- number to skip to, the <literal>keep-state</literal> option,
- and a list of <acronym>TCP</acronym> ports which will be used
- to reduce the number of rules.</para>
-
<programlisting>#!/bin/sh
ipfw -q -f flush
cmd="ipfw -q add"
@@ -2228,28 +2212,41 @@
ks="keep-state"
good_tcpo="22,25,37,53,80,443,110"</programlisting>
- <para>A <acronym>NAT</acronym> instance will also be
- configured. With in-kernel <acronym>NAT</acronym> it is
- possible to have multiple <acronym>NAT</acronym> instances
- each with their own configuration. Although, for this example
- only one <acronym>NAT</acronym> instance is needed;
+ <para>With in-kernel <acronym>NAT</acronym> it is
+ necessary to disable TCP segmentation offloading
+ (<acronym>TSO</acronym>) due to the architecture of
+ &man.libalias.3;, a library implemented as a kernel module to
+ provide the in-kernel <acronym>NAT</acronym> facility of
+ <application>IPFW</application>. <acronym>TSO</acronym> can
+ be disabled on a per network interface basis using
+ &man.ifconfig.8; or on a system wide basis using
+ &man.sysctl.8;. To disable <acronym>TSO</acronym> system
+ wide, the following must be set it
+ <filename>/etc/sysctl.conf</filename>:</para>
+
+ <programlisting>net.inet.tcp.tso="0"</programlisting>
+
+ <para>A <acronym>NAT</acronym> instance will also be configured.
+ It is possible to have multiple <acronym>NAT</acronym>
+ instances each with their own configuration. For this example
+ only one <acronym>NAT</acronym> instance is needed,
<acronym>NAT</acronym> instance number 1. The configuration
- takes a few arguments and flags such as: <option>if</option>
- which indicates the public interface,
- <option>same_ports</option> which takes care that alliased
- ports and local port numbers are mapped the same,
- <option>unreg_only</option> will result in only unregistered
- (private) address spaces to be processed by the
- <acronym>NAT</acronym> instance, and <option>reset</option>
- which will help to keep a functioning <acronym>NAT</acronym>
- instance even when the public <acronym>IP</acronym> address of
- the <application>IPFW</application> machine changes. For all
+ can take a few options such as: <option>if</option> which
+ indicates the public interface, <option>same_ports</option>
+ which takes care that alliased ports and local port numbers
+ are mapped the same, <option>unreg_only</option> will result
+ in only unregistered (private) address spaces to be processed
+ by the <acronym>NAT</acronym> instance, and
+ <option>reset</option> which will help to keep a functioning
+ <acronym>NAT</acronym> instance even when the public
+ <acronym>IP</acronym> address of the
+ <application>IPFW</application> machine changes. For all
possible options that can be passed to a single
<acronym>NAT</acronym> instance configuration consult
- &man.ipfw.8;. Furthermore, because of the nature of a
- stateful <acronym>NAT</acronym>ing firewall, it is neseccary
- to allow translated packets to be reinjected in the firewall
- for further processing, this can be achieved by disabling
+ &man.ipfw.8;. When configuring a stateful
+ <acronym>NAT</acronym>ing firewall, it is neseccary to allow
+ translated packets to be reinjected in the firewall for
+ further processing. This can be achieved by disabling
<option>one_pass</option> behavior at the start of the
firewall script.</para>
@@ -2272,21 +2269,21 @@
happen, but when dealing with <acronym>IPSEC/ESP/GRE</acronym>
tunneling traffic it might and the reassmabling of fragments
is necessary before handing the complete packet over to the
- in-kernel <acronym>NAT</acronym> engine.</para>
+ in-kernel <acronym>NAT</acronym> facility.</para>
<note>
<para>The reassemble rule was not needed with userland
&man.natd.8; because the internal workings of the
<application>IPFW</application> <literal>divert</literal>
- action already takes care of this automatically as also
- stated in &man.ipfw.8;.</para>
+ action already takes care of reassambling packets before
+ delivery to the socket as also stated in &man.ipfw.8;.</para>
- <para>The current <acronym>NAT</acronym> instance number and
- <acronym>NAT</acronym> rule number does not match with the
- default <acronym>NAT</acronym> instance number and rule
- number created by <filename>rc.firewall</filename> which is
- a script to set up the baked-in default firewall rulesets
- present in &os;.</para></note>
+ <para>The <acronym>NAT</acronym> instance and rule number used
+ in this example does not match with the default
+ <acronym>NAT</acronym> instance and rule number created by
+ <filename>rc.firewall</filename>.
+ <filename>rc.firewall</filename> is a script that sets up
+ the default firewall rules present in &os;.</para></note>
<programlisting>&dollar;cmd 005 allow all from any to any via xl0 # exclude LAN traffic
&dollar;cmd 010 allow all from any to any via lo0 # exclude loopback traffic
@@ -2306,8 +2303,8 @@
<note>
<para>Remember that <application>IPFW</application>'s
- firewall performance is largely determined by the number of
- rules present in the ruleset.</para></note>
+ performance is largely determined by the number of rules
+ present in the ruleset.</para></note>
<programlisting># Authorized outbound packets
&dollar;cmd 120 &dollar;skip udp from any to x.x.x.x 53 out via &dollar;pif &dollar;ks
@@ -2375,17 +2372,18 @@
interface.</para>
<note>
- <para>Transition from userland &man.natd.8; to in-kernel
+ <para>Transitioning from userland &man.natd.8; to in-kernel
<acronym>NAT</acronym> might seem seamless at first but
there is small catch. When using the GENERIC kernel,
<application>IPFW</application> will load the
- <filename>libalias.ko</filename>
- kernel module, when <literal>firewall_nat_enable</literal>
- is enabled in <filename>rc.conf</filename>. Although, the
- loaded module only provides basic <acronym>NAT</acronym>
- functionality, whereas the userland implementation
- &man.natd.8; has all functionality available without any
- extra configuration from its userland library. All
+ <filename>libalias.ko</filename> kernel module, when
+ <literal>firewall_nat_enable</literal> is enabled in
+ <filename>rc.conf</filename>. The
+ <filename>libalias.ko</filename> kernel module only provides
+ basic <acronym>NAT</acronym> functionality, whereas the
+ userland implementation &man.natd.8; has all
+ <acronym>NAT</acronym> functionality available in its
+ userland library without any extra configuration. All
functionality refers to the following kernel modules that
can additionally be loaded when needed besides the standard
<filename>libalias.ko</filename> kernel module:
@@ -2396,10 +2394,9 @@
<filename>alias_pptp.ko</filename> and
<filename>alias_smedia.ko</filename> using the
<literal>kld_list</literal> directive in
- <filename>rc.conf</filename> to mimic the full functionality
- of the userland implementation. If a custom kernel is used,
+ <filename>rc.conf</filename>. If a custom kernel is used,
the full functionality of the userland library can be
- compiled in, in the kernel, using the <option>option
+ compiled in, in the kernel, using the <option>options
LIBALIAS</option>.</para></note>
<sect3>
@@ -2450,7 +2447,7 @@
<programlisting>ipfw -q nat 1 config if &dollar;pif same_ports unreg_only reset \
redirect_port tcp 192.168.0.2:6667 6667 \
- redirect_port tcp 192.1683.0.3:80 80</programlisting>
+ redirect_port tcp 192.168.0.3:80 80</programlisting>
<para>Port ranges over individual ports can be indicated with
<option>redirect_port</option>. For example,
@@ -2518,7 +2515,7 @@
<para>Let us start with a statement: the userspace
<acronym>NAT</acronym> implementation: &man.natd.8;, has
- more overhead than in-kernel <acronym>NAT</acronym>. For
+ more overhead than in-kernel <acronym>NAT</acronym>. For
&man.natd.8; to translate packets, the packets have to be
copied from the kernel to userspace and back which brings in
extra overhead that is not present with in-kernel
@@ -2539,13 +2536,13 @@
<para>In general, the above ruleset as explained for in-kernel
<acronym>NAT</acronym> can also be used together with
- &man.natd.8;. The only exceptions are the configuration of
- the in-kernel <acronym>NAT</acronym> instance <literal>(ipfw
- -q nat 1 config ...)</literal> not being applicable any
- more, rule number 100 and 1000 will have to change sligthly
- as below, and reassemble rule 99 is not needed anymore
- as the <option>divert</option> action is used which covers
- fragmentation.</para>
+ &man.natd.8;. The exceptions are the configuration of the
+ in-kernel <acronym>NAT</acronym> instance <literal>(ipfw -q
+ nat 1 config ...)</literal> which is not needed together
+ with reassemble rule 99 because its functionality is
+ included in the <option>divert</option> action. Rule number
+ 100 and 1000 will have to change sligthly as shown
+ below.</para>
<programlisting>&dollar;cmd 100 divert natd ip from any to any in via &dollar;pif
&dollar;cmd 1000 divert natd ip from any to any out via &dollar;pif</programlisting>
@@ -2777,7 +2774,8 @@
options IPFIREWALL_VERBOSE # enables logging for rules with log keyword to syslogd(8)
options IPFIREWALL_VERBOSE_LIMIT=5 # limits number of logged packets per-entry
options IPFIREWALL_DEFAULT_TO_ACCEPT # sets default policy to pass what is not explicitly denied
-options IPFIREWALL_NAT # enables in-kernel NAT support
+options IPFIREWALL_NAT # enables basic in-kernel NAT support
+options LIBALIAS # enables full in-kernel NAT support
options IPFIREWALL_NAT64 # enables in-kernel NAT64 support
options IPFIREWALL_NPTV6 # enables in-kernel IPv6 NPT support
options IPFIREWALL_PMOD # enables protocols modification module support

File Metadata

Mime Type
text/plain
Expires
Fri, Nov 21, 11:52 PM (16 h, 1 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
25829790
Default Alt Text
D23426.id68463.diff (13 KB)

Event Timeline