From owner-freebsd-questions@FreeBSD.ORG Sun Dec 14 16:46:08 2003 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 C3B0216A4D2 for ; Sun, 14 Dec 2003 16:46:05 -0800 (PST) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8F1D43D32 for ; Sun, 14 Dec 2003 16:46:03 -0800 (PST) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 6FA1B3C2; Sun, 14 Dec 2003 18:46:03 -0600 (CST) Date: Sun, 14 Dec 2003 18:46:03 -0600 From: Tillman Hodgson To: freebsd-questions@freebsd.org Message-ID: <20031215004603.GT64340@seekingfire.com> References: <20031214233809.GS64340@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.5.1i Subject: Re: ipnat+ipfw + 3 gateways 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: Mon, 15 Dec 2003 00:46:08 -0000 On Sun, Dec 14, 2003 at 07:23:26PM -0500, fbsd_user wrote: > What do you think IPF is? That's the utility name used to load > filter rules into IPFILTER. > So you are doing just what I said. The original poster said > nothing about doing traffic shaping. > IPNAT will not function with out IPFILTER rules. At lease pass in > all on all interfaces. He listed none in his post. Unlike IPFW, IPF defaults to "open" (thus the reason for the IPFILTER_DEFAULT_BLOCK kernel option). Thus IPF won't be blocking any of the packets that IPNAT is NATing. For example, when I issue a `ipf -F a`, my IPNAT rules continue to function normally. -T -- The person who takes the banal and ordinary and illuminates it in a new way can terrify. We do not want our ideas changed. We feel threatened by such demands. "I already know the important things!" we say. Then Changer comes and throws our old ideas away. - The Zensufi Master