Feature request: Remove fasttrack dummy rule

RouterOS General
1

What behaviour of counters on fasttracking rules do you want?

  • I want no dummy rules. Each rule should count its own counters correctly.
  • I want non-removable one dummy rule for all fasttracking rules to display summary values and real rules can show nonsenses further.
  • I want one dummy rule for each fasttracking rule to display values individually (as many dummy rules as many real fasttracking rules).
  • I want to have general option to enable or disable this dummy rule.
  • I want to have an individual option in each fasttracking rule to invoke corresponding dummy rule for counting values.
0 voters

Hi,
I am absolutely against having general accepting rule in forward chain, that I cannot remove:
fasttrack.jpg
Everyone that sees it must think that it is accepting all traffic in forward chain.

I dont know if it is really accepting or not. This makes big mess in firewall, to have “dummy” rules that (hopefully) do nothing. How can I be sure???

Please, remove it as soon as possible, or at least make it selectable for example in real fasttracking rule open an option to invoke dummy rules for those who want it and keep the firewall otherwise clean without such garbage.

I am using more than one fasttracking rules and such one dummy accepting rule does not say anything. I have asked several times and had not get answer, so asking again:

Why the fasttracking rules do not count their hits but count something different? Make them count correctly and you do not need any dummy rules!

I am creating the polling question. As the answers are not fully disjunctive, everyone can select up to 2 answers.

Thank you very much.

2

Not only these rules are mess for some people (including me), they are just cannot be deleted! Considering everything (obviously excluding some deep system things) in ROS can be set up by us, this is a step backwards.
I can understand these rules if they were unique. But they are just showing the same information that in “IP - Settings”. I’m not too lazy to go there and see, if I need. But I don’t need that info be forced.

3

I hate settings that do not have any real reason but cannot be removed too.

The ipsec policies and proposals that cannot be removed even there is not used ipsec on the device at all, for example. But it is another topic…

4

This feature should be nixed. Not even optional, just removed.

Having a do-nothing rule in firewall because your OS can’t correctly track fastpathed traffic is just kludgy and unprofessional. As stated before, the same counters are available in ip->settings.

5

I imagine this was a quick workaround for what some people were missing and that it will be cleaned up in a future release, but maybe not in 6.30.x .

6

Why not? It’s not a really complex problem. But it’s MikroTik choice anyways — to remove it, or not.

7

+1 ..up

8

Maybe they would fix it, but not in 6.30.x because it might imply an architectural change.

9

I’d like to support you and vote against the dummy rules, which are undoubtedly just a mess. I would have vote for option #1, but your wording is quite misleading. Your “Each rule should count its own counters correctly” implies the rule’s packet/byte counters are incorrect, but in fact they aren’t! What real rule counters show you is perfectly correct. You just need to understand what they show exactly. And Mikrotik needs to document that stuff in a clear way.

As I understand, things work as follows:

  1. If packet matches a fasttracked connection, it is not being processed by the firewall at all. Just accepted. Thus no rule’s counters are being updated when such packets are being processed by your router.
  2. A rule with ‘action=fasttrack’ (fasttrack rule) just marks the corresponding connection-tracking entry for fasttrack. The packet hitting a fasttrack rule is not being fasttracked yet, and thus updates the rules’ counters.
  3. A fasttrack rule does not automatically imply ‘accept’, effectively passing the matching packet through. If you have an accept rule immediately following the fasttrack rule with the same traffic selectors, the hit and byte count on both rules is always the same. This is perfectly normal and expected.
10

Im with you Jarda.

11

It looks like person that that made this pool doesn’t know how fasttrack works:

I want no dummy rules. Each rule should count its own counters correctly.

There will be no difference in counters for other rules - as soon as you enable fasttrack, fasttracked traffic will skip firewall - will not be counted in any rules, will be invisible in firewall and queues, that is how fasttrack works, so with and without fasttrack dummy rule other rules will count exatly the same amount of traffic.

I want non-removable one dummy rule for all fasttracking rules to display summary values and real rules can show nonsenses further.

