Date: Tue, 7 Aug 2001 08:30:02 -0700 (PDT) From: mikescott@clara.net To: freebsd-bugs@FreeBSD.org Subject: Re: kern/29294: IPFW dynamic rules and NATD interaction has logical design flaw Message-ID: <200108071530.f77FU2U76051@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/29294; it has been noted by GNATS. From: mikescott@clara.net To: <freebsd-gnats-submit@FreeBSD.org>, <mikescott@clara.net>, "David Hedley" <david@inty.net> Cc: Subject: Re: kern/29294: IPFW dynamic rules and NATD interaction has logical design flaw Date: Tue, 7 Aug 2001 16:20:38 +0100 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. > > i.e. > > add 1 skipto 30000 ip from any to any out > # All packets at this point are now inbound > # Map incoming external IPs to internal > add 100 divert natd ip from any to any via tun0 > # Allow any packets that are part of an ongoing connection > add 200 check-state > add 300 deny log ip from any to any > > # Outgoing packets are processed here > # Add in dynamic rule using non-NAT addresses > add 30000 skipto 30100 ip from any to any via tun0 keep-state > # Do NAT > add 30100 divert natd ip from any to any via tun0 > add 30200 allow ip from any to any > > >From this, both keep-state and check-state will work on internal (i.e. > before-NAT) addresses. > > Hope this helps, > > David Ah, I see. Thanks for that. Amazing how you can't see the wood sometimes. 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. I *think* this is what happens with ipf, to which (in desperation :-) ) 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?) Anyway, as this would seem to be a "feature" rather than a "fault", may I suggest to anyone involved in the documentation that a working example might be useful in future please! Thanks again, anyway! -- various incoming sites blocked because of spam: see www.mikescott.clara.net for a list mikescott@clara.net Mike Scott aka mikeascott@ntlworld.com Harlow Essex England 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?200108071530.f77FU2U76051>