pf: Initial Ethernet level filtering code
ClosedPublic
Actions

Authored by kp on Aug 31 2021, 8:23 AM.

Details

Reviewers

None

Group Reviewers

network
pfsense

Commits

rGe732e742b37f: pf: Initial Ethernet level filtering code

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 41276
Build 38165: arc lint + arc unit

Event Timeline

kp created this revision.Aug 31 2021, 8:23 AM

Herald added subscribers: melifaro, farrokhi, ae, imp. · View Herald TranscriptAug 31 2021, 8:23 AM

kp requested review of this revision.Aug 31 2021, 8:23 AM

Harbormaster completed remote builds in B41276: Diff 94413.Aug 31 2021, 8:23 AM

kp added a child revision: D31738: pfctl: Print Ethernet rules.Aug 31 2021, 8:24 AM

Rebase

Harbormaster completed remote builds in B41831: Diff 95938.Sep 29 2021, 2:58 PM

Rebase & cleanup

Harbormaster completed remote builds in B42105: Diff 96812.Oct 13 2021, 3:30 PM

glebius added a subscriber: glebius.Dec 17 2021, 4:12 PM

glebius added inline comments.

sys/netpfil/pf/pf_ioctl.c
6069	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!

afedorov added a subscriber: afedorov.Dec 17 2021, 10:08 PM

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.