pf: Initial Ethernet level filtering code

[kp]

Summary

This is the kernel side of stateless Ethernel level filtering for pf.

The primary use case for this is to enable captive portal functionality
to allow/deny access by MAC address, rather than per IP address.

Sponsored by: Rubicon Communications, LLC ("Netgate")

[kp]

Rebase

[kp]

Rebase & cleanup

[glebius]

sys/netpfil/pf/pf_ioctl.c

6080

I'd suggest assert that pfil_link() succeeds.

[glebius]

When I did the pfil(9) rewrite in 2019, our goal was to connect a filtering hook to a single NIC. We now are able to achieve that with the following sequence:

sysctl net.inet.ip.fw.enable=0
sysctl net.inet.ip6.fw.enable=0
sysctl net.inet.link.fw.enable=0
pfilctl link -i ipfw:default-link ${netif}

However, a better API/UI would be for the packet filters (pf, ipfw, whatever) to allow to create rulesets with arbitrary names not attached to anything. Right now pf just mimics ipfw, whose behavior is historical, based on the fact that the network stack has 3 fixed filtering points.

I don't know if it is in interest of PfSense of Rubicon to invest time in that, just typing out my thoughts on the topic. Not requesting any changes to the revision!

[kp]

In D31737#757754, @glebius wrote:

I don't know if it is in interest of PfSense of Rubicon to invest time in that, just typing out my thoughts on the topic. Not requesting any changes to the revision!

For context, the intent behind adding L2 capabilities to pf is to simplify pfSense's captive portal setup. That currently uses IPFW so it can filter based on MAC addresses, and then leaves the rest of the filtering to pf. It's a bit silly to run two packet filters, so we'd like to get pf to do everything.

It might be possible to tweak pf to allow unhooked anchors, but that's a different project that I don't think we're interested in at the moment.

sys/netpfil/pf/pf_ioctl.c

6080

That gets done in D31742