Same as before…, only small fraction of traffic will go through firewall with fasttrack, and dummy rules have no effect of “nonsense further”

I want one dummy rule for each fasttracking rule to display values individually (as many dummy rules as many real fasttracking rules).

Fasttrack-connection works with connections, similar to connection-mark, you don’t know how many rules are marking your traffic with the same mark, it is impossible.

I want to have general option to enable or disable this dummy rule.

I can agree to this option, but be ready that there will be someone that will report that traffic is missing in firewall and queues as soon as you disable it.

I want to have an individual option in each fasttracking rule to invoke corresponding dummy rule for counting values.

Already stated before - it is impossible as fasttrack is binary flag in connection tracking you can’t say what rule added the flag.


Bottom line, If you use fasttrack, most of the traffic will take the shortcut, skipping your firewall counters and queues, that is the way it works.
So fasttracked traffic is invisible for firewall and queues. To make it visible dummy rule was added.

so the pool options should be

a) i like dummy rules it allows me easier to see all my traffic in the firewall
b) i don’t like dummy rules, i can live with traffic that is invisible to my firewall and queues
c) i like option that allows me enable/disable dummy rules

12

Sure I am the person that does not know everything. And probably I do not fully understand the fasttrack counting approach.

I know that the fasttracking rule more or less works like mange and once the connection is marked it bypasses the firewall.

But: If there is possibility to count the values and display them in dummy rule, the values could be displayed on real rules instead on the dummy ones.

I am mainly against the forced dummy rules. If I would like to have such rule in firewall or in mangle, I would like to put it there on my own. Maybe some other options are not smart enough, but it is interesting anyway what people vote for…

13

It is a workaround, you can’t get those counters any other way manually, you need to go to /ip settings to see them
Check console, it have better representation. of that rule, winbox view can be misleading i agree.

14

Dummy rules show cumulative fasttrack counters (i.e. grand total bytes/packet fasttracked). You may have more then 1 fasttrack rule in your configuration, and showing the same number of packets/bytes on all your real fasttrack rules will be even more misleading then it is now with the fake (dummy) rules. Making fasttrack update per-rule counters is not an option, I think, as that should be quite expensive, while fasttrack is all about performance.

15

Maybe it is correct, but you never know. We are not ros developers.

The counters are held in conntrack on each connection individually. Maybe it is possible to number internally the fasttracking rules and add this number to each connection in conntrack while marked as fasttracked connection to be able to distinguish to which fasttracking rule the connection belongs. Then the regular counting would be easy and almost as fast as in total. This could be a way that mikrotik can solve my request, I think…

I guess that the counting is not part of firewall but part of conntrack anyway. So I still see possibility to get the right values where they should be.

16

Already there.
123.png

17

Where do these rules come from? I have some RB2011 with these rules and some RB2011 without these rules. All are running 6.30
These rules caused real headache because my configuration script does something like:

  1. disable all interfaces
  2. clear all firewall rules (filter, nat, mangle)
  3. do something more
  4. enable specific interfaces
    Of course my script fails at this point:
[admin@INCOMPLETE_CONFIGURATION] > :foreach item in=[ /ip firewall filter find ] do { /ip firewall filter remove $item }
failure: cannot remove builtin
[admin@INCOMPLETE_CONFIGURATION] > :foreach item in=[ /ip firewall mangle find ] do { /ip firewall mangle remove $item }
failure: cannot remove builtin

I will change it to delete only non-dynamic rules. But it would be interesting to know.

Edit 1: These rules are not there when I do a /system reset-configuration no-defaults=yes . So I do not understand why they are separatly handled as “built-ins”

18

Looks like it is another unwanted effect of such “dummy” bad things.

19

I only a new with RouterBoard and only test for a little with fast-track. And this is my think about dummy rule:

  • I like this dummy rule because I can get a look over all fast-track streaming. I do not see the need to be monitored on a fast track streaming.

  • But I also like the option to disable/enable this rule when I see don’t need them.

20

It means you want the non-removable dummy rule as it is in 6.30 at the moment and simultaneously you want to be able to remove such non-removable dummy rule? Is not that contradictory?