Date: Wed, 18 Jan 2006 10:53:08 -0600 From: Gable Barber <gablebarber@gmail.com> To: Erik Norgaard <norgaard@locolomo.org> Cc: Peter <petermatulis@yahoo.ca>, freebsd-questions@freebsd.org Subject: Re: How to tell if IPF is running? Message-ID: <aab166ce0601180853t7bd21e97rd0280a8f27af0e84@mail.gmail.com> In-Reply-To: <43CE6C7C.2040307@locolomo.org> References: <aab166ce0601180627s781f0bdk108a8eabbe36136c@mail.gmail.com> <20060118152806.46592.qmail@web60022.mail.yahoo.com> <aab166ce0601180746j4a430495p7afaed5d4942d428@mail.gmail.com> <43CE6C7C.2040307@locolomo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/18/06, Erik Norgaard <norgaard@locolomo.org> wrote: > > 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 th= e > > 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 > Awesome information, and links. Thank you Everyone. Gable
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aab166ce0601180853t7bd21e97rd0280a8f27af0e84>