Hello,

I found that disabling connection tracking by setting "/ip firewall connection tracking set enabled=no" will add 2 rules to raw table (with action=no-track) and it will not flush "connections table" (entries have to timeout natively).

On the other hand, when "/ip firewall connection tracking set enabled=auto" and I delete all filter and NAT rules, "connections table" is flushed and no entries in "raw" table are added.

My question is, if results of both methods do exactly the same. Does anybody know? I can not understand, why "auto" mode disables conntrack only if no filter rule is present. Any stateless rule in filter table causes conntrack to enable.

Thanks, Blažej

More info here https://wiki.mikrotik.com/wiki/Manual:I ... n_tracking
When set to no then connection tracking is disabled.
If set to auto then if you have a filter or Nat rule it will automatically get enabled.

What I'm trying to say is that these two methods don't do the same thing. And I think, it can have impact to performance also.

(I think that conntrack disabled in AUTO mode disables some parts of Linux Kernel network stack completely. But forcing conntrack disable just cause to mark all traffic with "no-track")

You have to specify each time which version you are talking about and, if relevant, also what model...

I just check on RB5009 wit 7.2.3 and on RB911G with 6.48.6, but on both never appear rules on firewall raw when I set connection-tracking off...

The point being, that set either OFF if you dont want any at all, or AUTO, if you want it to work at the right time.
The better question is do you want the default loose tracking enabled, or the alternative unchecked and thus strict tracking enabled.

I just check on RB5009 wit 7.2.3 and on RB911G with 6.48.6, but on both never appear rules on firewall raw when I set connection-tracking off...

I checked this on RB2011 running 6.48.3.
https://i.imgur.com/tNESJpN.png

on comment I see "/ip firewall connection tracking set enabled=no"
is the first time I see on comment a command instead some... comment...
suspect something strange........ like a fake....

Yes, it is strange. Because of this I opened this ticket, what that is.

Just to make sure, these rules are:

The thing is that what you've actually open is not a "ticket"

Sorry, it is just typo ... but I opened ticket also (SUP-81934).

When you tried to turn the conntrack off, did you have any rule in filter/NAT table? EDIT And did the connections table flushed after turning off? yes

I not understand why on my two test devices do not appear anything on firewall raw:

checked on RB5009 with 7.2.3 and on RB911G with 6.48.6

Some other rules inside firewall filter, nat or mangle?

ROS v 7.2, setting connection tracking to off created the exact same Dynamic entries in the RAW table too...

ROS v 7.2, setting connection tracking to off created the exact same Dynamic entries in the RAW table too...

Hmm, we have to wait for support reply in ticket. I will keep in touch.

ROS v 7.2, setting connection tracking to off created the exact same Dynamic entries in the RAW table too...

Instantly or after reboot?

For me, it's instantly.

On RB760iGS (hEX S) with 6.48.6 is happening also for me...
I discover the differencies: the other two devices on production do not have any firewall rule (because are protected from another firewall device).
Adding one firewall filter rule, enable also on that devices the raw rules.
(and also have same comment)

Thanks, today I discover something new about RouterOS.

Back to OP, is like than really you can not disable for real connection-tracking, but if act like those rules are added when some other rule on filter or NAT are added.
Adding RAW rule, place the dynamic added rules at the end, because on RAW connection tracking do not have effect.

When you tried to turn the conntrack off, did you have any rule in filter/NAT table?

I also think, this behaviour depends on rules in filter table. It looks like Mikrotik completely disable some kernel parts, when there are no filter rules. But when there is any, mikrotik can not disable these kernel parts. So this "no-track everything" solution is used. It also makes sense, why any, even stateless filter rule, automatically enable conntrack in "auto" mode.

And there we are. I think that "disabled" conntrack, when there are some filter rules, will not save as much CPU as when disabled natively in "auto" mode.

Documentation on connection tracking says about property enabled:

Allows to disable or enable connection tracking. Disabling connection tracking will cause several firewall features to stop working. See the list of affected features. Starting from v6.0rc2 default value is auto. Which means that connection tracing is disabled until at least one firewall rule is added.

But if there are some rules (because they make sense to be used in stateless firewall scenario), connection tracking is not entirely disabled. So it seems they came with the "workaround" rules, which are pretty similar to rules which one can construct manually and would only affect portion of traffic flowing through router. And in this case the property of these default rules comes into play:

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"

Which, IMO, at the end of the day means that "connection tracking disabled half way" means only limited reduction of processing required ... firewall still has to at least look at packet to determine that it doesn't need connection tracking (so it skips actual classification part) and it still processes a few firewall filter rules ... until it hits one of rules quoted above (how many filter rules that is depends on actual order of firewall filter rules, default config has the rule for chain=forward only 4th). I wonder if in some scenarios keeping full connection tracking with fast-tracking enabled doesn't actually give better performance.

I got reply from MK support:

Artūrs C.3
Hello,

Yes, that is how it works in RouterOS. Turning off firewall connection tracking will dynamically generate firewall RAW rules with "action=notrack" and all the new connections will bypass the connection tracking table. Fundamentally, connection tracking is not turned off to not interrupt previously established connections.

Best regards,

How do you all understand the last sentence? I really see no reason to keep connection tracking on for established connections. Even so, nothing changes when the last connection is timed out.

I like this security measure.

ROS v 7.2, setting connection tracking to off created the exact same Dynamic entries in the RAW table too...

Instantly or after reboot?

Instantly...

@Zacharias
thanks to the reply

viewtopic.php?t=185863#p932608

I tried few things. Any filter/nat/mangle rule will add two dynamic rules to RAW table. Any rule in raw table will not. If raw table contains any static rule, these dynamic rules go to the end.
Conntrack turned off in auto mode makes the same CPU saving as turning off via "no-track" raw rules (if any filter/nat/mangle rules are present).

CCR1036, 0 filter/nat rules, 10 mangle rules, 5 static raw rules, > 2000 simple queues, peak traffic > 1.7Gbps. Conntrack turned off 2022-05-12 03:00


CCR1036, 0 filter/nat/mangle/raw rules, 0 simple queues, peak traffic > 0.8Gbps. Conntrack turned off 2022-05-06 18:00