Date: Wed, 2 Jun 2004 21:43:01 -0700 From: Luigi Rizzo <rizzo@icir.org> To: JJB <Barbish3@adelphia.net> Cc: "Thomas S. Crum - 1WISP, Inc." <tscrum@1wisp.com> Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? Message-ID: <20040602214301.A55108@xorpc.icir.org> In-Reply-To: <MIEPLLIBMLEEABPDBIEGKEHBGAAA.Barbish3@adelphia.net>; from Barbish3@adelphia.net on Wed, Jun 02, 2004 at 11:16:29PM -0400 References: <00f901c44910$50cfb330$6466a8c0@wolf> <MIEPLLIBMLEEABPDBIEGKEHBGAAA.Barbish3@adelphia.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 02, 2004 at 11:16:29PM -0400, JJB wrote: ... > I know that Luigi Rizzo has rewritten ipfw into ipfw2, but he did > not address this problem of stateful rules and nated in his rewrite. there is not any problem except the fact that making the two things work together is a difficult thing and highly dependent on the specific features that you need. Given that this is (to me) a useless thing to do, i am not going to waste time and provide a solution every time someone challenges me with his own specific example. Of course you are free not to trust my words no matter who i am. But you seem to raise another issue, namely the lack of in-kernel NAT for ipfw. Yes, this is a missing feature. In-kernel NAT support for well-designed protocols (e.g. ssh, http etc.) is trivial and i have already done it a few times, for ipfw1 and ipfw2. But replicating all of libalias is an immensely boring task, which i have not much interest in doing, and given that there are alternatives packet filters, i suggest people to use them if they are not happy with the performance of natd or the complexity of writing a working configuration with belt and suspenders this is all i have to say on the topic luigi > > # Reject & Log all incoming connections from the outside > $cmd 00499 deny log all from any to any in via $pif > > # Everything else is denied by default > # deny and log all packets that fell through to see what they are > $cmd 00999 deny log all from any to any > ################ End of IPFW rules file > ############################### > > > > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org > [mailto:owner-freebsd-ipfw@freebsd.org]On Behalf Of Luigi Rizzo > Sent: Wednesday, June 02, 2004 6:42 PM > To: OpenMacNews > Cc: freebsd-ipfw > Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ > keep-state? > > On Wed, Jun 02, 2004 at 03:33:58PM -0700, OpenMacNews wrote: > > In continued digging for some guidance w.r.t. my earlier post, I > came across the following list comment ... > > > > > The real show stopper is ipfw with stateful rules using > the 'keep state' > > > option does not work when used with the divert/nated > legacy sub-routine. > > > What this means is ipfw with stateful rules can only be > used if > > > 'user ppp -nat' is how you connect to the public > internet. > > > > Is this in fact true? > > If using NATd, am I relegated to a _static_ ruleset, w/ no ability > to use stateful rules? > > just about every sentence above is false. > > nothing prevents you from using stateful ipfw rules with natd, > _but_ you must understand very well the packet's flow and how > addresses are transformed or you won't get what you want. > > personally i see almost always only disadvantages (basically, it is > much > easier to screw up your configuration) in using both because nat is > already stateful > > cheers > luigi > > Richard > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040602214301.A55108>