pfSense

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/778

No, that won't work on ethernet rules. The 'dnpipe (1, 2)' syntax tell pf to apply pipe 1 on forward traffic, and pipe 2 for replies.
The ethernet rules are stateless, so there's never a link between forward and reply traffic.

I'd recommend re-testing with the fix to #13148 included. That might change things.

Kristof Provost wrote in #note-8:

No, that won't work on ethernet rules. The 'dnpipe (1, 2)' syntax tell pf to apply pipe 1 on forward traffic, and pipe 2 for replies.
The ethernet rules are stateless, so there's never a link between forward and reply traffic.

I'd recommend re-testing with the fix to #13148 included. That might change things.

That fix doesn't fix it.
I'll move dnpipe to L3 anchors to fix the issue.

Thinking about this a bit more, it's expected that

ether pass out quick proto 0x0800 to 3a:d2:8d:84:6e:56 l3 from any to 192.168.20.10 tag cpzoneid_2_auth dnpipe 2003

That means that with the current implementation the output traffic must be delayed by L3 rules.

This should be fixed by https://gitlab.netgate.com/pfSense/FreeBSD-src/-/merge_requests/87 , which changed pf ethernet rules to handle dummynet directly.

Upload/download bandwidth restrictions works as expected.

There still seems to be an issue here when the bandwidth limit values come from RADIUS attributes e.g. WISPr-Bandwidth-Max-Up or pfSense-Bandwidth-Max-Down. I can see the attributes sent correctly on a pcap, but the limits are only applied after re-saving the CP zone configuration. Test on 22.05:

Reboot firewall and authenticate a new client:

02000: unlimited         0 ms burst 0 
q133072 100 sl. 0 flows (1 buckets) sched 67536 weight 0 lmax 0 pri 0 droptail
 sched 67536 type FIFO flags 0x0 16 buckets 1 active
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 ip           0.0.0.0/0             0.0.0.0/0        3      311  0    0   0
02001: unlimited         0 ms burst 0 
q133073 100 sl. 0 flows (1 buckets) sched 67537 weight 0 lmax 0 pri 0 droptail
 sched 67537 type FIFO flags 0x0 16 buckets 1 active
  0 ip           0.0.0.0/0             0.0.0.0/0        3      497  0    0   0

Re-save CP zone configuration:

02000:   1.000 Mbit/s    0 ms burst 0 
q133072 100 sl. 0 flows (1 buckets) sched 67536 weight 0 lmax 0 pri 0 droptail
 sched 67536 type FIFO flags 0x0 16 buckets 0 active
02001:  10.000 Mbit/s    0 ms burst 0 
q133073 100 sl. 0 flows (1 buckets) sched 67537 weight 0 lmax 0 pri 0 droptail
 sched 67537 type FIFO flags 0x0 16 buckets 0 active

The client bandwidth is indeed limited at this point, but after removing the client from Status / Captive Portal and re-authenticating, the issue re-occurs.