How to tell if IPF is running?
norgaard at locolomo.org
Wed Jan 18 08:26:47 PST 2006
Gable Barber wrote:
> On 1/18/06, Peter <petermatulis at 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
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
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:
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
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
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.
More information about the freebsd-questions