[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NPF on 8.1 and pcap-filter expressions
On 08/22/19 17:44, Michael van Elst wrote:
But it would allow the npfctl reload strategy after changing things.
Though the reload strategy opens a small time frame where installed
filter rules do not match the interface configuration.
On Thu, Aug 22, 2019 at 04:02:43PM +0200, Frank Kardel wrote:
I found that in the mean time - thanks for looking.
That leaves me probably with no generic way in npf to detect/determine
NPF does not seem to have PF's :network/:broadcast/:peer mechanism and all
can access is the IP layer information.
This looks a bit clumsy.
Ideally I would like a generic way to determine networks, broadcast
addresses and maybe peers statically and dynamically
npfctl already reads IP information from interfaces, also reading the
netmask wouldn't be much of a problem. It wouldn't be magic though,
Yes. But we currently have the situation the NPF does not seem to have
any means right now to handle netmasks and broadcasts related to
interface addresses. As NPF works at the IP level I think supporting
netmask/broadcast/network should be part of NPF even if we start out
with the static solution in npfctl and supporting a dynamic one later.
rules aren't necessarily bound to an interface, so pcap-filter() would
need an explicit netmask argument, which makes it obvious that the
filter might not work correctly if applied to an interface with a
And what mechanisms does NPF provide to access the broadcast address
except for manually coding it - did I overlook something?
(I am currently looking in 8.1 as that is productional an try to convert
our pf router configuration to NPF with very limited success right
In many situations it might be easier to just match the list of broadcast
addresses without pcap-filter.
now - more on that in another thread).
for my case where the IP address/network is configured via DHCP and I'd
rather like to avoid dhcpcd's hooks to rewrite/reload the
Also partial interface names like tun for tun0...tun<n> could be helpful
especially as these interfaces can come and go.
That's more a question on how much code should be pushed into the
kernel. I'd rather trigger userland to reload the config.
Leaving small time windows of inconsistent configurations.
I think it depends more on the mechanisms/primitives we can think of for
efficient dynamic access to interface properties.
Yes, interface descriptions are the right/better thing here. But how do
we handle groups for an interface description when these interfaces
appear and disappear? Should be compile these groups anyway? How do we
handle groups for interface names and interface descriptions - looks
like we might have two different groups for one interface - which rule
do we run? This needs more thought or just a decision to use either
interface names or interface descriptions.
Using partial interface names doesn't sound like a security feature to
me. Matching the new interface descriptions instead is probably safer
but then descriptions must also be supported by the program that manages
Main Index |
Thread Index |