Transparent bridge shaper with limiters, upload issues

I've decided to add a pfSense traffic limiter on my network and it seems to be behaving oddly by extremely clamping down on the upload speed.

I have a 50/50mbps internet connection.
Running pfSense 2.4.4 on a core i5 with 3 NIC's (2x Intel Pro/1000 for WAN & LAN, and on-board for management web interface).

Stock install of pfSense 2.4.4, default tunables, no IP set on WAN/LAN interfaces. WAN & LAN joined in bridge0. Bridge0 is not assigned to an OPT interface.

Under Traffic Shapers, Limiters, I created 2 limiters, one called "UPLOAD", and the other "DOWNLOAD". Both are set to 10mbps, no masking, CoDel/FQ_CoDel, everything else default.

Under Firewall Rules, LAN, I created a rule to pass any traffic from 192.168.1.5 (test station to be limited) to !192.168.1.0/24, IPV4, TCP+UDP, with the Limit In=UPLOAD, Out=DOWNLOAD. Besides that rule, below it there's a pass any/any/any... rule to allow everything else, with no limit.

On speedtest.net, the download speed shows as correctly being limited to 10mbps, but the upload speed is limited to just under 1mbps, sometimes even giving an upload error.

If I remove the In/Out Pipe settings, save the rule, apply/reload the firewall, speedtest.net gives ~50mbps/~50mbps.

Any suggestions? I've tried various combinations under the Limiters for the Queue Management Algorithm and Scheduler, but it doesn't seem to help.

As a note, the pfSense box is between the LAN port of my router (192.168.1.1) and the uplink of my switch. The LAN port port of the router is connected to the "WAN" interface in pfSense, and the uplink of the switch is connected to the "LAN" interface.

@xandercdn Can you try using floating match rules, one for LAN-In and one for LAN-Out? I'm assuming you have one limiter for IN and one for OUT? Below links to an example I shared today that should help you get something working - just change the bandwidth and remove the packet loss and delay values.

@xandercdn Can you try using floating match rules, one for LAN-In and one for LAN-Out? I'm assuming you have one limiter for IN and one for OUT? Below links to an example I shared today that should help you get something working - just change the bandwidth and remove the packet loss and delay values.

I'm away for the week-end, but I'll give it another try on Monday evening... I know I had tested a floating rule for the IN and OUT directions for traffic from 192.168.1.5 (station I want to limit to a 10/10 pipe) to reverse match 192.168.1.0/24 (anything not on the LAN) and the floating rules were not showing as if they were hitting anything (the counter next to the rule was not showing any packets or bytes being processed).

...
Just remembered also, I had issues because I believe the floating rule wanted to have a "Gateway" setting, and there is no gateway, because it's a bridge. As far as pfSense is concerned, there's no default gateway or nat'ing going on.

@xandercdn Can you try using floating match rules, one for LAN-In and one for LAN-Out? I'm assuming you have one limiter for IN and one for OUT? Below links to an example I shared today that should help you get something working - just change the bandwidth and remove the packet loss and delay values.

I created some floating rules as you suggested, however only the "IN" floating rule seems to be catching any traffic, so I applied the traffic shaper queues to the In & Out Pipes of that rule, and the result is the same, speedtest.net shows the upload is less than 10% of the shaper's limit. At first I had set the shapers IN and OUT to be 6mbps, and on speedtest.net, the download would be limited correctly at 6mbps, but the upload would error out. If I bumped up the upload/out limiter from 6mbps to 20mbps, then speedtest.net wouldn't error on the upload anymore, but would only show ~1.5mbps.

@xandercdn Hmm, well I don't have a bridge configuration to test with currently but I do have a bench with quite a bit of kit. I'll see what I can figure out in the next day or so and get back to you. I know there is a bug related to limiters and bridge interfaces but it appears you are placing the limiters on the interfaces and not the virtual bridge interface. While you're waiting, have you tried using a match-In floating rule on each interface, one for WAN and one for LAN, applying the queues to the rules in the appropriate orientation based on the direction of traffic?

@xandercdn Hmm, well I don't have a bridge configuration to test with currently but I do have a bench with quite a bit of kit. I'll see what I can figure out in the next day or so and get back to you. I know there is a bug related to limiters and bridge interfaces but it appears you are placing the limiters on the interfaces and not the virtual bridge interface. While you're waiting, have you tried using a match-In floating rule on each interface, one for WAN and one for LAN, applying the queues to the rules in the appropriate orientation based on the direction of traffic?

That's correct, I was applying the rules directly on the WAN/LAN interfaces, not on the bridge itself. I'm aware the system tunables need to be changed to allow the packet filter to work on a bridge, and the bridge needs to be assigned to an OPT interface/role.

I changed from interface rules to floating rules as you suggested, and it works just the same as it did with the normal rules on the WAN or LAN interfaces. Essentially, the shaper for the download works fine, but the shaper for the upload is still being restricted to like 1/10th of the shaper limit for the upload queue.

For the time being, I've just multiplied the upload shaper by x10 to make it behave the way I want, but I'd still like to get to the bottom of it, whether it's a bug or me doing something wrong.

"net.link.bridge.pfil_member=1" and "net.link.bridge.pfil_bridge=0" under system tunables.

Outgoing NAT is disabled

WAN has an IP address for management

WAN and LAN are joined in BRIDGE0

I do not have the bridge assigned under "Interface Assignments"

I configured 10 Mbit/s in and out limiters using this example. I did not create the first two floating rules for ICMP since NAT is not involved in this config. If you want the limiter to only apply to a certain IP(s) you can change the source and destinations accordingly.