I would expect that rule 20 (ACCEPT) should have FULL counters for this connection, but in fact it does not (it only shows tiny amount). Only fastrack counters are correct
Also: when a connection is fasttracked, it no longer hits any of firewall filter rules, not even the rule 16 (hence the “dummy rule” with index #0). Which means both that your “restrict-by-time-2” chan rules will not break already on going connection (and that none of counters will increment).
Simply, if you do not select anything on connection-state, the rule is valid when the connection-state does not exist…
At test select one connection-state, or remove the empty connection-state…
also the same for connection-nat-state.
Your #20 rue have both: connection-state=“” connection-nat-state=“”
P.S.: do not do print, but export, and the full list, the jump is not visible…
The fast track rule works on connections, not on machines. And the way rule is done it fasttracks all connections after they enter “established” state (for TCP connections that’s after initial 3-way handshake successfully completes, for UDP connection state is faked anyways). And then all packets, belonging to fasttracked connections, bypass most of processing. If there was no fasttrack, all packets would be checked by firewall filter rules and then it would be possible to break ongoing connections.
The dummy rule is, as comment says, dummy. So it doesn’t affect the packet flow, it’s there only to show fasttrack counters. This rule is automatically put on the list of rules if there’s a fasttrack rule active in the firewall filter rule list. And as I explained in paragraph above, packets, belonging to fasttracked connections, bypass all of firewall filter rules (including the fasttrack rule itself), so it seems that the only way of displaying some statistics in firewall section (consistent with displaying statistics of other rules) was introduction of this dummy rule.
Probably was added in some past version, I was using filter rules since before it existed..
Anyway, not very exciting - http://forum.mikrotik.com/t/tool-kid-control/115151/1
I just would like the normal rule to display the counters correctly…
What I wanted to say is: if machine starts a connection at 22:30, then that connection will successfully establish … and will not break at 22:31.
However, if machine starts a new connection at 22:31, then the new connection will not get established.
And none of this depends on when machine gets powered on.
E.g. if you open a web browser, go to google (browser opens a few parallel connections to google), search for something and click on search result (which directs to a different site), then browser opens new connections. According to firewall rules, first few packets of those connections will pass the whole firewall filter setup (and might get dropped, depending on filter rules), but if connection is allowed to establish, the rest of packets will bypass firewall processing and none of rules which might be triggered by subsequent packets (e.g. due to time constraints) will ever apply.
If the machine starts connection only at ie 15:00 then it is in Allowed timeframe and to my logic: that should be the rule that carries on being used for this access (and the counters should be correct)
Up to 15:00 there are NO connections Related to this machine), so no counters moving
But once the machine is up & connections start happening, I would expect the very rule to keep the counters (and not some other [dummy] rule etc)
and none of rules which might be triggered by subsequent packets (e.g. due to time constraints) will ever apply.
That makes no sense & it would make total mockery of the firewall, what would be the point of having the rules in first place? Just to act on few first packets?4
Ofcourse if I wanted to process other rules ralated to the very machine, I would move them UP
My existing time rule works fine, just the counters do not reflect what is happening
I guess you want to block internet for MAC D8:5E:D3:5D:52:76 over wan interface pppoe-out1 in some time periods…
It is not needed to define time for period 24/7, that is default if period is not set. Also add here pppoe-out1 as out interface, you don’t need other packets in that chain, you can replace it with
last rule will handle accepts for forward chain, also you have flexibility to after add other rules in forward chain without need to modify restrict-by-time-2 chain when you return packets from that chain if above rules are not matched.
Also remove connection-state in time rules.
If you have already open connections in that period, they will not be blocked because of fastrack rule. This can be handled with scheduler script to close all connections for IP which is assigned to that MAC, but then if you use scheduler, you don’t need time based rules, you can enable/disable rules needed for blocking when scheduler triggers.
I’m telling you how fasttrack works (since you have it in firewall filter rule set). But since you don’t want to hear it (it seems that reality doesn’t fit your mental model), I’m outta here.
this is set in rule for packets to enter in chain, it should work enter even if
time=0s-23h59m,sun,mon,tue,wed,thu,fri,sat
is not set, because that period is 27/4 and it is unnecessary to set, but it works because it covers all periods, it is just not optimal (has additional unnecessary condition). And it is not default if you don’t expand in Winbox time in rule, I guess you mean default when you expand, in Winbox you need to be careful what you expanding in GUI, a lot of things can be set then.
In general, various combinations of rules can work, but are they optimal is a question and unoptimized rules can affect CPU and lower throughput.