@emikaadeo Hi, can you show me your rules?
I have a similar setup with some traffic through the WAN and some through the load-balanced VPNs.
I would like to add traffic shaping to improve the overall internet experience in my home.
@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.
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.
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.
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.
@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.
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.
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
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.