@turrican64 You might be looking for a limiter anyway. Shaping prioritizes traffic, while a limiter caps bandwidth usage.

Interestingly I ran into a similar scenario today. A client with an SG-2440 and pfSense 2.4.5 upgraded cable from 75/15 to 300/30. Shaping had been configured and working fine when I started. With shaping configured and the numbers adjusted upwards, I couldn't get above 90-100 download after raising the bandwidth. I tried deleting shaping and recreating it a couple of times. With shaping off, testing could get up to 350 down but the CPU was maxing out (it also had Suricata). With it on, downloading was around 100 Mbps but only 40% CPU.

@farmerjohn based on this netgate forum post, I simply added the same WAN queues I was using in the Floating rule to the LAN rule for openvpn clients. I just reversed the order for the in/out pipes. I ran the waveform.com test and download speed increased 10% and 'active download latency' dropped from 129ms to 94ms. Significant improvement - I'm just not sure if this is the best solution for handling openvpn clients via traffic shaping.

@farmerjohn reboot seems to have fixed.

@steveits said in bufferbloat / limiter = hair pulling: ely 2.5.1 should be out shortly (days im wondering if after i upgraded to 2.5.0 things started happening . i cant confirm . ill keep looking , thanks for the info all

@bigtfromaz After further investigation this appears to be an upgrade issue. The Rule in question was disabled during the upgrade. Apparently there was a breaking change somewhere along the way and the upgrade process did not fix up this rule. I made an innocuous change to the rule and saved it. The syntax errors stopped. To be sure, quality has suffered recently, especially with IKEv2 tunnels. It's causing us concern.

Here is the first finding: When these rules active, pfsense can not make any connection to internal or external endpoints.

I was trying to deprioritize a specific download (IP) tonight and having trouble. I found if I view Diagnostics/States the states are shown with the server IP (behind pfSense) as the destination (on both WAN and LAN). If I set the floating rule to use the IP as the destination, it puts the traffic in the qOthersLow queue. So I suspect the state bytes count is the count of the inbound URL request (several dozen bytes), and not the amount of the traffic actually going into the queue (multiple GB of download).

@emikaadeo In case your not aware already, the limiters are applied per gateway meaning if you apply limiters on your WAN gateway it does not apply to your VPN gateway regardless of being on the same interface. There is also several threads on using the same limiter on multiple gateways and none seemed to be able to get it to work if i remember right.

Seems to be resolved in 2.5

@jimp Thanks, will do!

There is an issue that has been identified with dynamic IPv6 gateways (for example, if you use DHCPv6 to obtain an address/prefix). The gateway is not being populated properly behind-the-scenes, which has a ripple effect to other areas in pfSense, including gateway selection in rules, which I believe is what all here are experiencing. There is no fix available yet (the fix for "dpinger" was to manually specify a monitor address, but that won't have an effect on gateway selection in rules), but if you want to track the bug: https://redmine.pfsense.org/issues/11454

@vmac I know it’s not much help, but I’m getting the same after upgrading to 2.5.0 with an igb driver.

I seem to recall somewhere in the docs that Netgate recommends using the same speed measurements everywhere but I couldn't find it in a quick search. I don't seem to recall that issue though.

The traffic shaper wizard should do that by default for you. https://docs.netgate.com/pfsense/en/latest/trafficshaper/index.html If that's all you want you can basically ignore the other options (e.g. VoIP or P2P).