From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 26 00:14:10 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 6276637B401 for ; Sat, 26 Jul 2003 00:14:10 -0700 (PDT) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA52543FAF for ; Sat, 26 Jul 2003 00:14:08 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3p2/8.12.3) with ESMTP id h6Q7E0gb064053; Sat, 26 Jul 2003 11:14:00 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3p2/8.12.3/Submit) id h6Q7DxSi064052; Sat, 26 Jul 2003 11:13:59 +0400 (MSD) (envelope-from yar) Date: Sat, 26 Jul 2003 11:13:59 +0400 From: Yar Tikhiy To: Clement Laforet Message-ID: <20030726071359.GA61353@comp.chem.msu.su> References: <200307251349.38413.durham@jcdurham.com> <20030726022205.452c374f.sheepkiller@cultdeadsheep.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030726022205.452c374f.sheepkiller@cultdeadsheep.org> User-Agent: Mutt/1.5.3i cc: freebsd-hackers@freebsd.org cc: durham@jcdurham.com Subject: Re: NATD and Address Redirection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2003 07:14:10 -0000 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. -- Yar