How I see it, may not be accurate since I don't use Squid since a long time: When you are using Squid, the connection is no longer between the host and the web server. The connection is between pfsense itself and the webserver, thus the definition of proxy. The rule in which you applied the limiter will no longer be used. Transparent or explicit proxy, both are affected by this behavior. What you can do is to enable limiter in the squid itself, or set limits through Radius if you configure squid to authenticate through it. I didn't test the Radius authentication with Squid, so I'm not sure if it would work.

Same issue here, I have a totally unrelated interface with a 40 Mbps traffic shaper on upload and download, whenever I enable captive portal on an unrelated interface and enable per user bandwidth limitation any other interfaces with a traffic shaper completely lose internet. What is happening here?

@sysadminfromhell In general, a limiter limits bandwidth. A shaper prioritizes packets. Sometimes they are used together. Netgate has a page on bufferbloat also, which uses both. I've not set that up myself, I've used the shaper with other methods, like PRIQ only prioritizes packets.

"your experience with fq-codel is impossible unless you misconfigured it" I never said that. Yet your replies are contrary. My reply is still the same: If possible use CAKE (preferably with the ingress keyword) if you want to maximize throughput for a given increase of latency (which ultimately effects the packet loss rate). Question your solution if you have to sacrifice 40 % of your throughput in order for FQ-CoDel to have no packet loss on sparse flows. not to mention the dozens of lines that show you have not read the documentation you linked to I leave it to the reader to judge who has neither read nor understood it.

@jimp said in Old bug or new issue?: Those are not the same rule you have failing in the error message. The one in the error message has a different description. Check all the other tabs and see where that specific rule is, labeled "Connections From Upstream SIP Server" Rebooted today and the issue is gone.. bizarre

@demux To the 200Mbit and 20Mbit pipes you created, the remainder of your bandwidth does not exist. Any traffic that you assign to those pipes using firewall rules will only ever have access to a total of 200Mbit and 20Mbit of bandwidth respectively. If you assign all your traffic to one or the other of these two pipes, then the remainder of your bandwidth will just go unused.

@tman222 awesome! thanks for the information :)

@jaypfadmin You saved me HOURS of troubleshooting!

I created a small tool luckman212/stv to help make it a little easier to debug states. In case it's useful to anyone else.

I think I figured it out. I was using one limiter for all interfaces. I created one limiter per interface and it appears to be working as desired. Sorry for asking a dumb question.

@thiasaef said in Question about firewall rules for FQ_Codel Limiter: @fsr the source port randomization should alleviate the issue: By default, pfSense rewrites the source port on all outgoing connections Thanks for your answer. It certainly looks like the limiter does a good job, even after NAT.

Also is this graph from Flent? Yes.