Date: Wed, 18 Jan 2006 17:27:40 +0100 From: Erik Norgaard <norgaard@locolomo.org> To: Gable Barber <gablebarber@gmail.com> Cc: Peter <petermatulis@yahoo.ca>, freebsd-questions@freebsd.org Subject: Re: How to tell if IPF is running? Message-ID: <43CE6C7C.2040307@locolomo.org> In-Reply-To: <aab166ce0601180746j4a430495p7afaed5d4942d428@mail.gmail.com> References: <aab166ce0601180627s781f0bdk108a8eabbe36136c@mail.gmail.com> <20060118152806.46592.qmail@web60022.mail.yahoo.com> <aab166ce0601180746j4a430495p7afaed5d4942d428@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Gable Barber wrote: > On 1/18/06, Peter <petermatulis@yahoo.ca> wrote: >> >> Switch over to pf. >> > Why do you suggest PF over IPF? > > Hope I am not starting a war here.. but I am genuinely interested in the > opinions. I used IPF on FBSD until there was some bug in IPF for 5.x some version that forced me to switch after an upgrade. The bug has been fixed since but I have found no reason to go back. There are two things I miss from IPF: a) proper accounting: You can't count traffic correctly with stateful filtering on pf, pf will count when a rule is matched but once a state is established packets for that state are not matched and hence not counted. b) an active and inactive ruleset: To load a new ruleset you'll have to flush everything. You can check syntax of rules before loading and pf loads all or nothing, so if there is a syntax error in your ruleset it won't be loaded. BUT: You may make syntactically correct changes that yet contain errors: Just say you wrote: block in all from 10.0.0.0/2 but meant block in all from 10.0.0.0/24 In IPF I always used: # ipf -s && sleep 60 && ipf -s to give me 60 seconds to verify that I didn't lock myself out. Now, that is compensated by in PF you can flush and reload the rules only, keeping existing states, so the connection you use for maintenance is not torn down. The pros for PF are some features to prevent DDoS against servers behind your firewall, and advanced queuing features and CARP. The use of macros and tables makes it easier to maintain rules, but the lack of groups means you have to be more careful structuring your ruleset: Rules are read top down _always_ in IPF I really liked groups, even though I always kept rules together. It just made it more explicit that rules went the same place. PF uses some clever skip ahead to gain the speed that proper use of groups give in IPF, and tests have shown that pf is faster than IPF in particular when rulesets grow large. but you need to be careful writing rules: IPF sample: block in quick from 10.0.0.0/24 to any head 10 pass in quick from 10.0.0.0/24 to 192.168.0.0/24 group 10 PF sample: block in from 10.0.0.0/24 to any pass in quick from 10.0.0.0/24 to 192.168.0.0/24 block in quick from 10.0.0.0/24 to any The thing is that in the first line of the IPF sample, a default action is made for that group. packets matching the head rule but no rules in the group will take that action. In PF you'll have to include that extra rule in the end to get the same behavior. So, in short, ipf is really simple and comparatively easy to work with, the lack of macros means you generally have to write more but this also makes it more explicit what happens as packets traverse the ruleset. pf has some really nice features in particular in more complex setups. The use of macros means that you can create compact rulesets that can easily be adopted to other systems or setups. Use what you feel most comfortable with. Cheers, Erik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43CE6C7C.2040307>