[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 ...
> 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).
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
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
Main Index |
Thread Index |