How to tell if IPF is running?

[Gable Barber]

On 1/18/06, Erik Norgaard <norgaard at locolomo.org> wrote:
>
> 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
>


Awesome information, and links.

Thank you Everyone.

Gable