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 @@ &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 public + implementations of NAT: the userland + implementation &man.natd.8;, and the more recent in-kernel + NAT implementation. 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 public IP address. To do this, the &os; machine connected to the Internet @@ -2176,7 +2174,7 @@ 1918. Some additional configuration is needed in order to enable - the in-kernel NAT function of + the in-kernel NAT facility of IPFW. To enable in-kernel NAT support at boot time, the following must be set in /etc/rc.conf: @@ -2186,9 +2184,9 @@ firewall_nat_enable="YES" - When firewall_enable is not set, - but firewall_nat_enable is, it will have - no effect and do nothing, because the in-kernel + When firewall_nat_enable is set but + firewall_enable is not, it will have no + effect and do nothing. This is because the in-kernel NAT implementation is only compatible with IPFW. @@ -2196,30 +2194,16 @@ 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. 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: + 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 + 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. - 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 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" @@ -2228,28 +2212,41 @@ 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; + With in-kernel NAT it is + necessary to disable TCP segmentation offloading + (TSO) due to the architecture of + &man.libalias.3;, a library implemented as a kernel module to + provide the in-kernel NAT facility of + IPFW. TSO 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 TSO system + wide, the following must be set it + /etc/sysctl.conf: + + net.inet.tcp.tso="0" + + A NAT instance will also be configured. + It is possible to have multiple NAT + instances each with their own configuration. 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 + can take a few options 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 + &man.ipfw.8;. When configuring 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. @@ -2272,21 +2269,21 @@ 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. + in-kernel NAT facility. The reassemble rule was not needed with userland &man.natd.8; because the internal workings of the IPFW divert - action already takes care of this automatically as also - stated in &man.ipfw.8;. + action already takes care of reassambling packets before + delivery to the socket 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 rc.firewall which is - a script to set up the baked-in default firewall rulesets - present in &os;. + The NAT instance and rule number used + in this example does not match with the default + NAT instance and rule number created by + rc.firewall. + rc.firewall is a script that sets up + the default firewall rules 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 @@ -2306,8 +2303,8 @@ Remember that IPFW's - firewall performance is largely determined by the number of - rules present in the ruleset. + 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 @@ -2375,17 +2372,18 @@ interface. - Transition from userland &man.natd.8; to in-kernel + Transitioning 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 + libalias.ko kernel module, when + firewall_nat_enable is enabled in + rc.conf. The + libalias.ko kernel module only provides + basic NAT functionality, whereas the + userland implementation &man.natd.8; has all + NAT 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 libalias.ko kernel module: @@ -2396,10 +2394,9 @@ 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, + rc.conf. If a custom kernel is used, the full functionality of the userland library can be - compiled in, in the kernel, using the . @@ -2450,7 +2447,7 @@ 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 + redirect_port tcp 192.168.0.3:80 80 Port ranges over individual ports can be indicated with . For example, @@ -2518,7 +2515,7 @@ Let us start with a statement: the userspace NAT implementation: &man.natd.8;, has - more overhead than in-kernel NAT. For + 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 @@ -2539,13 +2536,13 @@ 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. + &man.natd.8;. The exceptions are the configuration of the + in-kernel NAT instance (ipfw -q + nat 1 config ...) which is not needed together + with reassemble rule 99 because its functionality is + included in the action. Rule number + 100 and 1000 will have to change sligthly as shown + below. $cmd 100 divert natd ip from any to any in via $pif $cmd 1000 divert natd ip from any to any out via $pif @@ -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