Index: en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
===================================================================
--- en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
+++ en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
@@ -1698,7 +1698,7 @@
Only firewall rules with the option will
be logged. The default rules do not include this option and it
- must be manually added. Therefor it is advisable that the default
+ must be manually added. Therefore it is advisable that the default
ruleset is edited for logging. In addition, log rotation may be
desired if the logs are stored in a separate file.
@@ -2121,9 +2121,9 @@
$cmd 00999 deny log all from any to any
-
+
- Configuring NAT
+ In-kernel NAT
@@ -2134,19 +2134,34 @@
Contributed by
+
+
+
+
+ Dries
+ Michiels
+
+ Rewritten and updated by
+
+
+
NATand IPFW
- &os;'s built-in NAT daemon,
- &man.natd.8;, works in conjunction with
+ &os;'s IPFW firewall has two
+ implementations of NAT: one being the
+ userland &man.natd.8; daemon, and the more recent
+ IPFW's built-in
+ NAT facility also known as in-kernel
+ NAT. Both work in conjunction with
IPFW 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
+ can connect to the Internet using a single public
IP address.To do this, the &os; machine connected to the Internet
@@ -2157,92 +2172,143 @@
LAN should be assigned an
IP address in the private network space, as
defined by RFC
- 1918, and have the default gateway set to the
- &man.natd.8; system's internal IP
- address.
+ xlink:href="https://www.ietf.org/rfc/rfc1918.txt">RFC
+ 1918.
- Some additional configuration is needed in order to
- activate the NAT function of
- IPFW. If the system has a custom
- kernel, the kernel configuration file needs to include
- option IPDIVERT along with the other
- IPFIREWALL options described in .
+ Some additional configuration is needed in order to enable
+ the in-kernel NAT function of
+ IPFW. To enable in-kernel
+ NAT support at boot time, the following
+ must be set in /etc/rc.conf:
- To enable NAT support at boot time, the
- following must be in /etc/rc.conf:
+ gateway_enable="YES"
+firewall_enable="YES"
+firewall_nat_enable="YES"
- gateway_enable="YES" # enables the gateway
-natd_enable="YES" # enables NAT
-natd_interface="rl0" # specify interface name of NIC attached to Internet
-natd_flags="-dynamic -m" # -m = preserve port numbers; additional options are listed in &man.natd.8;
-
- It is also possible to specify a configuration file
- which contains the options to pass to &man.natd.8;:
+ When firewall_enable is not set,
+ but firewall_nat_enable is, it will have
+ no effect and do nothing, because the in-kernel
+ NAT implementation is only compatible
+ with IPFW.
- natd_flags="-f /etc/natd.conf"
-
- The specified file must contain a list of configuration
- options, one per line. For example:
-
- redirect_port tcp 192.168.0.2:6667 6667
-redirect_port tcp 192.168.0.3:80 80
-
- For more information about this configuration file,
- consult &man.natd.8;.
-
-
- Next, add the NAT rules to the firewall
- ruleset. When the rulest contains stateful rules, the
- positioning of the NAT rules is critical
- and the skipto action is used. The
+ When the ruleset contains stateful rules, the positioning
+ of the NAT rule is critical and the
+ skipto action is used. The
skipto action requires a rule number so
- that it knows which rule to jump to.
+ 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
+ NAT facility of
+ IPFW, it is necessary to disable
+ TCP segmentation offloading, or in short
+ TSO. TSO 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 TSO system
+ wide, the following must be set in
+ /etc/sysctl.conf:
- The following example builds upon the firewall ruleset
+ net.inet.tcp.tso="0"
+
+ 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 NAT. It starts by adding
- some additional variables which represent the rule number to
- skip to, the keep-state option, and a list
- of TCP ports which will be used to reduce
- the number of rules:
+ the firewall for in-kernel NAT. It starts
+ by adding some additional variables which represent the rule
+ number to skip to, the keep-state option,
+ and a list of TCP ports which will be used
+ to reduce the number of rules.#!/bin/sh
ipfw -q -f flush
cmd="ipfw -q add"
-skip="skipto 500"
+skip="skipto 1000"
pif=dc0
ks="keep-state"
good_tcpo="22,25,37,53,80,443,110"
+ A NAT instance will also be
+ configured. With in-kernel NAT it is
+ possible to have multiple NAT instances
+ each with their own configuration. Although, for this example
+ only one NAT instance is needed;
+ NAT instance number 1. The configuration
+ takes a few arguments and flags such as:
+ which indicates the public interface,
+ which takes care that alliased
+ ports and local port numbers are mapped the same,
+ will result in only unregistered
+ (private) address spaces to be processed by the
+ NAT instance, and
+ which will help to keep a functioning NAT
+ instance even when the public IP address of
+ the IPFW machine changes. For all
+ possible options that can be passed to a single
+ NAT instance configuration consult
+ &man.ipfw.8;. Furthermore, because of the nature of a
+ stateful NATing firewall, it is neseccary
+ to allow translated packets to be reinjected in the firewall
+ for further processing, this can be achieved by disabling
+ behavior at the start of the
+ firewall script.
+
+ ipfw disable one_pass
+ipfw -q nat 1 config if $pif same_ports unreg_only reset
+
The inbound NAT rule is inserted
after the two rules which allow all
- traffic on the trusted internal interface and on the loopback
- interface and before the
+ traffic on the trusted and loopback interfaces and after the
+ reassamble rule but before the
check-state rule. It is important that the
rule number selected for this NAT rule, in
this example 100, is higher than the first
- two rules and lower than the check-state
- rule:
+ three rules and lower than the check-state
+ rule. Furthermore, because of the behavior of in-kernel
+ NAT it is advised to place a reassamble
+ rule just before the first NAT rule and
+ after the rules that allow traffic on trusted interface.
+ Normally, IP fragmentation should not
+ happen, but when dealing with IPSEC/ESP/GRE
+ tunneling traffic it might and the reassmabling of fragments
+ is necessary before handing the complete packet over to the
+ in-kernel NAT engine.
+
+ The reassemble rule was not needed with userland
+ &man.natd.8; because the internal workings of the
+ IPFWdivert
+ action already takes care of this automatically as also
+ stated in &man.ipfw.8;.
+
+ The current NAT instance number and
+ NAT rule number does not match with the
+ default NAT instance number and rule
+ number created by firewall.rc which is
+ a script to set up the baked-in default firewall rulesets
+ present in &os;.
+
$cmd 005 allow all from any to any via xl0 # exclude LAN traffic
$cmd 010 allow all from any to any via lo0 # exclude loopback traffic
-$cmd 100 divert natd ip from any to any in via $pif # NAT any inbound packets
+$cmd 099 reass all from any to any in # reassamble inbound packets
+$cmd 100 nat 1 ip from any to any in via $pif # NAT any inbound packets
# Allow the packet through if it has an existing entry in the dynamic rules table
$cmd 101 check-stateThe outbound rules are modified to replace the
allow action with the
$skip variable, indicating that rule
- processing will continue at rule 500. The
+ processing will continue at rule 1000. The
seven tcp rules have been replaced by rule
125 as the
$good_tcpo variable contains the
seven allowed outbound ports.
+
+ Remember that IPFW's
+ firewall performance is largely determined by the number of
+ rules present in the ruleset.
+
# Authorized outbound packets
$cmd 120 $skip udp from any to x.x.x.x 53 out via $pif $ks
$cmd 121 $skip udp from any to x.x.x.x 67 out via $pif $ks
@@ -2256,20 +2322,19 @@
rule, must have a higher number than that last rule, and the
rule number must be referenced by the
skipto action. In this ruleset, rule
- number 500 diverts all packets which match
- the outbound rules to &man.natd.8; for
- NAT processing. The next rule allows any
- packet which has undergone NAT processing
- to pass.
+ number 1000 handles passing all packets to
+ our configured instance for NAT processing.
+ The next rule allows any packet which has undergone
+ NAT processing to pass.
- $cmd 499 deny log all from any to any
-$cmd 500 divert natd ip from any to any out via $pif # skipto location for outbound stateful rules
-$cmd 510 allow ip from any to any
+ $cmd 999 deny log all from any to any
+$cmd 1000 nat 1 ip from any to any out via $pif # skipto location for outbound stateful rules
+$cmd 1001 allow ip from any to anyIn this example, rules 100,
101, 125,
- 500, and 510 control the
- address translation of the outbound and inbound packets so
+ 1000, and 1001 control
+ the address translation of the outbound and inbound packets so
that the entries in the dynamic state table always register
the private LAN IP
address.
@@ -2286,7 +2351,7 @@
internal LAN. On matching this rule, two
actions take place. First, the keep-state
action adds an entry to the dynamic state table and the
- specified action, skipto rule 500, is
+ specified action, skipto rule 1000, is
executed. Next, the packet undergoes NAT
and is sent out to the Internet. This packet makes its way to
the destination web server, where a response packet is
@@ -2305,22 +2370,50 @@
generated as a response is recognized by the
check-state rule as belonging to an
existing session. It is then sent to rule
- 500 to undergo
+ 1000 to undergo
NAT before being released to the outbound
interface.
+
+ Transition from userland &man.natd.8; to in-kernel
+ NAT might seem seamless at first but
+ there is small catch. When using the GENERIC kernel,
+ IPFW will load the
+ libalias.ko
+ kernel module, when firewall_nat_enable
+ is enabled in rc.conf. Although, the
+ loaded module only provides basic NAT
+ functionality, whereas the userland implementation
+ &man.natd.8; has all functionality available without any
+ extra configuration from its userland library. All
+ functionality refers to the following kernel modules that
+ can additionally be loaded when needed besides the standard
+ libalias.ko kernel module:
+ alias_cuseeme.ko,
+ alias_ftp.ko,
+ alias_bbt.ko,
+ skinny.ko, irc.ko,
+ alias_pptp.ko and
+ alias_smedia.ko using the
+ kld_list directive in
+ rc.conf to mimic the full functionality
+ of the userland implementation. If a custom kernel is used,
+ the full functionality of the userland library can be
+ compiled in, in the kernel, using the .
+
Port Redirection
- The drawback with &man.natd.8; is that the
- LAN clients are not accessible from the
- Internet. Clients on the LAN 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 LAN
+ The drawback with NAT in general is
+ that the LAN clients are not accessible
+ from the Internet. Clients on the LAN
+ 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 LAN
client machines. A simple way around this is to redirect
- selected Internet ports on the &man.natd.8; machine to a
- LAN client.
+ selected Internet ports on the NAT
+ providing machine to a LAN client.For example, an IRC server runs on
client A and a web server runs on
@@ -2329,49 +2422,51 @@
(IRC) and 80 (HTTP)
must be redirected to the respective machines.
- The syntax for is as
+ With in-kernel NAT all configuration
+ is done in the NAT instance
+ configuration. For a full list of options that an in-kernel
+ NAT instance can use, consult
+ &man.ipfw.8;. The IPFW syntax
+ follows the syntax of natd. The
+ syntax for is as
follows:
- -redirect_port proto targetIP:targetPORT[-targetPORT]
- [aliasIP:]aliasPORT[-aliasPORT]
- [remoteIP[:remotePORT[-remotePORT]]]
+ redirect_port proto targetIP:targetPORT[-targetPORT]
+ [aliasIP:]aliasPORT[-aliasPORT]
+ [remoteIP[:remotePORT[-remotePORT]]]
- In the above example, the argument should be:
+ To configure the above example setup, the arguments
+ should be:
- -redirect_port tcp 192.168.0.2:6667 6667
- -redirect_port tcp 192.168.0.3:80 80
+ redirect_port tcp 192.168.0.2:6667 6667
+redirect_port tcp 192.168.0.3:80 80
- This redirects the proper TCP ports
- to the LAN client machines.
+ After adding these arguments to the configuration of
+ NAT instance 1 in the above ruleset, the
+ TCP ports will be port forwarded to the
+ LAN client machines running the
+ IRC and HTTP
+ services.
+ ipfw -q nat 1 config if $pif same_ports unreg_only reset \
+ redirect_port tcp 192.168.0.2:6667 6667 \
+ redirect_port tcp 192.1683.0.3:80 80
+
Port ranges over individual ports can be indicated with
- . For example,
+ . For example,
tcp 192.168.0.2:2000-3000
- 2000-3000 would redirect all connections
+ 2000-3000 would redirect all connections
received on ports 2000 to 3000 to ports 2000 to 3000 on
client A.
-
- These options can be used when directly running
- &man.natd.8;, placed within the
- natd_flags="" option in
- /etc/rc.conf, or passed via a
- configuration file.
-
- For further configuration options, consult
- &man.natd.8;.Address Redirection
-
- address redirection
-
-
Address redirection is useful if more than one
IP address is available. Each
LAN client can be assigned its own
- external IP address by &man.natd.8;,
+ external IP address by &man.ipfw.8;,
which will then rewrite outgoing packets from the
LAN clients with the proper external
IP address and redirects all traffic
@@ -2383,7 +2478,7 @@
class="ipaddress">128.1.1.2, and 128.1.1.3 are available,
128.1.1.1 can be
- used as the &man.natd.8; machine's external
+ used as the &man.ipfw.8; machine's external
IP address, while 128.1.1.2 and 128.1.1.3 are forwarded
@@ -2391,48 +2486,90 @@
A and
B.
- The syntax is as
- follows:
+ The syntax is as
+ below, where localIP is the internal
+ IP address of the LAN
+ client, and publicIP the external
+ IP address corresponding to the
+ LAN client.
- -redirect_address localIP publicIP
+ redirect_address localIP publicIP
+ In the example, the arguments would read:
-
-
-
-
- localIP
- The internal IP address of
- the LAN client.
-
+ redirect_address 192.168.0.2 128.1.1.2
+redirect_address 192.168.0.3 128.1.1.3
-
- publicIP
- The external IP address
- corresponding to the LAN
- client.
-
-
-
-
-
- In the example, this argument would read:
-
- -redirect_address 192.168.0.2 128.1.1.2
--redirect_address 192.168.0.3 128.1.1.3
-
- Like , these arguments
- are placed within the natd_flags=""
- option of /etc/rc.conf, or passed via a
- configuration file. With address redirection, there is no
- need for port redirection since all data received on a
+ Like , these arguments
+ are placed in a NAT instance
+ configuration. With address redirection, there is no
+ need for port redirection, as all data received on a
particular IP address is
redirected.The external IP addresses on the
- &man.natd.8; machine must be active and aliased to the
+ &man.ipfw.8; machine must be active and aliased to the
external interface. Refer to &man.rc.conf.5; for
details.
+
+
+
+ Userspace NAT
+
+ Let us start with a statement: the userspace
+ NAT implementation: &man.natd.8;, has
+ more overhead than in-kernel NAT. 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
+ NAT.
+
+ To enable the userpace NAT daemon
+ &man.natd.8; at boot time, the following is a minimum
+ configuration in /etc/rc.conf. Where
+ is set to the name of the
+ NIC attached to the Internet. The
+ &man.rc.8; script of &man.natd.8; will automatically check
+ if a dynamic IP address is used and
+ configure itself to handle that.
+
+ gateway_enable="YES"
+natd_enable="YES"
+natd_interface="rl0"
+
+ In general, the above ruleset as explained for in-kernel
+ NAT can also be used together with
+ &man.natd.8;. The only exceptions are the configuration of
+ the in-kernel NAT instance (ipfw
+ -q nat 1 config ...) 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 action is used which covers
+ fragmentation.
+
+ $cmd 100 divert natd ip from any to any in via $pif
+$cmd 1000 divert natd ip from any to any out via $pif
+
+ To configure port or address redirection, a similar
+ syntax as with in-kernel NAT is used.
+ Although, now, instead of specifying the configuration in
+ our ruleset script like with in-kernel
+ NAT, configuration of &man.natd.8; is
+ best done in a configuration file. To do this, an extra
+ flag must be passed via /etc/rc.conf
+ which specifies the path of the configuration file.
+
+ natd_flags="-f /etc/natd.conf"
+
+
+ The specified file must contain a list of
+ configuration options, one per line. For more information
+ about the configuration file and possible variables,
+ consult &man.natd.8;. Below are two example
+ entries, one per line:
+
+ redirect_port tcp 192.168.0.2:6667 6667
+redirect_address 192.168.0.3 128.1.1.3