Date: Wed, 13 Jul 2011 05:50:23 -0400 From: Michael Powell <nightrecon@hotmail.com> To: freebsd-questions@freebsd.org Subject: Re: IPFW Firewall NAT inbound port-redirect Message-ID: <ivjpn8$8k1$1@dough.gmane.org> References: <CAHu1Y70Uq1AkMF--rB8sAw2M1NW8a0x1H9voTPsy3cm5vQ6O2Q@mail.gmail.com> <20110711170729.GG6611@dan.emsphone.com> <1310473165.58370.YahooMailRC@web36501.mail.mud.yahoo.com> <CAHu1Y725TGa8D=TQCKa7VQYDVAFLoABdFOZ%2BJwnMOBck0gWzyA@mail.gmail.com> <20110712160304.GI6611@dan.emsphone.com> <CAHu1Y73-M7Ds=zNUDDJboh7_eEPT-uiL6qULBghFJK__NiFKzQ@mail.gmail.com> <1310537140.18043.YahooMailRC@web36506.mail.mud.yahoo.com> <CAHu1Y7113W_-Z0ttbaVu7waM177pVWbwB7Mi_wAJOZwoVhSJvg@mail.gmail.com> <ivjf6v$c4u$1@dough.gmane.org> <CAHu1Y7035wyi6WuOMtTFYMh6BoDBNff8KuhBXGV8pUqjUT6h0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
OK - I'm confused. Could be all the top posting. ;-) testbed# man ipfw Formatting page, please wait...Done. IPFW(8) FreeBSD System Manager's Manual IPFW(8) NAME ipfw -- User interface for firewall, traffic shaper, packet scheduler, in-kernel NAT. ^^^^^^^^^^^^ [...] kernel config options: options IPFIREWALL_NAT #ipfw kernel nat support ^^^^^^^^ With this option you do not need userland natd and NAT stays in the kernel and keywords are in the IPFW ruleset. I did indeed mis-speak wrt to natd as the above was conceived in IPFW2 to supersede userland natd. Been about maybe 7 or 8 years since I used IPFW, so the memory is rusty. Michael Sierchio wrote: > Mike - > > You're confused. natd is still a userland process that works via > divert sockets. ipfirewall nat is an extension to ipfirewall (ipfw is > the userland control program to modify the rulesets, nat config, > tables, etc.). > > - Michael > > On Tue, Jul 12, 2011 at 11:51 PM, Michael Powell <nightrecon@hotmail.com> > wrote: >> Michael Sierchio wrote: >> >>> I'm familiar with natd since its appearance. I was unclear on the >>> ipfirewall nat syntax, since there is no syntax definition in the man >>> page. It's true the man page is already too large, but some examples >>> (somewhere) would be nice. Marshaling packets into userland and back >>> into the kernel makes natd much slower than kernel nat. >> >> This is no longer true as some while ago IPFW's NATD switched over to >> being kernel-based. A long time ago when NATD was still userland I >> switched to Darren Reed's IPFILTER for just this reason. >> >> The first thing this entailed was learning the IPFILTER syntax as it was >> somewhat different from IPFW. I made the adjustment and later I found >> when I moved to PF the syntax from IPFILTER was closer to PF which made >> it easier to migrate. >> >>> The statement "follow closely the syntax used in natd" is not >>> particularly reassuring, since it doesn't declare that the syntax is >>> identical, and (I am repeating myself, sorry), there is no syntax def >>> in the man page. >>> >> [snip] >>>> >>>> NATD and IPFW work together. It's a little hard to explain in this >>>> format so as Dan suggests, you should read the manpage on each. Also, >>>> do some google searches and you will find many helpful articles. But >>>> take my word for this, you can do exactly what you want with IPFW+NATD. >>>> There are those who will probably promote PF as the firewall of choice >>>> as well. It all depends on what you become familiar with. >> >> All trueness here. I have used all three: IPFW, IPFILTER, and PF. I use >> PF today, but any of the three will work just fine for essentially the >> same purpose (mostly). For example, IPFW had dummynet for traffic-shaping >> while PF uses ALTQ for essentially the same purpose. >> >> Mostly it is just grokking the syntax for whichever of the three you >> choose. The Handbook contains some content examples for getting started >> for IPFW and the PF docs can be found on the OpenBSD web site. Understand >> the syntax and you can shape the firewall however you choose. The various >> ruleset examples should probably not just be dropped in cut-and-paste >> style, but rather dissected line by line for understanding and then make >> tweaks which conform to exactly your local requirements. And it _is_ some >> arcane stuff to be sure, but stare at it long enough and it'll make sense >> eventually. :-) >> >> -Mike >> >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "freebsd-questions-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ivjpn8$8k1$1>