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.
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”)
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.
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…
What puzzles me most is that you say you can see this weird behaviour in two distinct RouterOS versions - I’ve just tried on CHR 6.48.6 and it behaves the way I am used to, where no means simply that connection tracking is completely off no matter what the firewall rules say, /ip firewall connection print shows no connections, and no rules are dynamically added to raw.
So unless someone more experienced on this forum has an answer, you’ll have to open a real ticket.
Yes to both - there are two NAT rules, and the connections table is empty after setting enabled to no. As soon as I put it back to auto, some connections reappear as the traffic keeps going. What happens under the hood is of course unclear to me, maybe the connections still exist in the table but are not shown, but even if so, no further packets should go via connection tracking so the connections should die off even if they stay in the table.
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.
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.
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:
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.