svn commit: r53486 - head/en_US.ISO8859-1/books/handbook/firewalls
Benedict Reuschling <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
Author: bcr Date: Fri Oct 11 19:21:19 2019 New Revision: 53486 URL: https://svnweb.freebsd.org/changeset/doc/53486 Log: Rewrite the NAT chapter to focus on in-kernel NAT, with a small section about natd at the end. Submitted by: [email protected] Approved by: bcr@ Differential Revision: https://reviews.freebsd.org/D21306 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 Fri Oct 11 12:35:28 2019 (r53485) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Oct 11 19:21:19 2019 (r53486) @@ -1698,7 +1698,7 @@ options ALTQ_PRIQ # Priority Queuing (PR <warning> <para>Only firewall rules with the <option>log</option> 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.</para> </warning> @@ -2121,9 +2121,9 @@ pif="dc0" # interface name of NIC attached to Inte $cmd 00999 deny log all from any to any</programlisting> </sect2> - <sect2 xml:id="network-natd"> + <sect2 xml:id="in-kernel-nat"> <info> - <title>Configuring <acronym>NAT</acronym></title> + <title>In-kernel <acronym>NAT</acronym></title> <authorgroup> <author> @@ -2134,19 +2134,34 @@ pif="dc0" # interface name of NIC attached to Inte <contrib>Contributed by </contrib> </author> </authorgroup> + + <authorgroup> + <author> + <personname> + <firstname>Dries</firstname> + <surname>Michiels</surname> + </personname> + <contrib>Rewritten and updated by </contrib> + </author> + </authorgroup> </info> + <indexterm> <primary>NAT</primary> <secondary>and <application>IPFW</application></secondary> </indexterm> - <para>&os;'s built-in <acronym>NAT</acronym> daemon, - &man.natd.8;, works in conjunction with + <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 + 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 @@ -2157,92 +2172,143 @@ pif="dc0" # interface name of NIC attached to Inte <acronym>LAN</acronym> should be assigned an <acronym>IP</acronym> address in the private network space, as defined by <link - xlink:href="https://www.ietf.org/rfc/rfc1918.txt">RFC - 1918</link>, and have the default gateway set to the - &man.natd.8; system's internal <acronym>IP</acronym> - address.</para> + xlink:href="https://www.ietf.org/rfc/rfc1918.txt">RFC + 1918</link>.</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> along with the other - <literal>IPFIREWALL</literal> options described in <xref - linkend="firewalls-ipfw-enable"/>.</para> + <para>Some additional configuration is needed in order to enable + the in-kernel <acronym>NAT</acronym> function 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> - <para>To enable <acronym>NAT</acronym> support at boot time, the - following must be in <filename>/etc/rc.conf</filename>:</para> + <programlisting>gateway_enable="YES" +firewall_enable="YES" +firewall_nat_enable="YES"</programlisting> - <programlisting>gateway_enable="YES" # enables the gateway -natd_enable="YES" # enables <acronym>NAT</acronym> -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;</programlisting> - <note> - <para>It is also possible to specify a configuration file - which contains the options to pass to &man.natd.8;:</para> + <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 + <acronym>NAT</acronym> implementation is only compatible + with <application>IPFW</application>.</para></note> - <programlisting>natd_flags="-f /etc/natd.conf"</programlisting> - - <para>The specified file must contain a list of configuration - options, one per line. For example:</para> - - <programlisting>redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80</programlisting> - - <para>For more information about this configuration file, - consult &man.natd.8;.</para> - </note> - - <para>Next, add the <acronym>NAT</acronym> rules to the firewall - ruleset. When the rulest contains stateful rules, the - positioning of the <acronym>NAT</acronym> rules is critical - and the <literal>skipto</literal> action is used. The + <para>When the ruleset contains stateful rules, the positioning + 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.</para> + 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> - <para>The following example builds upon the firewall ruleset + <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 <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> + 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" -skip="skipto 500" +skip="skipto 1000" pif=dc0 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; + <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 + 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 + <option>one_pass</option> behavior at the start of the + firewall script.</para> + + <programlisting>ipfw disable one_pass +ipfw -q nat 1 config if $pif same_ports unreg_only reset</programlisting> + <para>The inbound <acronym>NAT</acronym> rule is inserted <emphasis>after</emphasis> the two rules which allow all - traffic on the trusted internal interface and on the loopback - interface and <emphasis>before</emphasis> the + traffic on the trusted and loopback interfaces and after the + reassamble rule but <emphasis>before</emphasis> the <literal>check-state</literal> rule. It is important that the rule number selected for this <acronym>NAT</acronym> rule, in this example <literal>100</literal>, is higher than the first - two rules and lower than the <literal>check-state</literal> - rule:</para> + three rules and lower than the <literal>check-state</literal> + rule. Furthermore, because of the behavior of in-kernel + <acronym>NAT</acronym> it is advised to place a reassamble + rule just before the first <acronym>NAT</acronym> rule and + after the rules that allow traffic on trusted interface. + Normally, <acronym>IP</acronym> fragmentation should not + 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> + <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> + + <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> + <programlisting>$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-state</programlisting> <para>The outbound rules are modified to replace the <literal>allow</literal> action with the <literal>$skip</literal> variable, indicating that rule - processing will continue at rule <literal>500</literal>. The + processing will continue at rule <literal>1000</literal>. The seven <literal>tcp</literal> rules have been replaced by rule <literal>125</literal> as the <literal>$good_tcpo</literal> variable contains the seven allowed outbound ports.</para> + <note> + <para>Remember that <application>IPFW</application>'s + firewall performance is largely determined by the number of + rules present in the ruleset.</para></note> + <programlisting># 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 @@ good_tcpo="22,25,37,53,80,443,110"</programlisting> rule, must have a higher number than that last rule, and the rule number must be referenced by the <literal>skipto</literal> action. In this ruleset, rule - number <literal>500</literal> diverts all packets which match - the outbound rules to &man.natd.8; for - <acronym>NAT</acronym> processing. The next rule allows any - packet which has undergone <acronym>NAT</acronym> processing - to pass.</para> + number <literal>1000</literal> handles passing all packets to + our configured instance for <acronym>NAT</acronym> processing. + The next rule allows any packet which has undergone + <acronym>NAT</acronym> processing to pass.</para> - <programlisting>$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</programlisting> + <programlisting>$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 any</programlisting> <para>In this example, rules <literal>100</literal>, <literal>101</literal>, <literal>125</literal>, - <literal>500</literal>, and <literal>510</literal> control the - address translation of the outbound and inbound packets so + <literal>1000</literal>, and <literal>1001</literal> control + the address translation of the outbound and inbound packets so that the entries in the dynamic state table always register the private <acronym>LAN</acronym> <acronym>IP</acronym> address.</para> @@ -2286,7 +2351,7 @@ good_tcpo="22,25,37,53,80,443,110"</programlisting> internal <acronym>LAN</acronym>. On matching this rule, two actions take place. First, the <literal>keep-state</literal> action adds an entry to the dynamic state table and the - specified action, <literal>skipto rule 500</literal>, is + specified action, <literal>skipto rule 1000</literal>, is executed. Next, the packet undergoes <acronym>NAT</acronym> 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 @@ good_tcpo="22,25,37,53,80,443,110"</programlisting> generated as a response is recognized by the <literal>check-state</literal> rule as belonging to an existing session. It is then sent to rule - <literal>500</literal> to undergo + <literal>1000</literal> to undergo <acronym>NAT</acronym> before being released to the outbound interface.</para> + <note> + <para>Transition 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 + functionality refers to the following kernel modules that + can additionally be loaded when needed besides the standard + <filename>libalias.ko</filename> kernel module: + <filename>alias_cuseeme.ko</filename>, + <filename>alias_ftp.ko</filename>, + <filename>alias_bbt.ko</filename>, + <filename>skinny.ko</filename>, <filename>irc.ko</filename>, + <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, + the full functionality of the userland library can be + compiled in, in the kernel, using the <option>option + LIBALIAS</option>.</para></note> + <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> + <para>The drawback with <acronym>NAT</acronym> in general 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> + selected Internet ports on the <acronym>NAT</acronym> + providing 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 @@ -2329,49 +2422,51 @@ good_tcpo="22,25,37,53,80,443,110"</programlisting> (<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 + <para>With in-kernel <acronym>NAT</acronym> all configuration + is done in the <acronym>NAT</acronym> instance + configuration. For a full list of options that an in-kernel + <acronym>NAT</acronym> instance can use, consult + &man.ipfw.8;. The <application>IPFW</application> syntax + follows the syntax of <application>natd</application>. The + syntax for <option>redirect_port</option> is as follows:</para> - <programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT] - [aliasIP:]aliasPORT[-aliasPORT] - [remoteIP[:remotePORT[-remotePORT]]]</programlisting> + <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>To configure the above example setup, the arguments + should be:</para> - <programlisting> -redirect_port tcp 192.168.0.2:6667 6667 - -redirect_port tcp 192.168.0.3:80 80</programlisting> + <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>After adding these arguments to the configuration of + <acronym>NAT</acronym> instance 1 in the above ruleset, the + <acronym>TCP</acronym> ports will be port forwarded to the + <acronym>LAN</acronym> client machines running the + <acronym>IRC</acronym> and <acronym>HTTP</acronym> + services.</para> + <programlisting>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</programlisting> + <para>Port ranges over individual ports can be indicated with - <option>-redirect_port</option>. For example, + <option>redirect_port</option>. For example, <replaceable>tcp 192.168.0.2:2000-3000 - 2000-3000</replaceable> would redirect all connections + 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> <sect3> <title>Address Redirection</title> - <indexterm> - <primary>address redirection</primary> - </indexterm> - <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;, + external <acronym>IP</acronym> address by &man.ipfw.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 @@ -2383,7 +2478,7 @@ good_tcpo="22,25,37,53,80,443,110"</programlisting> 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 + used as the &man.ipfw.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 @@ -2391,48 +2486,90 @@ good_tcpo="22,25,37,53,80,443,110"</programlisting> <systemitem>A</systemitem> and <systemitem>B</systemitem>.</para> - <para>The <option>-redirect_address</option> syntax is as - follows:</para> + <para>The <option>redirect_address</option> syntax is as + below, where <literal>localIP</literal> is the internal + <acronym>IP</acronym> address of the <acronym>LAN</acronym> + client, and <literal>publicIP</literal> the external + <acronym>IP</acronym> address corresponding to the + <acronym>LAN</acronym> client.</para> - <programlisting>-redirect_address localIP publicIP</programlisting> + <programlisting>redirect_address localIP publicIP</programlisting> + <para>In the example, the arguments would read:</para> - <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> + <programlisting>redirect_address 192.168.0.2 128.1.1.2 +redirect_address 192.168.0.3 128.1.1.3</programlisting> - <row> - <entry>publicIP</entry> - <entry>The external <acronym>IP</acronym> address - corresponding to the <acronym>LAN</acronym> - client.</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <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 + <para>Like <option>redirect_port</option>, these arguments + are placed in a <acronym>NAT</acronym> instance + configuration. With address redirection, there is no + need for port redirection, as 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 + &man.ipfw.8; machine must be active and aliased to the external interface. Refer to &man.rc.conf.5; for details.</para> + </sect3> + + <sect3> + <title>Userspace <acronym>NAT</acronym></title> + + <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 + &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 + <acronym>NAT</acronym>.</para> + + <para>To enable the userpace <acronym>NAT</acronym> daemon + &man.natd.8; at boot time, the following is a minimum + configuration in <filename>/etc/rc.conf</filename>. Where + <option>natd_interface</option> is set to the name of the + <acronym>NIC</acronym> attached to the Internet. The + &man.rc.8; script of &man.natd.8; will automatically check + if a dynamic <acronym>IP</acronym> address is used and + configure itself to handle that.</para> + + <programlisting>gateway_enable="YES" +natd_enable="YES" +natd_interface="rl0"</programlisting> + + <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> + + <programlisting>$cmd 100 divert natd ip from any to any in via $pif +$cmd 1000 divert natd ip from any to any out via $pif</programlisting> + + <para>To configure port or address redirection, a similar + syntax as with in-kernel <acronym>NAT</acronym> is used. + Although, now, instead of specifying the configuration in + our ruleset script like with in-kernel + <acronym>NAT</acronym>, configuration of &man.natd.8; is + best done in a configuration file. To do this, an extra + flag must be passed via <filename>/etc/rc.conf</filename> + which specifies the path of the configuration file.</para> + + <programlisting>natd_flags="-f /etc/natd.conf"</programlisting> + + <note> + <para>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:</para> + + <programlisting>redirect_port tcp 192.168.0.2:6667 6667 +redirect_address 192.168.0.3 128.1.1.3</programlisting></note> </sect3> </sect2> _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-doc-all To unsubscribe, send any mail to "[email protected]"