From nobody@FreeBSD.org  Mon Apr  3 12:51:41 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0B97C16A401
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  3 Apr 2006 12:51:41 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A697A43D46
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  3 Apr 2006 12:51:40 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k33CpeeN029905
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 3 Apr 2006 12:51:40 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k33CpemV029904;
	Mon, 3 Apr 2006 12:51:40 GMT
	(envelope-from nobody)
Message-Id: <200604031251.k33CpemV029904@www.freebsd.org>
Date: Mon, 3 Apr 2006 12:51:40 GMT
From: Joe <fbsd_user@a1poweruser.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Correction to handbook section 26.5.20 Port Redirection
X-Send-Pr-Version: www-2.3

>Number:         95262
>Category:       docs
>Synopsis:       Correction to handbook section 26.5.20 Port Redirection
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-doc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 03 13:00:34 GMT 2006
>Closed-Date:    Mon Jul 02 19:49:52 GMT 2007
>Last-Modified:  Mon Jul 02 19:49:52 GMT 2007
>Originator:     Joe
>Release:        6.0
>Organization:
none
>Environment:
>Description:
Content of section is totally incorrect.
>How-To-Repeat:

>Fix:
Replace section with this content.

An very common practice is to have a web server, email server, database
server or domain name server each segregated to a different PC on the LAN.
Any traffic originating from those servers destine for the public internet
would pass out the firewall on keep state rules automatically controlling
the bidirectional exchange of packets for the duration of the session
conversation. Due to the nature of these servers they also need to receive
unsolicited inbound traffic from the public internet. The problem is how to
direct this unsolicited inbound traffic to the correct target PC on the LAN?

For this purpose we use the NAT 'rdr' directive in the /etc/ipnat.rules
file to instruct where to redirect (or route) a particular packet to on
the NAT'ed LAN.

For example, lets say your web server resides on the LAN and you want it
to be accessible from the public internet. The NAT rules file would need
a additional rule added after the MAP rules to handle this. You would code
the rule like this:


        rdr xl0 0.0.0.0/0 port 80 -> 10.0.10.5 port 80



"rdr" = the command which provides the selection information and target
redirect information. 

"xl0" = is the network interface that is connected to the public internet.

"0.0.0.0/0" = is a special aliases which means any source IP address
contained in the inbound packet traveling the interface is to be selected
for testing. The other special aliases |0.32|, |0/0| and |0/32|, only work
in IPNAT's map and bimap rules. They do NOT work in IPF rules, or in IPNAT
rdr rules and 0.0.0.0/0 only works in rdr rules. Beware how and where you
use these special aliases as incorrect usage generates no errors. 

"port 80" = is the destination port number that has to be matched in the
inbound packet to select the candidate packet to be redirected. The number
"80" don't have to be used. You can use "port www" to specify a redirection
of port 80. If you would like to use a name instead of a number, the service
name and corresponding port, must exist in the file /etc/services.

"->" = Mandatory arrow symbol used to distinguish between the rule
selection information side and the redirect information side of the rule.
 
"10.0.10.5" = the IP address of the LAN PC which the matched packets are
to be targeted to. The netmask defaults to "/32" and therefore should not
be coded.

"port 80" - this is the port number value to substitute in the destination
port number of the redirected packet. You could make it 8088 and tell the
web server on 10.0.10.5 to listen on that port number. If omitted the
destination port number goes unchanged.

The above IPNAT redirect rule says that any inbound packet that has not
already had its destination IP address translated by earlier MAP rules
will then have its destination port tested for match to the port number
on the left of the mandatory arrow symbol, if  matched, the packet's
destination IP address and port number are over written with the values
on the right of the mandatory arrow symbol and then released for processing
against the firewall rules. NAT then posts an entry in its internal NAT
table so when the packet returns after first being processed by the
firewall rules on its outbound journey it can have its private LAN IP
address mapped back to your gateway's public routable IP address. After
reloading the NAT rules, the redirection will start immediately.

Depending on how tightly or loosely you control the services by firewall
rules the redirected packet may require a firewall rule to let it pass. 
Such as this for the above example:

pass in quick on xl0 proto tcp from any to 10.0.10.5 port = 80 flags S keep state

The main thing to remember is the firewall rules only sees the non-public
routable private LAN IP address. The NAT function happens after the outbound
packet has been processed by the firewall and before the inbound packet gets
to the firewall.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-doc->chinsan 
Responsible-Changed-By: chinsan 
Responsible-Changed-When: Wed Sep 27 06:58:58 UTC 2006 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=95262 
Responsible-Changed-From-To: chinsan->freebsd-doc 
Responsible-Changed-By: chinsan 
Responsible-Changed-When: Sun May 20 07:45:57 UTC 2007 
Responsible-Changed-Why:  
Sorry, I am busy on work handover with my team's job. 

So I haven't much time to deal with this.   
Return this pr to the pool. 
Sorry... :( 


http://www.freebsd.org/cgi/query-pr.cgi?pr=95262 
State-Changed-From-To: open->closed 
State-Changed-By: remko 
State-Changed-When: Mon Jul 2 19:49:51 UTC 2007 
State-Changed-Why:  
This does like something that should not be committed like this. The 
submitters mail bounces, if he reads this: please submit unified diffs 
next time so that the changes are more clear. Since i dont want to 
pretend that I will resolve this ; close the PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=95262 
>Unformatted:
