NPF and PF

[Hector]

A couple of years ago this bold note was added at the top of pf(4) man page:

  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

 cvs diff -r 1.12 pf.4
 ...
 $NetBSD: pf.4,v 1.13 2018/08/01 13:30:13 maxv Exp $

I am slightly concerned about the view this note might imply.

I have noticed other mailing list posts over the last year regarding
removing various obsolete network code.

I am concerned that the appearance of this note claiming PF is obsolete
and everyone should use NPF instead might be an indicator that at some
point someone might decide PF should be removed from NetBSD.

In my opinion, NPF is currently not a suitable replacement for PF.

NPF has improved some since its introduction in NetBSD 6, but it still
has some severe shortcomings compared to PF.

I have been building NetBSD routers for about 15 years, the first one
being on NetBSD 3.0.

I have some fairly advanced PF rulesets, and PF has been working very
well for me for many years.

I hope that PF will continue to be in NetBSD, despite the fact that
someone might consider it "obsolete". (I presume this to mean, nobody
has been pulling improvements over from OpenBSD for a while now.)

I would be glad to see NPF improve enough to be a clear successor to
PF, but it is not at that point now.

I would like to hear thoughts from others who have used NPF and PF on
a router.

My use cases depend on PF.  NPF is incapable of doing some things which
I currently do with PF.  If there are any plans or thoughts to remove PF
from NetBSD, I would be greatly concerned. In fact, I would like to see
PF be maintained so it is not considered "obsolete". I might be able
to work on this, if I were given some guidance.

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.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

Post by Hector
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
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany ***@greenie.muc.de

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Hector
My use cases depend on PF.  NPF is incapable of doing some things which
I currently do with PF.  If there are any plans or thoughts to remove PF
from NetBSD, I would be greatly concerned. In fact, I would like to see
PF be maintained so it is not considered "obsolete". I might be able
to work on this, if I were given some guidance.

I think you are severely underestimating the amount of work updating PF
involves. Yes, there are known shortcomings in NPF, but changes are
extremely high that fixing them is at least an order of magnitude less
work. That's not even including the work of keeping it up-to-date.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hauke Fath]

Post by Joerg Sonnenberger

My use cases depend on PF. NPF is incapable of doing some things which
I currently do with PF. If there are any plans or thoughts to remove PF
from NetBSD, I would be greatly concerned. In fact, I would like to see
PF be maintained so it is not considered "obsolete". I might be able
to work on this, if I were given some guidance.

I think you are severely underestimating the amount of work updating PF
involves. Yes, there are known shortcomings in NPF, but changes are
extremely high that fixing them is at least an order of magnitude less
work. That's not even including the work of keeping it up-to-date.

FreeBSD has forked pf a while back, and made it smp capable. I have
converted three NetBSD 7 routers @work to FreeBSD three years ago, and
they have been performant and stable ever since. If you need the
feature set of pf, but cannot stomach its creators, that would be the
way to go.

IMHO, the NetBSD packet filter supports SOHO installations at best;
anything else is misleading.

Cheerio,
Hauke

[Joerg Sonnenberger]

Post by Hauke Fath

Post by Joerg Sonnenberger

My use cases depend on PF. NPF is incapable of doing some things which
I currently do with PF. If there are any plans or thoughts to remove PF
from NetBSD, I would be greatly concerned. In fact, I would like to see
PF be maintained so it is not considered "obsolete". I might be able
to work on this, if I were given some guidance.

I think you are severely underestimating the amount of work updating PF
involves. Yes, there are known shortcomings in NPF, but changes are
extremely high that fixing them is at least an order of magnitude less
work. That's not even including the work of keeping it up-to-date.

FreeBSD has forked pf a while back, and made it smp capable. I have
they have been performant and stable ever since. If you need the
feature set of pf, but cannot stomach its creators, that would be the
way to go.

...and have you looked at the amount of work that was? That's exactly my
point.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hauke Fath]

Post by Joerg Sonnenberger

Post by Hauke Fath
FreeBSD has forked pf a while back, and made it smp capable. I have
they have been performant and stable ever since. If you need the
feature set of pf, but cannot stomach its creators, that would be the
way to go.

...and have you looked at the amount of work that was? That's exactly my
point.

I haven't, no. But it's been done, and could have been ported.*

