Date: Thu, 16 Aug 2001 09:47:57 -0700 From: "Crist J. Clark" <cristjc@earthlink.net> To: mikescott@clara.net Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/29294: IPFW dynamic rules and NATD interaction has logical design flaw Message-ID: <20010816094757.B4232@blossom.cjclark.org> In-Reply-To: <200108071530.f77FU2U76051@freefall.freebsd.org>; from mikescott@clara.net on Tue, Aug 07, 2001 at 08:30:02AM -0700 References: <200108071530.f77FU2U76051@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 07, 2001 at 08:30:02AM -0700, mikescott@clara.net wrote:
> On 6 Aug 2001, at 16:14, David Hedley wrote:
> > For this to work, you need to split your firewall rules between incoming and
> > outgoing packets and divert them to natd at different times.
No, there is a much easier way.
$fwcmd add divert natd all from any to any via ${natd_interface}
$fwcmd add check-state
$fwcmd add pass ip from ${oip} to any out via ${oif} keep-state
$fwcmd add pass ip from ${net} to any in via ${iif} keep-state
Just create dynamic rules on packets going _in_ the internal
interface(s). We now get two dynamic rules for each "connection," one
using the translated source one using the private net address.
> However, even though there is a workable solution, I'd still contend
> the basic design is logically flawed -- it's the embedding of the nat
> diversion into the firewall rules that requires that the rules be so
> split: I'm no OS design expert, but I'm still prepared to stick my
> neck out and say the nat should occur immediately data is
> transferred to/from the device, in which case the firewall rules deal
> only with one set of addresses and are much simpler.
This would require NAT to take place in the kernel which is against
one of the fundamental design assumptions of natd(8). natd(8) works
the way it does for good reasons. However, it is not perfect, there
are both pros and cons to the design.
> I *think* this
> is what happens with ipf, to which (in desperation :-) )
Yes. ipf(8) and ipnat(8) live in the kernel. This design also has pros
and cons.
> I've already
> switched -- certainly the equivalent rules for ipf are much simpler
> and seem to work as expected. (As an aside, I wonder why fbsd
> offers two different firewalls? ipf seems to offer a superset of ipfw's
> facilities, claims to be portable, and if my experience is anything to
> go by, is easier to set up: why keep ipfw?)
ipfw(8) is the native firewall. ipf(8) is externally maintained.
I think the only real bug that might be here is that the default
rc.firewall does not actually work with natd(8) and that is not what
the original PR is about. Unless someone objects, I am going to close
this PR later today. If someone feels the need to, a PR about
rc.firewall can be submitted separately.
--
Crist J. Clark cjclark@alum.mit.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010816094757.B4232>