tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NPF and PF

On Thu, Dec 17, 2020 at 11:23:39AM -0500, Mouse wrote:
> > first filter input packets based on source address
> > (default: block all).
> > Then, if not blocked above, filter based on destination address
> > (default: block all too)
> How important is it that the filters be applied in this order?  I'm
> having trouble imagining any difference, other than performance,

it would work, as long as there's no 'pass quick' decision based on
source address before it has been validated (the first group is anti-spoofing
rules in my case). Note that the second block makes decisions on
more than destination address. What I have is basically a group per
destination, and inside each group most of the rules allows packets
based on sources adress/destination port.

Validaing the source address first is much less error-prone.

> between the above and the same thing with the filters in the other
> order, or even filtering on <src,dst> pairs (though of course this last
> leads to a combinatorial issue if both lists are non-tiny).

I'm not even sure you can do things like "allow source address foo
only from interface bar" without groups.
> > The problem is really to have a packet go through several rulesets,
> > where a ruleset could decide to block the packet, or let it pass to
> > the next one.
> How does this differ - or, rather, what difference is relevant - from
> a setup where you simply have a list of rules which are tried in order?

Because I don't know how to do in a simple way "allow source address foo
only from interface bar" without groups.

Maybe I could write a scipt which generates flat rules using all possible
combiantion of groups, but the resulting rulesets would be huge.

As an example, on a currently running system, I have 1634 rules, of which
244 are head rules.

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index