@kom Although I am using "multi WAN" (WAN and VPN), my applications are running on the WAN interface. There are no Gateway Groups or anything, I just have the VPN assigned as a gateway for a couple of devices (not for the server running the torrent client).

@psilospiral A shaper is better than a limiter because the low-prio stuff can use full bandwidth if the network isn't busy. You don't have to guess how much bandwidth might be needed. When other stuff starts happening, the low-prio traffic gets dropped. You can also try the fq_codel shaper as it's reportedly easy to setup. There are good YouTube videos on how to configure it from Netgate and Lawrence Systems.

@tohil said in Traffic Shaper with LAGG and VLANs:

@steveits

Thanks for your fast answer.
But with multiple VLANs on the lagg, I cannot Set an WAN download Bandwith for shaper on LAN vlans without also limiting lan to lan traffic.

This statement is correct isn't it? LAN-to-LAN will also limited, because the egress traffic on an interface will match the shaping rules. This means LAN-to-LAN will be handled like WAN-to-LAN Traffic.

@steveits

Yeah, I see…. LOL

I guess I always confused the capital MB vs Mb as being the same thing. Thankfully, I paid enough attention to notice before I made the wife upset when things stopped working.

I always say, I know just enough to blow myself up. 😂

@thiasaef Amazing. Thank you!

@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.