From owner-freebsd-net@FreeBSD.ORG  Sun Feb 27 11:29:47 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 07BC4106564A
	for <net@freebsd.org>; Sun, 27 Feb 2011 11:29:47 +0000 (UTC)
	(envelope-from egrosbein@rdtc.ru)
Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221])
	by mx1.freebsd.org (Postfix) with ESMTP id 672728FC0A
	for <net@freebsd.org>; Sun, 27 Feb 2011 11:29:45 +0000 (UTC)
Received: from eg.sd.rdtc.ru (localhost [127.0.0.1])
	by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p1RBTiQI016694
	for <net@freebsd.org>; Sun, 27 Feb 2011 17:29:44 +0600 (NOVT)
	(envelope-from egrosbein@rdtc.ru)
Message-ID: <4D6A35A3.7060303@rdtc.ru>
Date: Sun, 27 Feb 2011 17:29:39 +0600
From: Eugene Grosbein <egrosbein@rdtc.ru>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU;
	rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7
MIME-Version: 1.0
To: "net@freebsd.org" <net@freebsd.org>
References: <4D6A30B7.2010001@rdtc.ru>
In-Reply-To: <4D6A30B7.2010001@rdtc.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: ipfw nat and dual-homed box
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Feb 2011 11:29:47 -0000

On 27.02.2011 17:08, Eugene Grosbein wrote:

[skip]

> For performance reasons, I need to create similar setup using in-kernel "ipfw nat"
> what does not have such "multiple instances" feature but has its own "keep-state" mechanics:

To correct myself: of course, ipfw nat has multiple instances... It does not offer
something like natd's "globalport" feature to check all NAT instances for entry
before creation of new one.

> nat config if $if0 unreg_only
> nat config if $if1 unreg_only
> nat 123 ip from any to any via $if0 keep-state # For incoming packets create dynamic rule.
> nat 124 ip from any to any via $if1 keep-state # For outgoing packet use corresponding NAT instance.
> fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface.
> fwd $if1_gate ip from $if1_ip to any out xmit $if0
> 
> This works just fine if we do not try to use ipfw nat's port forwarding.
> Here it breaks because "keep-state" creates dynamic rule for incoming connections
> before translation's done, so it records external IP of the box as destination IP.
> Hence, replies will be translated using wrong NAT instance when routing table
> chooses wrong outgoing interface - replies won't match ipfw's dynamic rules.
> 
> I think this is a bug in 8.2-STABLE. Am I right?
> Or, perhaps, there is another way to setup ipfw nat for dual-homed LAN?