From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 18:53:10 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C92C416A4E0 for ; Sat, 15 Jul 2006 18:53:10 +0000 (UTC) (envelope-from christian@de.clara.net) Received: from spamvir02.de.clara.net (spamvir02.de.clara.net [212.82.240.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E71743D45 for ; Sat, 15 Jul 2006 18:53:09 +0000 (GMT) (envelope-from christian@de.clara.net) Received: from localhost ([127.0.0.1]) by spamvir02.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1pGG-00019n-Ia; Sat, 15 Jul 2006 20:53:08 +0200 Received: from [192.168.0.221] (helo=[62.24.31.231]) by spamvir02.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1pGG-00019j-Ba; Sat, 15 Jul 2006 20:53:08 +0200 Message-ID: <44B9398C.2080307@de.clara.net> Date: Sat, 15 Jul 2006 20:53:00 +0200 From: Christian Meutes User-Agent: Mozilla Thunderbird 1.0.8 (Windows/20060417) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Travis H." References: <44B8F827.5000602@de.clara.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: RDR for locally generated traffic X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 18:53:10 -0000 > > You cannot DNAT in outbound, nor can you SNAT on inbound. I have been > asking for the symmetric cases on the OpenBSD pf list, and it's on my > "to do one day" list, but I have no idea when that will become the top > priority (maybe never). > > As I understand it, this limitation has to do with the way the TCP/IP > stack works in BSD, particularly vis-a-vis routing. You will note we > don't have an equivalent to the PREROUTING chain, either. > Thanks for the answer! Then would it be possible to bind the IP to lo0 as an alias, connect to this IP and then let the rule rewrite the destination to a other one which lies on fxp0 directly?