I’m mucking about with simple queues and I haven’t had any success getting a queue to apply unless I completely disable fasttrack in the filter rules, the following filter does not work, the excluded host is fasttracked along with everything else and the queue config is ignored:
I’ve also tried filtering for fasttrtack using address lists and subnets to get the queue to work, no success, all fasttrack needs to be disabled. Ideas?
OT:
I’m sure my limits are wonky, I didn’t read the documentation thoroughly, but it is having the desired effect when it does work. Yes, I am working at double digit Kb level of traffic flows. Don’t ask.
Think about your rules. For example, packet from 192.168.1.12 to 1.2.3.4 will be ignored by first rule, because the src-address=!192.168.1.12 condition is false. Which means that processing will continue with second rule and connection will get fasttracked, because if destination is 1.2.3.4, then dst-address=!192.168.1.12 is true.
The most straight-forward way of “not fast-tracking” certain connections is to accept them using “normal” rules before they have chance to hit the fasttrack rule. E.g.:
The later two rules are (somehow) rules from default firewall setup which enable fasttrack-ing vast majority of connections (traffic). The former two rules (in green colour) are two additional which, being above the fasttrack rule, take precedence and accept eligible connection before they have chance to hit the fasttrack rule.
Use of negation in “selector properties” of a firewall filter rule (or anywhere else where negation can be used) is, as @Sob showed, highly error-prone as it might kick arses left and right if not properly thought out. So it’s often better to come up with additional rules which do the job properly and place them appropriately.
Thanks for the responses, extremely helpful in reminding me to pay close attention to what I am doing and what I missed.
Yes, the negation is a great source of headache and I see what you are saying about the rule. My bad.
For the latter of accepting the traffic to be queued, I tried that but it didn’t seem to work. I’ll re-visit and reboot. It would not be the first time I have had packet processing be wonky on changes without a reboot, I was just trying to avoid reboot because it is a production system with real time data flows.
When it comes to changes in firewall filter rules, it’s important to keep the following in mind: after a connection is fast-tracked, it never gets “un-fast-tracked”. So if one adds a rule which should treat existing connection differently, then it won’t. It will only affect new connections.
And the most robust way of making sure firewall considers connections are new is to reboot device.