Date: Thu, 26 Feb 2004 19:30:01 +0100 From: Max Laier <max@love2party.net> To: cvs-all@freebsd.org Subject: PF import FAQ [Re: cvs commit: src/sys/contrib/pf/net if_pflog.c if_pflog.h if_pfsync.c if_pfsync.h pf.c pf_ioctl.c pf_norm.c pf_osfp.c pf_table.c pfvar.h src/sys/contrib/pf/netinetin4_cksum.c] Message-ID: <200402261930.01328.max@love2party.net> In-Reply-To: <20040226162751.GA25267@freebie.xs4all.nl> References: <200402260234.i1Q2YDx1014240@repoman.freebsd.org> <20040226161339.GI46714@madman.celabo.org> <20040226162751.GA25267@freebie.xs4all.nl>
index | next in thread | previous in thread | raw e-mail
Hi, to answer some of the questions and concerns raised in the discussion here (and in private mail to me): Q: Does that mean ipfw(6)/ipfilter will be removed? A: Not if I have to decide, which I have not ... luckyly. Q: Why for haven's sake do we include another firewall? A: Because we can! Fact is, that addition of pf does not mess any existing code. It is encapsulated inside the pfil(9) api and could be maintained as third-party code in the ports-tree. Still, it is my belief that the addition of pf to the base system has benefits: Possible to build it in the kernel (which is somewhat comforting for a firewall), it will be catched by tinderbox builds (i.e. track changes in the kernel api) and so forth. It boils down to: It's just more convenient for both user and developer! Q: Are there plans to unify the firewalls/create *the* firewall? A: No. It seems there are plans to glue ipfw with it's IPv6 part (see Luigi's msg on this thread before), but there will not be one unified kernel firewall thing doing all of ipfw/ipf/pf/... in near future. Keep in mind that every firewall has it's own (dis)advantages, some in implementation which can be lifted, some in design and that it is the differentses between them that make them especially useful for a certain job. Choice is the key here. Q: Will ALTQ and/or CARP come as well? A: Both is on my list, but not with a high priority or ready-made plans. It is ture that pf gains a lot from coupling with ALTQ and CARP rounds that up even more, still I like to take one step at a time and the current step is pf. If you are curious about ALTQ check out the altq project at rofug: http://www.rofug.ro/projects/freebsd-altq/ Q: Will there be a NO_PF knob? A: Definitely! The build infrastructure will not be too different from what ipf does now. Q: What are the technical arguments for pf again? A: Activ development! State of the art feature list, steadily increasing. High performance stateful inspection, stateful (in-kernel) NAT/redirect and load-balancing, DoS prevention (synproxy, per-rule/-state limits), flexible "high-level" syntax, structured rulesets with anchors, dynamic address tables w/ O(1)-lookups, highly customizable logging with full payload, mature IPv6 support and many many more ... Futur version will bring failover, with keeping states and other enterprise level solutions. -- Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnethelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402261930.01328.max>