From owner-freebsd-questions Wed Jan 17 7: 0:25 2001 Delivered-To: freebsd-questions@freebsd.org Received: from ammi.mclink.it (ammi.mclink.it [195.110.128.1]) by hub.freebsd.org (Postfix) with ESMTP id E971D37B401 for ; Wed, 17 Jan 2001 07:00:06 -0800 (PST) Received: by ammi.mclink.it (8.9.0/8.9.0) id QAA02040; Wed, 17 Jan 2001 16:00:03 +0100 (CET) Date: Wed, 17 Jan 2001 16:00:03 +0100 (CET) From: Marco Masotti To: questions@freebsd.org Subject: Re: ipf/ipnatd vs ipfw/natd ? Message-Id: <1.0.2.200101171558.2943@mclink.it> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Easy-MAIL v1.02 - http://www.mclink.it/ Organization: MC-link the world online Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think that ipf/ipnat might be better, because of its kernel space implementation, and because derives from the OpenBSD realm of tools. As far as I've been concerned with ipf/ipnat and FreeBSD, when occasionally doing a nat gateway to an internal private network in a small organization, I've got the lesson not to use the ipnat feature when utilizing user PPP. Similarly to what recommended in the natd man page, also using ipf/ipnat with PPP is not well suited - Use nat enable feature built-in the user PPP implementation instead. Omitting to follow this indication will put you in a a riot of strange behaviours, like being forced to issue ipf -y to resync (and *by hand*, not from any script I've been able to make) kernel filters after PPP goes up. Such behaviours are still weird to me, and I wonder if anyone is able to give a basic explanation or rationale of what happening between ipf/ipnat and user PPP. Best regards -- Marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message