Cheerio,
Hauke


* Says he who probably doesn't know what he's talking about.

[Gert Doering]

Hi,

Post by Hauke Fath
I haven't, no. But it's been done, and could have been ported.*

How different is kernel level networking stuff between NetBSD and FreeBSD,
and NetBSD and OpenBSD, these days?

I dabbled in if_gre.c some 10 years ago (or more), and *then*, FreeBSD
and NetBSD were "quite close" (some differences in byte ordering of
addresses, though).

Genuinely curious,

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany ***@greenie.muc.de

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Gert Doering
How different is kernel level networking stuff between NetBSD and FreeBSD,
and NetBSD and OpenBSD, these days?

Not as different as for USB, but still quite a bit.

A few things I ran accross in wlan land: different memory allocations,
interesting mbuf differences, totally different privilege handling, a
few things that NetBSD should get like taskqueues and timer taskqueues,
differences in interface stats, sometimes recursive locking, different
module support, and probably a lot more minor things that I forgot.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kristof Provost]

Post by Martin Husemann

Post by Gert Doering
How different is kernel level networking stuff between NetBSD and FreeBSD,
and NetBSD and OpenBSD, these days?

Not as different as for USB, but still quite a bit.
A few things I ran accross in wlan land: different memory allocations,
interesting mbuf differences, totally different privilege handling, a
few things that NetBSD should get like taskqueues and timer
taskqueues,
differences in interface stats, sometimes recursive locking, different
module support, and probably a lot more minor things that I forgot.

And VIMAGE, and likely locking differences. If not now, then probably in
due course as I have hopes of using ck_epoch in pf.

I’m pretty sure that no matter how much work you think it is, it’s
more than that.

Best regards,
Kristof

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Gert Doering
Hi,

Post by Hector
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.

I also have some tables which have thousands of subnet entries (sourced
from the filesystem). pf handles these with no problems.

npfctl(8) says:
"Reloading the configuration is a relatively expensive operation."

Yes, it is, more expensive than you might guess.

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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

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.

Please file a bug report!

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Jason Thorpe

Post by Hector
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.

Please file a bug report!
-- thorpej

Which behavior should be called out as the bug? The crash, or the
fact that it takes minutes to load a ruleset with large tables?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paul Goyette]

One bug, two bad behaviours. Mention both behaviours. And if possible,
get a crash dump, put it somewhere semi-permanent, and provide a link to
the crash dump in the PR text.

Post by Hector

Post by Jason Thorpe

Post by Hector
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.

Please file a bug report!
-- thorpej

Which behavior should be called out as the bug? The crash, or the
fact that it takes minutes to load a ruleset with large tables?
!DSPAM:5fda5dfd47237347678438!

+--------------------+--------------------------+-----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | ***@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | ***@netbsd.org |
+--------------------+--------------------------+-----------------------+

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Hauke Fath
[...]
IMHO, the NetBSD packet filter supports SOHO installations at best;
anything else is misleading.

Even at home, I stay with ipf for multihomed routers.
npf just lacks the features I use (as I already explained several times).

[Robert Swindells]

Post by Manuel Bouyer

Post by Hauke Fath
[...]
IMHO, the NetBSD packet filter supports SOHO installations at best;
anything else is misleading.

Even at home, I stay with ipf for multihomed routers.
npf just lacks the features I use (as I already explained several times).

Prompted by today's thread I looked back at recent firewall discussions.

I don't see enough of a description of what you want to do to be able
to work on fixing your problem.

File it as a confidential PR if you want to keep your exact network
configuration private.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Robert Swindells

Post by Manuel Bouyer

Post by Hauke Fath
[...]
IMHO, the NetBSD packet filter supports SOHO installations at best;
anything else is misleading.

Even at home, I stay with ipf for multihomed routers.
npf just lacks the features I use (as I already explained several times).

Prompted by today's thread I looked back at recent firewall discussions.
I don't see enough of a description of what you want to do to be able
to work on fixing your problem.

My first mail on this topic was 26 Oct 2012 on tech-net@
I then did send a more complete example 21 Aug 2018, as a followup to a
mail from you on developers@ (you were in Cc).
I dind't get any follow up.

