Re: Layer-2 filtering in NPF: breaking config parsing

> On 8 Jul 2025, at 12:56 PM, Greg Troxel <[email protected]> wrote:
> 
> netbsd-current built yesterday, updated from release sets.
> amd64, xen domU (on a n10 dom0).
> 
> system was working fine before the npf changes (well, occasional zfs
> lockups, but we know why and that's not related..)
> 
>  #> npfctl validate
>  table <blocklist> type lpm
> 
>  procedure "log"
> 
>  /etc/npf.conf:171:0: npfctl_print_filter: layer not supported near ''
> 
> 171 is the closing brace of a big "group default" (maybe 30 rules).
> 
> I have a line
> 
>  map $ext_if dynamic $vpn_prefix -> ifaddrs($ext_if)

thanks for this. Can easily get it fixed. seen it.


But can you also set a simple default config without layer2 rules and let me know if your network breaks?

a pass all default rule and see if it blocks like what Markus reported.


> 
> with earlier (different prefix)
> 
>  $ext_if = "xennet0"
>  $ext_ifaddrs = ifaddrs($ext_if)
> 
>  $vpn_if = "tun0"
>  $vpn_prefix = 10.1.2.0/24
> 
> and later
> 
>  group "external" on $ext_if {
>    pass stateful out final proto tcp from $vpn_prefix
>    pass stateful out final proto udp from $vpn_prefix
>    pass stateful out final proto icmp from $vpn_prefix
>  }
> 
> 
> and while this machine doesn't have a tun0, that was ok.
> 
> 
> If I coment out the map line (only the map line) "npfctl validate"
> returns my config ok.
> 
> 
> One can argue about whether map on an inerface that doesn't exist should
> be an error or not, but that would be
> 
>  /etc/npf.conf:37:0: map statement with interface that does not exist
> 
> and not be confusing.  There's a longer discussion about general configs
> that can be shared vs having to write a config generator and I'm
> avoiding that.  The point, besides confused error messages, is that this
> should not change with the introduction of a feature; it should only
> change if we decide to change it.

Emmanuel