@Poli Oh I founded that, so BSD still didn't fix it ? https://redmine.pfsense.org/issues/12661

I guess the fix was an upgrade from 2gb/s to 4gb/s why so low? https://reviews.freebsd.org/D31582

@MaxRackstraw To better answer your throughput question the 1100 should top out around 400-500 Mbps I’d expect. If you don’t need packages that use lots of disk writes or RAM then it’s a fine little router.

https://www.netgate.com/supported-pfsense-plus-packages

@SteveITS

Thanks man.

While you typed this, I set up a virtual server and tested in a sandbox..got it!

fda705f3-a69e-4b65-9d88-296fdf82f207-image.png

@ctrlbreak Can you post your queue config? If the wizard was used there is this issue for instance: https://forum.netgate.com/topic/166621/priority-of-qotherslow-higher-than-default

@Antibiotic

Sometimes it is better to NOT make your connection better to other hackers.

@aweber

Yes. I got fq_codel working on a bridge in OPNSense and pfSense, but there seems to be Free and Double free errors on the machine and maybe on my XGS-PON. I am using FTTH. I think the errors are from applications trying to negotiate various link speeds and IOTCL not knowing which way is WAN and LAN. I was also running sensei/zenarmor on the LAN and fq_codel on the bridge.

I got hit by some mitre attack, binding public IPs to my bridge too. Perhaps DHCP and transparent DNS on unbound were to blame, as turning off DHCP seems to drop my link speed from 2.5gbps to 1gbps on my NBase-T NICs. This bit was never an issue with an AT&T router bypass. VLAN 0 stinks :) but at least OPNsense and pfSense recognize it. So can Mikrotik RouterOS devices.

Is it "supported"? No. Should it only be done with TCP? Probably. What about D-TLS and direct memory access NICs? What about putting IGMP in traffic shapers? What about file descriptors on local device NICs? What should they be set to?

I may go try out crowdsec one of these days.

https://youtu.be/zGTzeWYfy8o?si=Bb9RuXeyHmwWzoh-

Here is a maybe insightful video. (Wish I knew how to code :p)

@JonathanLee

The config.xml seems fine, and I have double checked all my setting before I posted here, but thanks for the advise.

In the Diagnostics/Limiter Info show the current bandwidth set it never changes when the Schedule does, I have tested doing speed test to make sure which Bandwidth is been used, as in my first post it only changes when I press save in Limiter settings.
Thanks anyway.

@SteveITS said in Upload speed too low:

https://docs.netgate.com/pfsense/en/latest/trafficshaper/vpns.html

904ad7ca-0908-461d-8b0a-6ab741ff1f18-image.png

c9ce88fc-7357-42d5-b0ec-3dd880218406-image.png

1de6458e-3de6-4e9d-8a22-2887367d9548-image.png

Use Floating with Match for Limiters and no quick.

Try codel instead of tail drop in the Limiter itself.

@jc1976 Netgate has a recipe at: https://docs.netgate.com/pfsense/en/latest/recipes/codel-limiters.html

I was trying it out a bit myself, following the above, and on my home 2100 the download speed drops from ~525 with PRIQ to ~430 with FQ_CODEL. I have not dug into it much other than switching back after a day. I would guess maybe a CPU limitation of the 2100's ARM CPU?

@MindlessMavis

ok i did some more testing on this, and it seems not the best for me, and goes to show that its important to test extensively lol

i use a lot of upstream from offsite backups, camera footage, uploading to my vps etc, most of which i have automated through a specific docker host.

so the rules on WanUp work really well, i use a 90/10 weight with 90 being on WanUpQ and 10 being on WanUpQ_LP

this ensures that everything which isn't upload heavy, gets really nice latency

the part which wasn't well configured was the WanDown, I erroneously set it to being the same without applying conscious thought to what it was doing.

I still had the same 90/10 rules in weight but if you think about that for a moment, what happens when anybody is thrashing download? then the weight system comes into place, and the things that i don't care about in the LP queue end up getting undue / undesired priority.

So I have now switched that to scheduler FQ_CODEL and its working much better.

YMMV so test and find out, run a ping to a local news site or similar, alongside multiple speedtests and see which combination of settings performs best for you.

@tman222 said in Bandwidth Limiter Not Working 23.05.01 for Policy Based Routing Firewall Rules:

@break1146 - thanks for your response. I actually came to this thread after noticing that the limiters did not work correctly when applied to LAN rules when a gateway group is used as the default gateway on the rules. Essentially what I was seeing in that case, was that the upload was correctly limited, but the download was limited to only 50% of what the limiter had been set to. I tried out the approach you suggested (floating rules on WAN with tagged LAN traffic) and everything works as expected. Perhaps this is a bug that I should report? Or would you have any ideas as to why I'm only seeing download limited to 50% of limiter value when applied to LAN rules directly? Thanks again.

Just to close the loop on this, it looks like the issue I was experiencing where the download was limited to only 50% of what the limiter had been set to has been resolved in 24.03:

https://redmine.pfsense.org/issues/14854

Btw, all ipv6 disabled. Why creating ipv4 and ipv6?

@TheNarc said in Bufferbloat recipe and rule direction:

You didn't specify, but just make sure that your floating rule's action is Match, not Pass, and that it is not a "Quick" rule. In my setup I just have two floating rules with the Match action, one for In on WAN and one for Out on WAN. That way you don't need to remember to assign the limiters if you add extra Pass rules on the WAN interface.

Thinking about it, this makes good sense. I have a few services port forwarded. One is my VPN and the others are web based services. I want to throttle the latter but keep the VPN speed unfettered.
If I were to take a consistent approach (i.e. apply similar traffic shaping methods to the inbound), I think I'd need to create multiple limiters/queues in order to differenciate the speeds available to VPN vs the 'slower' services.