Here is what was in my 2018 mail (note that my example from 2012 was a
multihomed host, not a Xen dom0, but both use ruleset groups to
filter first on source, then on destination).
One thing I didn't mention in my previous emails is that, for the Xen
example, npf should accept to load rules with nonexistent interfaces
(the interfaces are created later).
Another thing not mentionned here is that in some corner cases I had
to use nested groups

Basically my ipf.conf looks like below. The kernel is configured with
BRIDGE_IPF on Xen dom0. This is a simple example. On real-life hosts
I have 51 vlans and more than 10 guests.
Note that I use interface names that are not present (or not always present)
in the system when the ipf.conf is first read. The Xen scripts patches it,
and do a /etc/rc.d/ipfilter reload

#the name below is patched with xvifXiY by Xen scripts
guest1i0=none1i0
guest1i1=none1i1

# block everything by default
block in log all

# 127.0.0.0/8 only on lo0
block in log level err quick from 127.0.0.0/8 to any head 10
pass in on lo0 from any to any group 10

block in log quick from any to 127.0.0.0/8 head 20
pass in quick on lo0 from any to any group 20

# check that a source IP comes in on the right interface
block in log quick from 10.0.0.0/24 to any head 100
pass in on vlan0 from any to any group 100
pass in on $guest1i0 from 10.0.0.10 to any group 100

block in log quick from 10.0.1.0/24 to any head 101
pass in on vlan1 from any to any group 101
pass in on $guest1i1 from 10.0.1.10 to any group 101

# there may be more checks on source, like public IP coming in only on
# the public interface

# now we're sure the source is on the correct interface. Check destination
# I have a single group below, but on real use cases, there will be one by
# host class/role
block in log quick from 10.0.0.1 to any head 1000
block in log quick from 10.0.1.1 to any head 1000
block in log quick from 10.0.0.10 to any head 1000
block in log quick from 10.0.1.10 to any head 1000
pass in log quick proto tcp from myworkstartion to any port = 22 flags S/SA group 1000
pass in log quick proto tcp from myworkstartion to any port = 443 flags S/SA group 1000
pass in log quick proto tcp from 10.0.0.0/16 to any port = 25 flags S/SA group 1000
block return-rst in log quick proto tcp from any to any group 1000
pass in quick proto icmp from any to any group 1000

[Robert Swindells]

Post by Manuel Bouyer

Post by Robert Swindells

Post by Manuel Bouyer

Post by Hauke Fath
[...]
IMHO, the NetBSD packet filter supports SOHO installations at best;
anything else is misleading.

Even at home, I stay with ipf for multihomed routers.
npf just lacks the features I use (as I already explained several times).

Prompted by today's thread I looked back at recent firewall discussions.
I don't see enough of a description of what you want to do to be able
to work on fixing your problem.

I then did send a more complete example 21 Aug 2018, as a followup to a
I dind't get any follow up.

By "what you want to do" I guess I'm really looking for an even higher
level description of where you want firewall operations to get done.

Are you trying to isolate Xen VMs from each other or just protect them
from the outside ?

You write that you have BRIDGE_IPF enabled, presumably you add some
interfaces to a bridge, knowing which ones would be a help in
understanding your configuration.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Robert Swindells

Post by Manuel Bouyer

Post by Robert Swindells

Post by Manuel Bouyer

Post by Hauke Fath
[...]
IMHO, the NetBSD packet filter supports SOHO installations at best;
anything else is misleading.

Even at home, I stay with ipf for multihomed routers.
npf just lacks the features I use (as I already explained several times).

Prompted by today's thread I looked back at recent firewall discussions.
I don't see enough of a description of what you want to do to be able
to work on fixing your problem.

I then did send a more complete example 21 Aug 2018, as a followup to a
I dind't get any follow up.

By "what you want to do" I guess I'm really looking for an even higher
level description of where you want firewall operations to get done.

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)

Post by Robert Swindells
Are you trying to isolate Xen VMs from each other or just protect them
from the outside ?

both. But I have similar configs on routers, this is not specific to Xen

Post by Robert Swindells
You write that you have BRIDGE_IPF enabled, presumably you add some
interfaces to a bridge, knowing which ones would be a help in
understanding your configuration.

the domU's interface (from the dom0 view) are bridged with real
interfaces (or vlan(4) in my case). But really, it doesn't matter.
On my routers I have a similar setup and no bridge involved.
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.

