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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, to answer some of the questions and concerns raised in the discussion here= =20 (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= =20 =A0 =A0code. It is encapsulated inside the pfil(9) api and could be maintai= ned=20 =A0 =A0as third-party code in the ports-tree. Still, it is my belief that t= he=20 =A0 =A0addition of pf to the base system has benefits: Possible to build it= in=20 =A0 =A0the kernel (which is somewhat comforting for a firewall), it will be= =20 =A0 =A0catched by tinderbox builds (i.e. track changes in the kernel api) a= nd=20 =A0 =A0so forth. It boils down to: It's just more convenient for both user = and=20 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=20 Luigi's msg on this thread before), but there will not be one unified=20 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=20 implementation which can be lifted, some in design and that it is the=20 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.=20 =A0 =A0It is ture that pf gains a lot from coupling with ALTQ and CARP roun= ds=20 =A0 =A0that up even more, still I like to take one step at a time and the=20 =A0 =A0current step is pf. If you are curious about ALTQ check out the altq= =20 =A0 =A0project 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 =A0 =A0what ipf does now. Q: What are the technical arguments for pf again? A: Activ development! State of the art feature list, steadily increasing.=20 =A0 =A0High performance stateful inspection, stateful (in-kernel) NAT/redir= ect=20 =A0 =A0and load-balancing, DoS prevention (synproxy, per-rule/-state limits= ),=20 =A0 =A0flexible "high-level" syntax, structured rulesets with anchors, dyna= mic=20 =A0 =A0address tables w/ O(1)-lookups, highly customizable logging with ful= l=20 =A0 =A0payload, mature IPv6 support and many many more ... =A0 =A0Futur version will bring failover, with keeping states and other=20 =A0 =A0enterprise level solutions. =2D-=20 Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402261930.01328.max>