Re: Proposed Improvements to NPF

[Christoph Badura <bad%bsd.de@localhost>]

I haven't had time to reply in June.

On Sat, Jun 07, 2025 at 08:52:56PM +0000, Josh Moyer wrote:
> There was some confusion around my careless use of the word "group".  For
> groups, as per npf.conf(5), yes I do mean supporting this syntax of Greg's:
> 
>     group "my-name" in on { wm0, wm1, vlan3 } {
>         # List of rules, for packets received on wm0
>     }

Maybe it's time to think about separating rulesets from groups?

Something like:

    ruleset "rs-name" {
	# list of rules
    }

Then you could do something like

    group "rs-name" in on ....

or
    group "my-name" in on ... ruleset rs-name

With a view to call other rulesets from groups or rulesets:

    group "my-name" in on $ext_if {
	pass final ruleset rs-name1;
	block ruleset rs-name2;
	...
    }

Not sure what the actual syntax would/should look like.  I have the
iptables/nftables JUMP/GOTO actions in mind.

> My use case also involves the dynamic tun(4) interfaces, which aren't always
> present at startup (think OpenVPN), so will try to accommodate that somehow
> too.

This would be welcome.  E.g. the ppp interface on my Linux router comes and
goes as the PPPoE connection sometimes terminates and gets restarted.

nftables distinguishes matching on a specific interface ([io]if "name", which
translates to the if_index of the interface) and matching on the name
([io]ifname "foo*", which translates to actual pattern matching on the
if_xname).
> 
> As for "DNS lookups", I was thinking of using gethostbyname(3), Olaf, so I'm
> sure that nsswitch.conf would be honored.

At the end of the thread I'm still unclear whether you mean translating the
names at the time npfctl processes the configuration file before loading
the rules into the kernel or if you mean lookups from inside the kernel.

My preference is to use NPF tables that get initialized or are regularly
updated.

--chris