[Mouse]

Post by Manuel Bouyer
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,
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).

Post by Manuel Bouyer
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?
Why is it important to group them into rulesets? (I can certainly
imagine possible reasons; I'm wondering what your actual reasons are.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Mouse

Post by Manuel Bouyer
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.

Post by Mouse
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.

Post by Mouse

Post by Manuel Bouyer
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.

[Hector]

Post by Manuel Bouyer
One thing I didn't mention in my previous emails is that, for the Xen
example, npf should accept to load rules with nonexistent interfaces
(the interfaces are created later).

I have this same problem with npf and tun interfaces.

My tun interfaces are generally not created until a particular process
starts and creates them with an open() call on /dev/tunN.

npf was not happy with the non-existent interfaces being referenced
in the ruleset.

I was able to work around the problem by creating a 'ifconfig.tun0', etc,
in rc.conf, with only an 'up' action in it, which causes the interface
to be created (by /etc/rc.d/network).


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Hector

Post by Manuel Bouyer
One thing I didn't mention in my previous emails is that, for the Xen
example, npf should accept to load rules with nonexistent interfaces
(the interfaces are created later).

I have this same problem with npf and tun interfaces.
My tun interfaces are generally not created until a particular process
starts and creates them with an open() call on /dev/tunN.
npf was not happy with the non-existent interfaces being referenced
in the ruleset.
I was able to work around the problem by creating a 'ifconfig.tun0', etc,
in rc.conf, with only an 'up' action in it, which causes the interface
to be created (by /etc/rc.d/network).

With Xen dom0 there's no way to work around this. The interfaces are numbered
by domain id, and this can becore arbitrary high: if you destroy/create a vm
(just rebooting the vm is enough) you get a new domain id each time.
You don't know how high it will get after months of uptime.
On one system of mine, the domain id is at 270 ...

[Mike Pumford]

Post by Hector

Post by Gert Doering
Hi,

Post by Hector
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?

Post by Hector
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Hector

Post by Gert Doering
Hi,

Post by Hector
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
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
npfctl rule blacklistd add ...
and
npfctl rule blacklistd remove ...
Is that what you meant?

Post by Hector
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.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Hector
  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

Why is use of PF strongly discouraged?

Who decided use of PF should be discouraged?

Are there plans or thoughts to remove it from NetBSD?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Hector

Post by Hector
  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

Why is use of PF strongly discouraged?

Basically what the note says: the verison of PF in the NetBSD tree is
*ancient* and unmaintained.

Post by Hector
Are there plans or thoughts to remove it from NetBSD?

Yes - as soon as npf(7) is considered to be mature enough to cover the
relevant use cases, both ipf and pf will be removed.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Martin Husemann

Post by Hector

Post by Hector
  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

Why is use of PF strongly discouraged?

Basically what the note says: the verison of PF in the NetBSD tree is
*ancient* and unmaintained.

Post by Hector
Are there plans or thoughts to remove it from NetBSD?

Yes - as soon as npf(7) is considered to be mature enough to cover the
relevant use cases, both ipf and pf will be removed.
Martin

Should I be concerned about how is decided what is considered relevant
use cases?

Is it likely that some current PF users (like me) may have use cases
which the decision makers conclude are not relevant?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Hector
Should I be concerned about how is decided what is considered relevant
use cases?
Is it likely that some current PF users (like me) may have use cases
which the decision makers conclude are not relevant?

Public feedback (in threads like this) is what typicaly forms the consensus,
so probably not much to worry.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Swindells]

Post by Hector

Post by Martin Husemann

Post by Hector

Post by Hector
  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

Why is use of PF strongly discouraged?

Basically what the note says: the verison of PF in the NetBSD tree is
*ancient* and unmaintained.

Post by Hector
Are there plans or thoughts to remove it from NetBSD?

Yes - as soon as npf(7) is considered to be mature enough to cover the
relevant use cases, both ipf and pf will be removed.

Should I be concerned about how is decided what is considered relevant
use cases?
Is it likely that some current PF users (like me) may have use cases
which the decision makers conclude are not relevant?

Are you getting anywhere with writing up the problems you found with
npf(7) ?

Just providing your list of IP addresses to block could be a start.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Robert Swindells

