@jonathanlee Thank you very much for this attempt. I am personally very graphically untalented, but very responsive to good graphs. If ever you have a chance to give this a go again, to revisit and re-use your first tail drop diagram in contrast with codel alone - codel drops from the head of the queue, not the tail, and I would perhaps draw a 5ms target window at the same 4 packets you use here and feature a few more packet slots as a shock absorber. then three phases queue over target showing timestamps shock absorber filling -> dropping from head when too old queue below or at target I have NEVER managed to describe how codel operates well enough to suit me, and fq_codel, or for that matter, cake, oh, man... https://lists.bufferbloat.net/pipermail/bloat/2013-February/004888.html To try and describe how fq-codel works, I would use a single queue on the front left there with different colors for packets and their bunches. I do things like AAAAAABBFBBEAAAFEAAACAAA -> And coming out: BABAABFA BCEFCA Which is kind of accurate for a per packet FQ system, but DRR is different and having the longer blobs to represent bytes rather than packets might help. Does that help any?

Ended up reverting back to 2.5.2 and everything works as it should. Not as I want, but at least the static traffic shaping does what it is described to do in the guide.

@steveits yes i did just wanted to ask because of the any any rule however it is on the outbound

@steveits Try using pfBlocker to create aliases based on their ASN numbers. YMMV.

@simonjcarr I think I have solved the problem, although I will see over the next 24 hours if I am issue free. The problem seemed to be related to an App on my Iphone. I don't know which one. It dawned on me the issues were only happening when my phone was active. I deleted about 10 apps that I had installed over the last few weeks, and have not had the problem since. I am assuming, that one of the apps got an update over the last few days and it mush have gone rogue.

@tleguizamon Same for me - limiters doesnt work correctly. You need to downgrade form 2.6.0, or wait until repair will be doployed. Have you turned of captive portal?

@chrcoluk And before you test the limiter u have to kill all states

@larrikin Hi, did you ever find a solution to this?

@enjoyit Hi, I'm not using Gateway Group anymore. I've switched from OpenVPN to WireGuard. My current anti-bufferbloat config is a combination of this two guides: https://docs.netgate.com/pfsense/en/latest/recipes/codel-limiters.html https://isc.sans.edu/forums/diary/Securing+and+Optimizing+Networks+Using+pfSense+Traffic+Shaper+Limiters+to+Combat+Bufferbloat/27102/

@bartkowski Noop. Not using limiters right now. "They" know the issue exists, something good will come out ... soon ...

@syserr-0, just use regular traffic shaping (e.g. fq codel) on the WAN interface of the office box? Tutorial: https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/814?_=1645275206163

@akuma1x many many thanks for your help :) I'm a newbie and users support its very useful in my case. I will take a look at th delinks you provided and I will try.

Just found another issue related to DSCP rules. It seems that the rule will match TOS value instead of DSCP value. For example, I originally set CS1 (DSCP value 8, equal to TOS value 32) in the rule, right now I need to set to CS4 instead to match the packet with DSCP value 8 (TOS value 32)