From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 26 19:13:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9560737B401 for ; Sat, 26 Jul 2003 19:13:09 -0700 (PDT) Received: from pgh.nepinc.com (pgh.nepinc.com [66.207.129.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D6F743F3F for ; Sat, 26 Jul 2003 19:13:08 -0700 (PDT) (envelope-from durham@jcdurham.com) Received: from jimslaptop.home.jcdurham.com (18.gibs5.xdsl.nauticom.net [209.195.184.19]) by pgh.nepinc.com (8.11.4/8.11.3) with ESMTP id h6R2D6u83791; Sat, 26 Jul 2003 22:13:07 -0400 (EDT) (envelope-from durham@jcdurham.com) From: Jim Durham Organization: JC Durham Consulting To: Yar Tikhiy Date: Sat, 26 Jul 2003 22:12:59 -0400 User-Agent: KMail/1.5.2 References: <200307251349.38413.durham@jcdurham.com> <20030726022205.452c374f.sheepkiller@cultdeadsheep.org> <20030726071359.GA61353@comp.chem.msu.su> In-Reply-To: <20030726071359.GA61353@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307262212.59810.durham@jcdurham.com> cc: freebsd-hackers@freebsd.org Subject: Re: NATD and Address Redirection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: durham@jcdurham.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2003 02:13:09 -0000 On Saturday 26 July 2003 03:13 am, you wrote: > On Sat, Jul 26, 2003 at 02:22:05AM +0200, Clement Laforet wrote: > > for incoming traffic, you must use -redirect_address, but for > > outgoing you have to set -alias_address. > > If you want to use a specific public IP to map incoming AND > > outgoing packets, you need to run 2 natd, using ipfw matching. > > I'm afraid this is not exactly correct. > > IIRC when 5 years ago I was hacking natd and libalias to use them > for transparent HTTP proxying, their internals looked rather clear. > In a nutshell, they were as follows. > > There was a translation table inside libalias with 3 columns in it: > the internal connection point (IP&port), alias point, and external > point. > > When a packet was heading outside, its source IP&port were matched > against the "internal" column, and its destination IP&port against > the "external" column. If an entry were found, the packet's source > IP&port would be replaced with the values from the "alias" column. > > When a packet was going in the opposite direction, inside, its > source IP&port were matched against the "external" column, and its > destination IP&port against the "alias" column. Then the packet's > destination IP&port were replaced with the values from the > "internal" column of the entry found. > > By specifying a redirect_address rule, just an entry was inserted > to that table with a wildcard value for all the ports and for the > external IP address. Upon matching, such an entry would clone into > a new one containing the information specific for a particular > session. Thus the solution was symmetric by design, without > requiring 2 natd's or additional ipfw rules. > > P.S. As I can see, today's libalias still uses the same approach. That's a great explanation! Thanks. I knew that NAT worked by establishing a "session" when an inside machine initiated a connection to the outside world and used that info the figure out how packets going back to that inside machine from the outside address got routed. I didn't know the internals. So redirect_address apparently just forces a permanent entry in the table, which would be symmetrical. Hmmmm... OK. -- -Jim