How to tell if IPF is running?

[Erik Norgaard]

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
> 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