Time based firewall rules stay inactive

RouterOS General
1

In order to ensure some gamer kid will get some sleep I have employed a couple of time based FW rules:

/ip firewall filter
add action=drop chain=forward comment="Drop 0000-0730 all days" in-interface=\
    ether2 log=yes log-prefix="DROP 0000-0800 ALL DAYS" time=\
    0s-8h,sun,mon,tue,wed,thu,fri,sat
# inactive time
add action=drop chain=forward comment="Drop 2200-0000 mon-thu and sun" \
    in-interface=ether2 log=yes log-prefix="DROP 2200-0000 MON-THU+SUN" time=\
    22h-23h59m59s,sun,mon,tue,wed,thu

Problem is that the rules stay disabled, i.e red even when the time enters the specified ranges.

Have tried manual clock/time zone and let the clock roll over 2200, but the rule stays disabled.
Disabling/enabling a rule that should be employed for the current time enables the rule.
The same does any editing of the rule parameters/comment.

First I was at bugfix 6.32.3, now I have upgraded to current 6.34.2, still same result.

Anyone?

2

Did you add them via webfig, winbox or CLI?

Does any warning appears near those rules if you perform a

/ip firewall filter print
3

Still the same here too…
Applied the following for another customer:

/ip firewall filter
add action=drop chain=forward comment="Drop 0000-0800 all days" dst-address=\
    !*.*.86.2 in-interface=ether1 log=yes log-prefix=\
    "DROP 0000-0800 ALL DAYS" src-address=!192.168.2.99 time=\
    0s-8h,sun,mon,tue,wed,thu,fri,sat

(Couple of IP address exceptions (first one camouflaged here) to allow for admin internally and externally even when active)
This rule ought to be applied at midnight, but last night I sat watching as the time moved from 23:59:59 to 00:00:00, and it remained red (inactive)
Doing any modification to the rule (even hitting apply without changing) or disabling/enabling it will employ the rule.
So what’s wrong with this feature? I’m even on 6.34.6…

4

Is ether1 part of a switch group? If yes, is ether1 the master-port?

5

No, standalone ethernet, no switch, no bridge.

6

Try to export this rule from CLI, remove it and then reinsert it from CLI.
Strange but IMHO sometimes ROS “caches” internal information and do not activate rules properly

Edit:
Try to disable it with Winbox … wait for some time and reenable … same issue … “cache”.

7

Tried to export, remove and add via CLI, no use.
Looks like at any time the rule should be employed - but isn’t, it comes into effect by disabling/enabling it.

For a workaround I added a script that is scheduled to run every 5 minutes.
It iterates through the rules, and for every rule that is enabled, it is disabled and then enabled.
(I want to keep disabled rules without fooling with them)

This does the trick, although a little dirty:

/ip firewall filter
add action=drop chain=forward comment="Drop 0000-0800 all days" dst-address=\
    !*.*.86.2 in-interface=ether1 log=yes log-prefix=\
    "DROP 0000-0800 ALL DAYS" src-address=!192.168.2.99 time=\
    0s-8h,sun,mon,tue,wed,thu,fri,sat
add action=drop chain=forward comment="Drop 2200-0000 mon-thu and sun" \
    disabled=yes dst-address=!*.*.86.2 in-interface=ether1 log=yes \
    log-prefix="DROP 2200-0000 MON-THU+SUN" src-address=!192.168.2.99 time=\
    22h-23h59m59s,sun,mon,tue,wed,thu

/system scheduler
add interval=5m name=schedule1 on-event=refreshtimerules policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=\
    jun/21/2016 start-time=07:30:00

/system script
add name=refreshtimerules owner=admin policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":foreach \
    rule in=[ /ip firewall filter find disabled=no ] do={ \r\
    \n  :log info \"Disabling / enabling time based firewall rules\"\r\
    \n  /ip firewall filter disable \$rule \r\
    \n  :delay 1\r\
    \n  /ip firewall filter enable \$rule \r\
    \n}\r\
    \n"

It would be even better if I could do this only to rules that are rendered “inactive”.
Anyone that knows how to script this?

To be very picky, the ultimate solution would be to do a check whether the rule “ought” to be active and compare this to the current “active/inactive” status, but this would require parsing of the “time” parameter and a lot of fiddling around, so I didn’t try that.

And- either way, this should be taken care of in RouterOS…
Mikrotik/Normis: any idea why this bug is still around? :open_mouth:

8

Interesting. Have you tried it to see if it’s working correctly or not doing anything? How are you monitoring the activity? I just tried a TOD based rule on one of my RB750s and it worked perfectly. The rule was as follows:
chain=ICMP action=drop protocol=icmp time=12h29m-12h30m,tue log=no log-prefix=“”

This was created using WinBox and I watched the filter rules as the time went by, again using WinBox. Separately I had a continuous ping to the router IP in a Windows command prompt window. WinBox showed the rule in red with a note of — inactive time. When the start of the 1 minute window came, the inactive time line disappeared and the rule became black. The ping window started showing ping failures, and WinBox showed the number of packets that met the rule parameters started counting up. One minute later the rule went back to red with the — inactive time line added, and the pings started replying again.
I then changed the times, and this time disabled the rule. As expected, WinBox showed the rule disabled (greyed out). The pings continued correctly. About 20 seconds into the time window, I enabled the rule via WinBox and the ping packets started failing. At the end of the rule time window, the rule went back to red with the — inactive line and the pings started working correctly. That was exactly how I expected it to work (I’ve never done a TOD based rule before).

9

Unfortunately, this bug is still around…
Now on 6.34.6, I have a few time based rules for another customer, and when time reaches the time window that one of the rules should block, the rule stays red instead of being employed.
Any chance that this can be fixed soon?

10

To my surprise this bug was still around in 6.37.5, but after upgrading to 6.38.7 it finally works as expected :slight_smile:
Strange that such a bug remains unsolved for so long :open_mouth:
Either way, thank you MT! :smiley: