Using iperf3 to test traffic shaper rules. Everything is working, except my one tcp (ACK packets only) rule. It matches absolutely every iperf3 TCP stream, if it's positioned at the top of the rule set.

If I reposition said ACK rule to the bottom of the rule set, everything works as it should (ie correct traffic into the correct queues).

I have to imagine this is a bug, as you would normally want to catch ACK's and prioritize them towards the top of a rule set. Even if you didn't, it still shouldn't be matching all TCP traffic.

This should be very easy to reproduce...

Simply make a rule bound to WAN, tcp (ACK packets only), any:any any:any, direction out, place at or near the top of your rule set. It will match all outbound WAN traffic, regardless of the ACK flag being set or not.

If I change the protocol of the rule, from tcp (ACK packets only), to tcp (non-ACK packets), the rule then matches absolutely no traffic at all, including ACK packets.

So, the two options are NOT reversed or anything like that on the back end, they are both simply handled wrong (misconfigured) by the back end code.

To me, this seems rather important, as being able to get both full upload and download bandwidth at the same time, relies heavily on being able to prioritize ACK packets. As is, OPNsense cannot do this.

On top of that, anyone with a previously working QoS config using ACK rules, isn't working even remotely as they intended.

Seeing what you are describing, here I am, stating that I didn't manage Traffic Shaper to work. It is activated, my intention being on sharing the bandwidth evenly between users, but no matter the settings, I didn't get it to work as intended.

More than this, I somehow concluded that it makes no difference if it's enabled, disabled, or set-up in a particular way otherwise.

I gave up for now, but it might be the same underling cause you have described? Maybe!...

Unfortunately for you, I do not think the two are related. If I (re)move the tcp ACK rules from my rule set, everything works as expected.

Getting QoS to balance is somewhat difficult to grasp at first. Try reading https://docs.opnsense.org/manual/how-tos/shaper.html again, case #2 applies directly to you. If you still can't get it working, start a new thread, many users here (including myself) have gotten this to work, and I'm sure they'd be happy to help.

The box is down right now at a remote location, faulty hardware. I should be driving there this week to swap it out with another box, keeping the same storage device & config (the SSD is the only new component in it).

add 60001 pipe 10001 ip from any to any src-port any dst-port any in via fxp0add 60002 pipe 10004 ip from any to any src-port any dst-port any in via ovpns1add 60003 pipe 10003 ip from any to any src-port any dst-port any out via ovpns1add 60004 queue 10001 ip from any to any src-port any dst-port 67-68 out via fxp0add 60005 queue 10001 ip from any to any src-port any dst-port 53 out via fxp0add 60006 queue 10001 ip from any to any src-port any dst-port 123 out via fxp0add 60007 queue 10001 icmp from any to any src-port any dst-port any out via fxp0add 60008 queue 10001 ip from any to any src-port any dst-port 5201 out via fxp0add 60009 queue 10003 udp from any to any src-port 1194 dst-port any out via fxp0add 60010 queue 10002 ip from any to any src-port any dst-port any out via fxp0add 60011 queue 10000 tcp from any to any src-port any dst-port any out tcpflags ack via fxp0

As of now, the rule using the "all ACK's" preset, is at the bottom of the stack, because it matches all traffic. If anybody can spot why (I can't), hopefully we can get this fixed, as well as the "any but ACK" preset.

It is definitely a bug. I'm not sure where the bug lies, in OPNsense's implementation, or upstream. But it is most definitely a bug. A quick packet capture confirms that.

I was hoping a dev would see this, and either weigh in, or create an issue. As you can see, that never happened. I played with it a bit, tried adding / modifying rules manually via SSH, I never got it to work like it should. Ended up just not using ACK / non-ACK presets.

I never did get around to opening an issue on GitHub either, I don't have time to work through to resolution at the moment, so feel free to do that