tech-net archive

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

Re: NPF and PF



* Mike Pumford <mpumford%mudcovered.org.uk@localhost> wrote, on 2020-12-16 18:05:
>
>
> On 16/12/2020 17:02, Hector wrote:
> > On 12/16/20 12:27 AM, Gert Doering wrote:
> > > Hi,
> > >
> > > On Tue, Dec 15, 2020 at 10:40:46PM -0600, Hector wrote:
> > > > I would be glad to enumerate some of the shortcomings of NPF, in a
> > > > follow-up message, and why I consider it to be in some ways a regression
> > > > from PF, if anyone is interested.
> > >
> > > I certainly am, especially which of the more advanced features of PF you
> > > use.
> > >
> > > (Now I am not a NetBSD developer, just an interested user)
> > >
> > > gert
> > >
> >
> > One pf feature I use is anchors. You can read about those in pf.conf(5)
> > if you are not familiar with them. It is very useful to be able to make
> > on-the-fly adjustments to part of the ruleset without disturbing any
> > other parts.
> >
> > As far as I can tell, npf has nothing like that.
> >
> Based on that description npf has that and its called a ruleset. Inside my
> external group I have:
>     ruleset "blacklistd"
>
> I can then add and remove dynamic rules from that ruleset (or rather
> blacklistd does on my behalf) without impacting any other part of the rules
> by doing:
>   npfctl rule blacklistd add ...
>
> and
>   npfctl rule blacklistd remove ...
>
> Is that what you meant?
>
> > Trying to load a npf ruleset with tables of thousands of entries takes
> > _minutes_. In one case I had with tens of thousands of lpm table
> > entries, 'npf reload' chewed for almost 20 minutes (!!), and then
> > crashed, leaving the filter in an inoperable state.
> That sounds like a nasty bug. I wonder if its trying to bpfjit the whole lot
> and blowing up? Not using table support so its not something I would have
> run into.
>
> I admit I'm at the more complex end of the soho setup level with a /29 of
> IPv6 and a /64 of routed IPv6.
>
> Haven't run into performance or stability issues though on 8.x or 9.1 and
> like you I was wary of making the switch to it (from IPF in my case).
>
> Mike
>

npf 'ruleset' is not as useful as pf anchors. With pfctl, you can
load a complete set of rules from a file into an anchor.

It seems like in npf the only way to add rules to a ruleset is invoking
npfctl for each rule. Reminds me of iptables.

With pf, you can also individually, in any anchor:

* Flush the NAT rules.
* Flush the queue rules.
* Flush the filter rules.
* Flush the state table (NAT and filter).
* Flush the source tracking table.
* Flush the filter information (statistics that are not bound to rules).
* Flush the tables.

And, pfctl -k host | network :

    Kill all of the state entries originating from the specified host
    or network.

this is also very useful!

I wish npf had better, more comprehensive man pages. Telling the
reader to go to the npf web site to find adequate information is not
a good plan. And even the information on the npf web site is not as
comprehensive and helpful as the pf man pages.

I first tried to replace a fancy pf config with npf about 4 years
ago, with NetBSD 7. After much frustration in trying to learn how to
configure npf, from inadequate documentation, I finally realized npf was
not able to do all that I was doing with pf, so I went back to pf.

At that time, I did some performance tests of pf vs. npf, with
functionally similar rulesets. This was on a four-core amd64 machine.
My iperf measurements showed npf was twice as fast as pf at routing
between interfaces.



Home | Main Index | Thread Index | Old Index