From owner-svn-doc-head@FreeBSD.ORG Wed Feb 26 23:44:34 2014 Return-Path: Delivered-To: svn-doc-head@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 5232DD74; Wed, 26 Feb 2014 23:44:34 +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 39D901A42; Wed, 26 Feb 2014 23:44:34 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1QNiYVP071932; Wed, 26 Feb 2014 23:44:34 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1QNiYqI071931; Wed, 26 Feb 2014 23:44:34 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402262344.s1QNiYqI071931@svn.freebsd.org> From: Dru Lavigne Date: Wed, 26 Feb 2014 23:44:34 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44083 - 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-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 23:44:34 -0000 Author: dru Date: Wed Feb 26 23:44:33 2014 New Revision: 44083 URL: http://svnweb.freebsd.org/changeset/doc/44083 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 Feb 26 23:14:36 2014 (r44082) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 23:44:33 2014 (r44083) @@ -1708,40 +1708,39 @@ options IPDIVERT # enables NAT If firewall_type is set to either - client or simple, - modify the default rules found in - /etc/rc.firewall to fit the - configuration of the system. + client or simple, + modify the default rules found in + /etc/rc.firewall to fit the + configuration of the system. - Note that the - filename type is used to load a custom ruleset. + Note that the filename type is used to + load a custom ruleset. An alternate way to load a custom ruleset is to set the firewall_script variable to the absolute - path of an executable script that includes - IPFW commands. The examples used in this - section assume that the firewall_script - is set to /etc/ipfw.rules: + path of an executable script that + includes IPFW commands. The + examples used in this section assume that the + firewall_script is set to + /etc/ipfw.rules: - firewall_script="/etc/ipfw.rules" + firewall_script="/etc/ipfw.rules" To enable logging, include this line: firewall_logging="YES" - There is no - /etc/rc.conf variable to set logging - limits. To limit the number of times a rule is logged - per connection attempt, specify the number using this line - in - /etc/sysctl.conf: + There is no /etc/rc.conf variable to + set logging limits. To limit the number of times a rule is + logged per connection attempt, specify the number using this + line in /etc/sysctl.conf: 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: - + &prompt.root; service ipfw start &prompt.root; sysctl net.inet.ip.fw.verbose_limit=5 @@ -1755,13 +1754,12 @@ options IPDIVERT # enables NATrule processing order - When a packet enters the IPFW firewall, - it is compared against the first rule in the ruleset and - progresses one rule at a time, moving from top to bottom in - sequence. When the - packet matches the selection parameters of a rule, the rule's - action is executed and the search of the ruleset - terminates for that packet. This is referred to as + When a packet enters the IPFW + firewall, it is compared against the first rule in the ruleset + and progresses one rule at a time, moving from top to bottom + in sequence. When the packet matches the selection parameters + of a rule, the rule's action is executed and the search of the + ruleset terminates for that packet. This is referred to as first match wins. If the packet does not match any of the rules, it gets caught by the mandatory IPFW default rule number 65535, @@ -1781,19 +1779,20 @@ options IPDIVERT # enables NATWhen creating an IPFW rule, keywords must be written in the following order. Some keywords are mandatory - while other keywords are optional. The words shown in uppercase - represent a variable and the words shown in lowercase must - precede the variable that follows it. The # symbol is used - to mark the start of a comment and may appear at the end of a - rule or on its own line. Blank lines are ignored. + while other keywords are optional. The words shown in + uppercase represent a variable and the words shown in + lowercase must precede the variable that follows it. The + # symbol is used to mark the start of a + comment and may appear at the end of a rule or on its own + line. Blank lines are ignored. CMD RULE_NUMBER set SET_NUMBER ACTION log - LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT + LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT OPTIONS This section provides an overview of these keywords and - their options. It is not an exhaustive list of every possible - option. Refer to &man.ipfw.8; for a complete description of + their options. It is not an exhaustive list of every possible + option. Refer to &man.ipfw.8; for a complete description of the rule syntax that can be used when creating IPFW rules. @@ -1812,9 +1811,10 @@ options IPDIVERT # enables NATEach rule is associated with a number in the range of 1 to 65534. The number is used to - indicate the order of rule processing. Multiple rules can have the same - number, in which case they are checked according to - the order in which they have been added. + indicate the order of rule processing. Multiple rules + can have the same number, in which case they are checked + according to the order in which they have been + added. @@ -1822,13 +1822,12 @@ options IPDIVERT # enables NATSET_NUMBER Each rule is associated with a set number in the - range of 0 to - 31. Sets can be individually - disabled or enabled, making it possible to quickly add - or delete a set of rules. If a SET_NUMBER is not - specified, the rule will be added to set 0. - - + range of 0 to 31. + Sets can be individually disabled or enabled, making it + possible to quickly add or delete a set of rules. If a + SET_NUMBER is not specified, the rule will be added to + set 0. + @@ -1840,14 +1839,15 @@ options IPDIVERT # enables NAT allow | accept | pass | - permit: these keywords are equivalent and allow packets - that match the rule. + permit: these keywords are equivalent and + allow packets that match the rule. - check-state: checks the packet against the dynamic state table. - If a match is found, execute the action associated with - the rule which generated this dynamic rule, otherwise - move to the next rule. A check-state - rule does not have selection criterion. If no + check-state: checks the + packet against the dynamic state table. If a match is + found, execute the action associated with the rule which + generated this dynamic rule, otherwise move to the next + rule. A check-state rule does not + have selection criterion. If no check-state rule is present in the ruleset, the dynamic rules table is checked at the first keep-state or @@ -1857,9 +1857,9 @@ options IPDIVERT # enables NAT - deny | drop: either word discards - packets that match this rule. - + deny | drop: either word + discards packets that match this rule. + Additional actions are available. Refer to &man.ipfw.8; for details. @@ -1873,15 +1873,14 @@ options IPDIVERT # enables NATSECURITY. Logging only occurs if the number of packets logged for that particular rule does - not exceed the optional specified LOG_AMOUNT. - If no LOG_AMOUNT is specified, the - limit is taken from the value - of net.inet.ip.fw.verbose_limit. A - value of zero removes the logging limit. - Once the limit is reached, logging can be re-enabled by - clearing the logging counter or the packet counter for - that rule, using ipfw reset - log. + not exceed the optional specified LOG_AMOUNT. If no + LOG_AMOUNT is specified, the limit is taken from the + value of + net.inet.ip.fw.verbose_limit. A + value of zero removes the logging limit. Once the limit + is reached, logging can be re-enabled by clearing the + logging counter or the packet counter for that rule, + using ipfw reset log. Logging is done after all other packet matching @@ -1898,25 +1897,25 @@ options IPDIVERT # enables NATThis optional value can be used to specify any protocol name or number found in /etc/protocols. - - + + SRC - The from - keyword must be followed by the source address or a - keyword that represents the source address. An address - can be represented by the any, - me (any address configured on an - interface on this system), + The from keyword must be followed + by the source address or a keyword that represents the + source address. An address can be represented by the + any, me (any + address configured on an interface on this system), me6, (any IPv6 address configured on an interface on this system), or table followed by the number of a lookup table which contains a list of addresses. When specifying an IP address, it can be optionally followed by its CIDR mask - or subnet mask. For example, 1.2.3.4/25 or + or subnet mask. For example, + 1.2.3.4/25 or 1.2.3.4:255.255.255.128. @@ -1934,10 +1933,10 @@ options IPDIVERT # enables NATDST The to keyword must be followed - by the destination address or a - keyword that represents the destination address. The - same keywords and addresses described in the SRC section - can be used to describe the destination. + by the destination address or a keyword that represents + the destination address. The same keywords and + addresses described in the SRC section can be used to + describe the destination. @@ -1956,28 +1955,29 @@ options IPDIVERT # enables NATSeveral keywords can follow the source and destination. As the name suggests, OPTIONS are optional. Commonly used options include - in or - out, which specify the direction of - packet flow, icmptypes followed by - the type of ICMP message, and + in or out, which + specify the direction of packet flow, + icmptypes followed by the type of + ICMP message, and keep-state. - When a keep-state rule is matched, the - firewall will create a dynamic rule which - matches bidirectional traffic between the - source and destination addresses and ports using the same + When a keep-state rule is + matched, the firewall will create a dynamic rule which + matches bidirectional traffic between the source and + destination addresses and ports using the same protocol. The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this type of attack with IPFW, use - limit. This option limits the - number of simultaneous sessions by checking the open dynamic rules, counting - the number of times this rule and IP address - combination occurred. If this count is greater than the - value specified by limit, the packet - is discarded. + limit. This option limits the number + of simultaneous sessions by checking the open dynamic + rules, counting the number of times this rule and + IP address combination occurred. If + this count is greater than the value specified by + limit, the packet is + discarded. Dozens of OPTIONS are available. Refer to &man.ipfw.8; for a description of each available @@ -1988,38 +1988,38 @@ options IPDIVERT # enables NAT - Example Ruleset + Example Ruleset - This section demonstrates how to create an example - stateful firewall ruleset script named - /etc/ipfw.rules. In this example, all - connection rules use in or - out to clarify the direction. They also - use via - interface-name to specify - the interface the packet is traveling over. - - - When first creating or testing a firewall ruleset, - consider temporarily setting this tunable: - - net.inet.ip.fw.default_to_accept="1" - - This sets the default policy of &man.ipfw.8; to - be more permissive than the default deny ip from - any to any, making it slightly more difficult - to get locked out of the system right after a reboot. + This section demonstrates how to create an example + stateful firewall ruleset script named + /etc/ipfw.rules. In this example, all + connection rules use in or + out to clarify the direction. They also + use via + interface-name to specify + the interface the packet is traveling over. + + + When first creating or testing a firewall ruleset, + consider temporarily setting this tunable: + + net.inet.ip.fw.default_to_accept="1" + + This sets the default policy of &man.ipfw.8; to be more + permissive than the default deny ip from any to + any, making it slightly more difficult to get + locked out of the system right after a reboot. - The firewall script begins by indicating that it is a - Bourne shell script and flushes any existing rules. It then - creates the cmd variable so that - ipfw add does not have to be typed at the - beginning of every rule. It also defines the - pif variable which represents the name of - the interface that is attached to the Internet. + The firewall script begins by indicating that it is a + Bourne shell script and flushes any existing rules. It then + creates the cmd variable so that + ipfw add does not have to be typed at the + beginning of every rule. It also defines the + pif variable which represents the name of + the interface that is attached to the Internet. - #!/bin/sh + #!/bin/sh # Flush out the list before we begin. ipfw -q -f flush @@ -2027,24 +2027,24 @@ ipfw -q -f flush cmd="ipfw -q add" pif="dc0" # interface name of NIC attached to Internet - The first two rules allow all traffic on the trusted - internal interface and on the loopback interface: + The first two rules allow all traffic on the trusted + internal interface and on the loopback interface: - # Change xl0 to LAN NIC interface name + # Change xl0 to LAN NIC interface name $cmd 00005 allow all from any to any via xl0 # No restrictions on Loopback Interface $cmd 00010 allow all from any to any via lo0 - The next rule allows the packet through if it matches - an existing entry in the dynamic rules table: + The next rule allows the packet through if it matches an + existing entry in the dynamic rules table: - $cmd 00015 check-state + $cmd 00015 check-state - The next set of rules defines which stateful connections - internal systems can create to hosts on the Internet: + The next set of rules defines which stateful connections + internal systems can create to hosts on the Internet: - # Allow access to public DNS + # Allow access to public DNS # Replace x.x.x.x with the IP address of a public DNS server # and repeat for each DNS server in /etc/resolv.conf $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state @@ -2076,14 +2076,14 @@ pif="dc0" # interface name of NIC at # deny and log all other outbound connections $cmd 00299 deny log all from any to any out via $pif - The next set of rules controls connections from - Internet hosts to the internal network. It starts by - denying packets typically associated with attacks and then - explicitly allows specific types of connections. All the - authorized services that originate from the Internet use - limit to prevent flooding. + The next set of rules controls connections from Internet + hosts to the internal network. It starts by denying packets + typically associated with attacks and then explicitly allows + specific types of connections. All the authorized services + that originate from the Internet use limit + to prevent flooding. - # Deny all inbound traffic from non-routable reserved address spaces + # Deny all inbound traffic from non-routable reserved address spaces $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP @@ -2125,50 +2125,49 @@ pif="dc0" # interface name of NIC at # Reject and log all other incoming connections $cmd 00499 deny log all from any to any in via $pif - The last rule logs all packets that do not match any of - the rules in the - ruleset: + The last rule logs all packets that do not match any of + the rules in the ruleset: - # Everything else is denied and logged + # Everything else is denied and logged $cmd 00999 deny log all from any to any - + - - + + Configuring <acronym>NAT</acronym> - - - Chern - Lee - - Contributed by - - - - - NAT + + + Chern + Lee + + Contributed by + + + + + NAT - and IPFW - + and IPFW + - &os;'s built-in - NAT daemon, &man.natd.8;, works 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 - IP address. + &os;'s built-in NAT daemon, + &man.natd.8;, works 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 IP + address. - To do this, the &os; machine connected to the Internet + To do this, the &os; machine connected to the Internet must act as a gateway. This gateway machine must have two NICs: one connects to the Internet router and the other connects to a LAN. All the machines on the LAN are connected through a hub or switch. - Each machine and interface behind the + Each machine and interface behind the LAN should be assigned IP addresses in the private network space, as defined by IP address. - 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 with the other - IPFIREWALL options. - - To enable firewall and NAT support at - boot time, the following must be in - /etc/rc.conf: + 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 with the other + IPFIREWALL options. + + To enable firewall and NAT support at + boot time, the following must be in + /etc/rc.conf: - gateway_enable="YES" # enables the gateway function + gateway_enable="YES" # enables the gateway function natd_enable="YES" # enables the NAT function natd_interface="rl0" # specify interface name of NIC attached to Internet natd_flags="-dynamic -m" # -m = preserve port numbers if possible @@ -2213,87 +2212,87 @@ redirect_port tcp 192.168.0.3:80 80 - Utilizing stateful rules with a divert - natd rule complicates the ruleset logic. The - positioning of the check-state, and - divert natd rules in the ruleset is - critical and a new action type is used, called - skipto. When using - skipto, it is mandatory that each rule is - numbered, so that the skipto rule knows - which rule to jump to. - - The following is an uncommented example of a ruleset - which explains the sequence of the packet flow. - - The processing flow starts with the first rule from the - top of the ruleset and progresses one rule at a time until - the end is reached or the packet matches and the packet is - released out of the firewall. Take note of the location of - rule numbers 100 101, 450, 500, and 510. These rules - control the translation of the outbound and inbound packets - so that their entries in the dynamic keep-state table always - register the private LAN IP address. All the allow and deny - rules specify the direction of the packet and the interface. - All start outbound session requests will - skipto rule 500 to undergo NAT. - - Consider a web browser which initializes a new 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 keep-state table yet. The packet finally matches - rule 125 as it is outbound through the NIC facing the - Internet and has a source IP address as a private LAN IP - address. On matching this rule, two actions take place. - keep-state adds this rule to the dynamic - keep-state rules table and the specified action is executed - and posted as part of the info in the dynamic table. In - this case, the action is skipto rule 500. - Rule 500 NATs the packet IP address and - sends it 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 corresponding LAN IP 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. It goes to the LAN system that sent it - and a new packet is sent requesting another segment of the - data from the remote server. This time it matches the - check-state rule, its outbound entry is - found, and the associated action, - skipto 500, is executed. The packet - jumps to rule 500, gets NATed, and is - released to the Internet. - - On the inbound side, everything coming in that is part - of an existing session is automatically handled by the - check-state rule and the properly placed - divert natd rules. The ruleset only has - to deny bad packets and allow only authorized services. - Consider a web server running on the firewall where web - requests from the Internet should have access to the local - web site. An inbound start request packet will match rule - 100 and its IP address will be mapped to the LAN IP address - of the firewall. The packet is then matched against all the - nasty things that need to be checked and finally matches - rule 425 where two actions occur. The packet rule is posted - to the dynamic keep-state table but this time, any new - session requests originating from that source IP address are - limited to 2. This defends against DoS attacks against the - service running on the specified port number. The action is - allow, so the packet is released to the - LAN. The packet generated as a response is recognized by the - check-state as belonging to an existing - session. It is then sent to rule 500 for - NATing and released to the outbound - interface. + Utilizing stateful rules with a divert + natd rule complicates the ruleset logic. The + positioning of the check-state, and + divert natd rules in the ruleset is + critical and a new action type is used, called + skipto. When using + skipto, it is mandatory that each rule is + numbered, so that the skipto rule knows + which rule to jump to. + + The following is an uncommented example of a ruleset + which explains the sequence of the packet flow. + + The processing flow starts with the first rule from the + top of the ruleset and progresses one rule at a time until + the end is reached or the packet matches and the packet is + released out of the firewall. Take note of the location of + rule numbers 100 101, 450, 500, and 510. These rules + control the translation of the outbound and inbound packets + so that their entries in the dynamic keep-state table always + register the private LAN IP address. All the allow and deny + rules specify the direction of the packet and the interface. + All start outbound session requests will + skipto rule 500 to undergo NAT. + + Consider a web browser which initializes a new 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 keep-state table yet. The packet finally matches + rule 125 as it is outbound through the NIC facing the + Internet and has a source IP address as a private LAN IP + address. On matching this rule, two actions take place. + keep-state adds this rule to the dynamic + keep-state rules table and the specified action is executed + and posted as part of the info in the dynamic table. In + this case, the action is skipto rule 500. + Rule 500 NATs the packet IP address and + sends it 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 corresponding LAN IP 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. It goes to the LAN system that sent it + and a new packet is sent requesting another segment of the + data from the remote server. This time it matches the + check-state rule, its outbound entry is + found, and the associated action, + skipto 500, is executed. The packet + jumps to rule 500, gets NATed, and is + released to the Internet. + + On the inbound side, everything coming in that is part of + an existing session is automatically handled by the + check-state rule and the properly placed + divert natd rules. The ruleset only has + to deny bad packets and allow only authorized services. + Consider a web server running on the firewall where web + requests from the Internet should have access to the local + web site. An inbound start request packet will match rule + 100 and its IP address will be mapped to the LAN IP address + of the firewall. The packet is then matched against all the + nasty things that need to be checked and finally matches + rule 425 where two actions occur. The packet rule is posted + to the dynamic keep-state table but this time, any new + session requests originating from that source IP address are + limited to 2. This defends against DoS attacks against the + service running on the specified port number. The action is + allow, so the packet is released to the + LAN. The packet generated as a response is recognized by the + check-state as belonging to an existing + session. It is then sent to rule 500 for + NATing and released to the outbound + interface. - Example Ruleset #1: + Example Ruleset #1: - #!/bin/sh + #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 @@ -2340,13 +2339,13 @@ ipfw -q -f flush ######################## end of rules ################## - The next example is functionally equivalent, but uses - descriptive comments to help the inexperienced IPFW rule - writer to better understand what the rules are doing. + The next example is functionally equivalent, but uses + descriptive comments to help the inexperienced IPFW rule + writer to better understand what the rules are doing. - Example Ruleset #2: + Example Ruleset #2: - #!/bin/sh + #!/bin/sh ################ Start of IPFW rules file ############################### # Flush out the list before we begin. ipfw -q -f flush @@ -2499,130 +2498,132 @@ pif="rl0" # public interface name of $cmd 999 deny log all from any to any ################ End of IPFW rules file ############################### - - Port Redirection + + 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 client machines. - A simple way around this is to redirect selected Internet - ports on the &man.natd.8; machine to a LAN - client. - - For example, an IRC server runs on - client A and a web server runs on - client B. For this to work properly, - connections received on ports 6667 (IRC) - and 80 (HTTP) must be redirected to the - respective machines. + 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 + client machines. A simple way around this is to redirect + selected Internet ports on the &man.natd.8; machine to a + LAN client. + + For example, an IRC server runs on + client A and a web server runs on + client B. For this to work + properly, connections received on ports 6667 + (IRC) and 80 (HTTP) + must be redirected to the respective machines. - The syntax for is as - follows: + The syntax for is as + follows: - -redirect_port proto targetIP:targetPORT[-targetPORT] + -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] - In the above example, the argument should be: + In the above example, the argument should be: - -redirect_port tcp 192.168.0.2:6667 6667 + -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. + This redirects the proper TCP ports + to the LAN client machines. - Port ranges over individual ports can be indicated with - . For example, - tcp 192.168.0.2:2000-3000 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; - + Port ranges over individual ports can be indicated with + . For example, + tcp 192.168.0.2:2000-3000 + 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. - - Address Redirection + 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;, - which will then rewrite outgoing packets from the - LAN clients with the proper external - IP address and redirects all traffic - incoming on that particular IP address - back to the specific LAN client. This is - also known as static NAT. For example, - if IP addresses 128.1.1.1, 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 - IP address, while 128.1.1.2 and 128.1.1.3 are forwarded back - to LAN clients A - and B. - - The syntax is as - follows: - - -redirect_address localIP publicIP - - - - - - - localIP - The internal IP address of - the LAN client. - - - - publicIP - The external IP address - corresponding to the LAN - client. - - - - + + address redirection + - In the example, this argument would read: + 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;, + which will then rewrite outgoing packets from the + LAN clients with the proper external + IP address and redirects all traffic + incoming on that particular IP address + back to the specific LAN client. This is + also known as static NAT. For example, + if IP addresses 128.1.1.1, 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 + IP address, while 128.1.1.2 and 128.1.1.3 are forwarded + back to LAN clients + A and + B. + + The syntax is as + follows: + + -redirect_address localIP publicIP + + + + + + + localIP + The internal IP address of + the LAN client. + + + + publicIP + The external IP address + corresponding to the LAN + client. + + + + - -redirect_address 192.168.0.2 128.1.1.2 + 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 - particular IP address is redirected. - - The external IP addresses on the - &man.natd.8; machine must be active and aliased to the - external interface. Refer to &man.rc.conf.5; for - details. - - + 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 + particular IP address is + redirected. + + The external IP addresses on the + &man.natd.8; machine must be active and aliased to the + external interface. Refer to &man.rc.conf.5; for + details. + + The <application>IPFW</application> Command