From owner-freebsd-questions@FreeBSD.ORG Tue Jan 20 07:26:26 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECA0F16A4CE for ; Tue, 20 Jan 2004 07:26:26 -0800 (PST) Received: from smtp-out1.blueyonder.co.uk (smtp-out1.blueyonder.co.uk [195.188.213.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62EE243DB0 for ; Tue, 20 Jan 2004 07:25:06 -0800 (PST) (envelope-from xfb52@dial.pipex.com) Received: from dial.pipex.com ([82.41.37.129]) by smtp-out1.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.5600); Tue, 20 Jan 2004 15:25:06 +0000 Message-ID: <400D483D.7000302@dial.pipex.com> Date: Tue, 20 Jan 2004 15:24:45 +0000 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040105 X-Accept-Language: en, en-us MIME-Version: 1.0 To: fbsd_user@a1poweruser.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2004 15:25:06.0427 (UTC) FILETIME=[9533DCB0:01C3DF69] cc: freebsd-questions@freebsd.org Subject: Re: ipfw/nated stateful rules example X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 15:26:27 -0000 fbsd_user wrote: > The conclusion so far is that ipfw1 and ipfw2 using keep-state rules > on the interface facing the public internet with divert/nated does > not work period. Probably my post hasn't reached you yet. I think you are mistaken if you mean that keep-state rules cannot be securely used in a NAT configuration -- see two examples in my post. The mistake I believe you are making is in talking about only the public-internet facing interface. What you are trying to do is to ensure that *conversations* from anywhere on your internal network can be keep-stated when talking to the external network. But the packets *start* on the internal facing interface. It just so happens that without NAT you can ignore this bit of the conversation, but once you include it, you cannot. In any case, my somewhat messy example which puts the keep-state on a skipto rule still manages without *looking* at the internal interface, though it does take into consideration the whole conversation. > Still would like to be proved wrong on my conclusion. If you find any bugs in the two alternatives I posted then I would love to know. --Alex