What happened with this? Any solution?

@andresmorago said in Help required for a simple QoS setup:

@ninthwave
I’m having exactly the same upload issues. I also reported them on that thread. https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/1045

I temporarily fixed that by multiplying the upload bandwidth parameter by 10.

Thanks for quoting me. Since my problem could not be resolved, I reverted back to using the wizard.

I will closely look at your thread to see if it finds any resolution.

Per https://docs.netgate.com/pfsense/en/latest/trafficshaper/advanced.html#shaper-rule-matching-tips you have to use tagging to prioritize based on the LAN IP of the NAS.

If you know the IPs of the cloud service you could lower the priority based on those, but I would expect those to change over time.

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

I just ran into this bug on the new SG-2100. I configured a VLAN switchport and added CBQ traffic shaping on the new OPT interface and it locked up, hard.

I had to reset the device to factory defaults to recover. This bug is disastrous in a production environment.

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

@teamits But they try to fit new packets in the queue by dropping new ones (tail drop) or randomly (Random Early Detection), right? Or I got it wrong?

@adrianx

in the mean time you could try and find the differences between the DDOS packets & the good packets by doing packet captures (& analyzing them in wireshark)

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

not sure if it matters, but found out its not just glftp, seems like all FTPS traffic is a problem (happening when using filezilla on a windows machine also)

@ipfftw
this is old but is it still working for you? I do not see any screenshots, probably cause this is so old...

@gcon Post above supposed to say "and TUN_LT2_GT1 OpenVPN tunnel is admin disabled), " but I'm now getting spam blocked from too many edits.

@rj said in Traffic Shaping on SG-5100:

Couldn't all the traffic shaping be done on the WAN interface since that is where the real bottleneck is

Shaping happens when packets leave an interface. (https://docs.netgate.com/pfsense/en/latest/trafficshaper/index.html#traffic-shaping-basics)

@tman222 when using limiters I disabled all altq shapers, using tail drop for management algorithm, worst case weighed fare queue for schedulers.
When using shapers I was using hsfc. Default queue size from wizard.