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
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).
Take a look further down on https://docs.netgate.com/pfsense/en/latest/trafficshaper/limiters.html#creating-limiters in the Creating section and it may describe it better. Masking to the IP creates one limit per IP and as I understand it masking to a subnet would create a bucket for that subnet to share. "When set to none, the limiter does not perform any masking. The pipe bandwidth will be applied to all traffic as a whole."
@phming Just to liven this one up again ive got this problem. My hardware is a Nuc with the onboard lan doing the WAN connection and the LAN being taken care of by a USB dongle. I got the same message when it was setup the opposite way round...
@anand_phulwani as your floating rule is direction is 'out', you need to swap your in/out pipes. Place download to the left.
The left slot is always in the same direction as the floating rule direction. In this case, 'out' to the LAN means traffic from the firewall to your LAN devices (download).
Also, use tail drop for your queues; if you check the limiter info you will find that codel doesn't work if you have codel on both queue management and limiter, i.e. it's empty.
Turn off ECN and leave the queue length at default/empty.
From my experience bandwidth needs to be about 90% of speed test results before the even distribution will work.
Lastly, FQ-Codel doesn't distribute bandwidth evenly so stick to WF2Q+. To prove this, start a torrent or a steam download on 1 computer and do a speed test on another. If it works correctly you'll get roughly even bandwidth. FQ_Codel in this scenario, in a 40MBps connection, will have 2-3MBps to the speedtest and the rest to the torrent.
the ftp itself works fine, problem is limiting the bw at the router side
i actually made a tcpdump right before making this post and looked at it in Wireshark, but not sure what to look for that will help me limit it
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.