Page MenuHomeFreeBSD

pf: Initial Ethernet level filtering code
ClosedPublic

Authored by kp on Aug 31 2021, 8:23 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 14 2024, 7:42 AM
Unknown Object (File)
Jan 4 2024, 11:55 PM
Unknown Object (File)
Jan 4 2024, 11:55 PM
Unknown Object (File)
Jan 4 2024, 11:55 PM
Unknown Object (File)
Jan 4 2024, 11:55 PM
Unknown Object (File)
Jan 4 2024, 11:55 PM
Unknown Object (File)
Jan 4 2024, 11:04 PM
Unknown Object (File)
Dec 30 2023, 8:36 PM

Details

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")

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 42105
Build 38993: arc lint + arc unit

Event Timeline

kp requested review of this revision.Aug 31 2021, 8:23 AM
glebius added inline comments.
sys/netpfil/pf/pf_ioctl.c
6068

I'd suggest assert that pfil_link() succeeds.

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!

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
6068

That gets done in D31742

This revision was not accepted when it landed; it landed in state Needs Review.Mar 2 2022, 4:01 PM
This revision was automatically updated to reflect the committed changes.