Re: pf and rpi

[christos%astron.com@localhost (Christos Zoulas)]

In article <20141004041529.GB390%deimos.ergonaut.org@localhost>,
Malcolm Herbert  <mjch%mjch.net@localhost> wrote:
>-=-=-=-=-=-
>
>On Sat, Oct 04, 2014 at 02:47:52AM +0200, Rhialto wrote:
>|On Fri 03 Oct 2014 at 16:25:58 +0200, Zoran Kolic wrote:
>|> On freebsd I use ipfw, with rules that first one wins. On pf I know
>|> that the last one wins. Cannot be so sure reading npf howto. My bet
>|> is that the last wins too.
>|
>|I've never understood the reason for "last one wins". That seems like
>|unnecessary work, checking all those rules that may or may not be
>|winning in the end. And you can get the same effect with a "first one
>|wins" system (hence more efficiently) if you simply reverse the order
>|of the rules.
>
>this is why the 'quick' flag is there - it lets the filter engine stop
>processing further rules on matching the one with the flag
>
>I thought the argument went that if you set up rules that worked least
>specifically to most, then with quick flag you get the best of both
>worlds - you can elect to have the filter skip the remaining rules if
>you want to or just let the packet trickle out through them all ...
>
>putting the most specific rules at the top may result in bad performance
>if most of your traffic doesn't match that rule

Careful with "quick" (or "final" in npf lingo rules). For TCP you also
need to specify "keep state" (or "stateful" in npf lingo), otherwise
you'll get spurious connection drops.

christos