Post by Hector

Post by Martin Husemann

Post by Hector

Post by Hector
  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

Why is use of PF strongly discouraged?

Basically what the note says: the verison of PF in the NetBSD tree is
*ancient* and unmaintained.

Post by Hector
Are there plans or thoughts to remove it from NetBSD?

Yes - as soon as npf(7) is considered to be mature enough to cover the
relevant use cases, both ipf and pf will be removed.

Should I be concerned about how is decided what is considered relevant
use cases?
Is it likely that some current PF users (like me) may have use cases
which the decision makers conclude are not relevant?

Are you getting anywhere with writing up the problems you found with
npf(7) ?
Just providing your list of IP addresses to block could be a start.

Thanks for your interest in this.

The machine on which I experienced the npf(7) problem has already been
put into production, using pf.

I have another identical machine available for experimentation, but
I need to first set up the same files and config in order to reproduce
the problem.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Robert Swindells

Post by Hector

Post by Martin Husemann

Post by Hector

Post by Hector
  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

Why is use of PF strongly discouraged?

Basically what the note says: the verison of PF in the NetBSD tree is
*ancient* and unmaintained.

Post by Hector
Are there plans or thoughts to remove it from NetBSD?

Yes - as soon as npf(7) is considered to be mature enough to cover the
relevant use cases, both ipf and pf will be removed.

Should I be concerned about how is decided what is considered relevant
use cases?
Is it likely that some current PF users (like me) may have use cases
which the decision makers conclude are not relevant?

Are you getting anywhere with writing up the problems you found with
npf(7) ?
Just providing your list of IP addresses to block could be a start.

Here you can download a minimal npf.conf which tries to load a table of
about 52,000 subnets.

http://lab.netdog.org/npf.conf
http://lab.netdog.org/ip-blacklist-52k.gz

On a 4-core machine with 4GB of memory, this command:

# npfctl reload

chewed in silence for about 7 minutes, and then produced this output:

npfctl: �8

With a larger table, the run time is longer, and the garbage output is
different, being longer. I'll guess because the random memory being
printed happens to have a longer sequence of non-null bytes before a zero
byte terminates the print.

I'll be interested to hear if this is helpful.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hector]

Post by Hector

Post by Robert Swindells

Post by Hector

Post by Martin Husemann

Post by Hector

Post by Hector
  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

Why is use of PF strongly discouraged?

Basically what the note says: the verison of PF in the NetBSD tree is
*ancient* and unmaintained.

Post by Hector
Are there plans or thoughts to remove it from NetBSD?

Yes - as soon as npf(7) is considered to be mature enough to cover the
relevant use cases, both ipf and pf will be removed.

Should I be concerned about how is decided what is considered relevant
use cases?
Is it likely that some current PF users (like me) may have use cases
which the decision makers conclude are not relevant?

Are you getting anywhere with writing up the problems you found with
npf(7) ?
Just providing your list of IP addresses to block could be a start.

Here you can download a minimal npf.conf which tries to load a table of
about 52,000 subnets.
http://lab.netdog.org/npf.conf
http://lab.netdog.org/ip-blacklist-52k.gz
# npfctl reload
npfctl: �8
With a larger table, the run time is longer, and the garbage output is
different, being longer. I'll guess because the random memory being
printed happens to have a longer sequence of non-null bytes before a zero
byte terminates the print.
I'll be interested to hear if this is helpful.

One time, with a larger list, I saw this, after running 'service npf start':

npfctl: ��t��F����8
npfctl: ioctl(IOC_NPF_SWITCH): File exists

-------

Also, if anyone has trouble connecting to the http server to fetch these
files, tell me. You might be blocked by a firewall rule which I can correct.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[nia]

Post by Hector
Why is use of PF strongly discouraged?

There are unfixed vulnerabilities in the version that is shipped
with NetBSD. If you choose to ignore the advice at the top of the
man page and enable it anyway, you're likely opening your system
up to more problems than it solves.

Post by Hector
Who decided use of PF should be discouraged?
Are there plans or thoughts to remove it from NetBSD?

It was decided by core@ that NetBSD should have one firewall
and not three.

My understanding is that ipf is in a better state than pf, with
more users and less problems. So it's likely pf will go first.

Nobody's stepped up to fix pf.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de