Page 1 of 1

Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 10:33 am
by sebus46
In my forward chain I have:
16    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related 

17    ;;; time restrictions upto 10;31 pm
      chain=restrict-by-time-2 action=reject reject-with=icmp-network-unreachable 
      time=22h31m-23h59m,sun,mon,tue,wed,thu,fri,sat 

19 I  ;;; Midnight to 6am
      ;;; inactive time
      chain=restrict-by-time-2 action=reject reject-with=icmp-network-unreachable 
      time=1s-6h,sun,mon,tue,wed,thu,fri,sat 

20    chain=restrict-by-time-2 action=accept connection-state="" connection-nat-state="" out-interface=pppoe-out1 log=no 
      log-prefix="--ts--"
      
21    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 
      log=no log-prefix=""
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

sebus

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 10:43 am
by rextended
Find the difference between these two rules and you will have the solution:
 /ip firewall filter> pri
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=forward action=log connection-state="" log=no log-prefix="" 

 1    chain=forward action=log log=no log-prefix="" 

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 11:29 am
by mkx
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).

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 2:47 pm
by sebus46
Well, the connection does not exist, the machine is OFF

It starts up from cold, so I do not see how it could become fastracked

And if dummy rule #0 takes presedence, then what is the point of any rules at all?

@rextended, the difference is connection-state="" (which is empty), so I must be stupid, but can not see the answer

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 2:50 pm
by rextended
@rextended, the difference is connection-state="" (which is empty), so I must be stupid, but can not see the answer
No, no, don't take offense at yourself.

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....

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 2:56 pm
by sebus46
Thanks, did not think that something with no value still has impact
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=jump chain=forward comment="--timerestr2--" \
    jump-target=restrict-by-time-2 log-prefix=--jump1-- src-mac-address=\
    D8:5E:D3:5D:52:76 time=0s-23h59m,sun,mon,tue,wed,thu,fri,sat
# inactive time
add action=reject chain=restrict-by-time-2 comment=22:31 reject-with=\
    icmp-network-unreachable time=22h31m-23h59m,sun,mon,tue,wed,thu,fri,sat
# inactive time
add action=reject chain=restrict-by-time-2 comment="Midnight to 6am" \
    reject-with=icmp-network-unreachable time=\
    1s-6h,sun,mon,tue,wed,thu,fri,sat
add action=accept chain=restrict-by-time-2 connection-state=\
    established,related,new log-prefix=--timerestr2-- out-interface=pppoe-out1
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 3:00 pm
by rextended
Thanks, did not think that something with no value still has impact
ignoring something is different from an empty list

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 3:10 pm
by mkx
Well, the connection does not exist, the machine is OFF

It starts up from cold, so I do not see how it could become fastracked

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.


And if dummy rule #0 takes presedence, then what is the point of any rules at all?

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.

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 3:15 pm
by rextended
I don't see the complete drawing, but for what you are doing there is already this...
https://wiki.mikrotik.com/wiki/Manual:Kid-control

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 3:59 pm
by sebus46
Probably was added in some past version, I was using filter rules since before it existed..
Anyway, not very exciting - viewtopic.php?t=129118
I just would like the normal rule to display the counters correctly...

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 4:59 pm
by sebus46
The fast track rule works on connections, not on machines.
But if machine is off, then the connection does not yet exists (to become fastracked)

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 5:45 pm
by mkx
The fast track rule works on connections, not on machines.
But if machine is off, then the connection does not yet exists (to become fastracked)

So I don't see how this is then relevant?

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.

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 7:01 pm
by sebus46
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

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 7:07 pm
by rextended
Look, you're speaking two different languages, you're not understanding each other...
One talks about pizza the other about pasta....

Re: Time restrictions forward rule and counters  [SOLVED]

Posted: Tue Jun 20, 2023 8:58 pm
by optio
Thanks, did not think that something with no value still has impact
I guess you want to block internet for MAC D8:5E:D3:5D:52:76 over wan interface pppoe-out1 in some time periods...
add action=jump chain=forward comment="--timerestr2--" \
    jump-target=restrict-by-time-2 log-prefix=--jump1-- src-mac-address=\
    D8:5E:D3:5D:52:76 time=0s-23h59m,sun,mon,tue,wed,thu,fri,sat
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
add action=jump chain=forward comment="--timerestr2--" \
    jump-target=restrict-by-time-2 log-prefix=--jump1-- src-mac-address=\
    D8:5E:D3:5D:52:76 out-interface=pppoe-out1
Replace also this rule
add action=accept chain=restrict-by-time-2 connection-state=\
    established,related,new log-prefix=--timerestr2-- out-interface=pppoe-out1
with
add action=return chain=restrict-by-time-2 log-prefix=--timerestr2--
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.

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 9:21 pm
by sebus46
Well, it is not 24/7, it is daily 22:31 till NEXT day 6am
time=0s-23h59m,sun,mon,tue,wed,thu,fri,sat is INDEED the default (not user specified!)

But as I said, I have NO ISSUE with the rule executing correctly, it is only counters that are not logically correct

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 9:34 pm
by mkx
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
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.

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 9:36 pm
by optio
Well, it is not 24/7, it is daily 22:31 till NEXT day 6am
That is checked in rules in chain
time=0s-23h59m,sun,mon,tue,wed,thu,fri,sat is INDEED the default (not user specified!)
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.

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 9:58 pm
by sebus46
Yes indeed, expand in WB makes is as selected, thanks!

In fact scheduler to turn single rule on or off is much cleaner/simpler way to do it! Thanks again

Still, how can I get correct counters for this (or any other) PC?

sebus

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 10:13 pm
by optio
Still, how can I get correct counters for this (or any other) PC?
Unless you disable fasttrack you can't, because packets when are marked for fasttrack they are no longer processed by firewall, see https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack

Re: Time restrictions forward rule and counters

Posted: Tue Jun 20, 2023 10:30 pm
by sebus46
Correct again. That was helpful: viewtopic.php?t=180035

I still cannot get my head around the counters, dummy rule shows xxx, forward fasttrack shows xx, forward accept est/related/untracked shows x
No matter how I want to add them, they do not equal, so lots goes through (on forward) that is simply not visible in any rules (I assume that is the last invisible allow rule?)

I do not have explicit drop all at the end of Forward section

But I suppose I am not the only one - viewtopic.php?t=179580 or viewtopic.php?t=107787

Re: Time restrictions forward rule and counters

Posted: Wed Jun 21, 2023 11:52 am
by sebus46
Still, how can I get correct counters for this (or any other) PC?
Unless you disable fasttrack you can't, because packets when are marked for fasttrack they are no longer processed by firewall, see https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
In fact if one inputs a dummy entry IP/Kid-control in User tab, then Device tab gets auto populated with dynamic entries, which state bytes UP & DOWN

So the data is there, just not displayed per firewall rule (as big chunks go via either fastrack or "allow est/related" or the invisible rule "allow all" (if there is no explicit deny)

So at least better than nothing