From owner-svn-doc-all@FreeBSD.ORG Wed Mar 5 20:28:47 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C0E9F8C; Wed, 5 Mar 2014 20:28:47 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36FA6A59; Wed, 5 Mar 2014 20:28:47 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s25KSkqx087489; Wed, 5 Mar 2014 20:28:46 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s25KSkES087488; Wed, 5 Mar 2014 20:28:46 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201403052028.s25KSkES087488@svn.freebsd.org> From: Dru Lavigne Date: Wed, 5 Mar 2014 20:28:46 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44139 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:28:47 -0000 Author: dru Date: Wed Mar 5 20:28:46 2014 New Revision: 44139 URL: http://svnweb.freebsd.org/changeset/doc/44139 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 Mar 5 20:11:16 2014 (r44138) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Mar 5 20:28:46 2014 (r44139) @@ -1735,13 +1735,13 @@ options IPDIVERT # enables NAT/etc/sysctl.conf: - net.inet.ip.fw.verbose_limit=5 + net.inet.ip.fw.verbose_limit=5 - After saving the needed edits, start the firewall. To - enable logging limits now, also set the - sysctl value specified above: + After saving the needed edits, start the firewall. To + enable logging limits now, also set the + sysctl value specified above: - &prompt.root; service ipfw start + &prompt.root; service ipfw start &prompt.root; sysctl net.inet.ip.fw.verbose_limit=5 @@ -1854,8 +1854,8 @@ options IPDIVERT # enables NATlimit rule. count: updates counters for - all packets that match the rule. The search continues with - the next rule. + all packets that match the rule. The search continues + with the next rule. deny | drop: either word silently discards packets that match this rule. @@ -2157,16 +2157,17 @@ pif="dc0" # interface name of NIC at 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 IP - address. + can connect to the Internet using a single + IP address. To do this, the &os; machine connected to the Internet must act as a gateway. This system must have two - NICs, where one is connected to the Internet - and the other is connected to the internal LAN. Each - machine connected to the LAN should be assigned - an IP address in the private network space, - as defined by NICs, where one is connected to the + Internet and the other is connected to the internal + LAN. Each machine connected to the + 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 @@ -2177,11 +2178,11 @@ pif="dc0" # interface name of NIC at 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 . + IPFIREWALL options described in . - To enable NAT support at - boot time, the following must be in - /etc/rc.conf: + To enable NAT support at boot time, the + following must be in /etc/rc.conf: gateway_enable="YES" # enables the gateway natd_enable="YES" # enables NAT @@ -2189,14 +2190,13 @@ natd_interface="rl0" # specify interfac 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;: + It is also possible to specify a configuration file + which contains the options to pass to &man.natd.8;: natd_flags="-f /etc/natd.conf" The specified file must contain a list of configuration - options, one per line. For - example: + options, one per line. For example: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 @@ -2207,21 +2207,19 @@ redirect_port tcp 192.168.0.3:80 80Next, 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 - skipto action requires a rule number - so that it knows - which rule to jump to. + positioning of the NAT rules is critical + and the skipto action is used. The + skipto action requires a rule number so + that it knows which rule to jump to. The following example 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 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 @@ -2264,13 +2262,13 @@ good_tcpo="22,25,37,53,80,443,110"The inbound rules remain the same, except for the very last rule which removes the via $pif in - order to catch both inbound and outbound rules. The + order to catch both inbound and outbound rules. The NAT rule must follow this last outbound 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 + 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. @@ -2281,43 +2279,47 @@ good_tcpo="22,25,37,53,80,443,110"In this example, rules 100, 101, 125, - 500, and 510 - 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. + 500, and 510 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. - Consider an internal web browser which initializes a new outbound HTTP - session over port 80. When the first outbound packet enters - the firewall, it does not match rule 100 because it is - headed out rather than in. It passes rule 101 because this - is the first packet and it has not been posted to the - dynamic state table yet. The packet finally matches - rule 125 as it is outbound on an allowed port - and has a source IP address from the 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 executed. - Next, the packet undergoes NAT and - is sent out to the Internet. This packet makes its way to + Consider an internal web browser which initializes a new + outbound HTTP session over port 80. When + the first outbound packet enters the firewall, it does not + match rule 100 because it is headed out + rather than in. It passes rule 101 because + this is the first packet and it has not been posted to the + dynamic state table yet. The packet finally matches rule + 125 as it is outbound on an allowed port + and has a source IP address from the + 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 + 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 generated and sent back. This new packet enters the top of - the ruleset. It matches rule 100 and has it destination IP - address mapped back to the original internal address. It - then is processed by the check-state - rule, is found in the table as an existing session, and is - released to the LAN. - - On the inbound side, the ruleset has - to deny bad packets and allow only authorized services. - A packet which matches an inbound rule - is posted - to the dynamic state table and the packet is released to the - LAN. The packet 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 + the ruleset. It matches rule 100 and has + it destination IP address mapped back to + the original internal address. It then is processed by the + check-state rule, is found in the table as + an existing session, and is released to the + LAN. + + On the inbound side, the ruleset has to deny bad packets + and allow only authorized services. A packet which matches an + inbound rule is posted to the dynamic state table and the + packet is released to the LAN. The packet + 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 NAT before being released to the outbound interface. + Port Redirection