Yesterday I was experimenting with kid-control on my new RB5009 running ROS 7.8. I am somewhat familiar how kid-control worked on ROS 6.49, I used it for at least a year.

After setting up kid-control I realised there is a new firewall filter rule which just makes a jump to a new firewall chain kid-control. This kid-control firewall chain is where "a magic happens". Devices (their IP addresses) are added dynamically to kid-control chain and their traffic is either accepted or dropped. Those rules seem to be correct.

IMHO, the problem is with the first rule, which is added at the TOP of the firewall stack.

Firstly, there are no limits to this rule. At least it should be allowed just for established and related connections. This way every connection to the IP address of any device managed by kid-control is accepted regardless on other rules in the firewall stack.

Secondly, the last rule in kid-control firewall chain should be "return" in order to process the other firewall rules.

And, finally, it should be properly described in the documentation. The current documentation doesn't describe this new concept. (https://help.mikrotik.com/docs/display/ROS/Kid+Control)

I know, I can modify the first firewall rule (i.e. a jump to the kid-control chain). It seems to "survive" disabling and enabling the kid-control. But it should be advised to do that in docs, I guess.

Am I missing something?

I dunno. Hard to say.

The docs do say rules are an "example", so different reading is they show that you can use "print" to see the rules added - which you did and got the "specific" ones . And not having a return is same as setting passthrough=no on the last rule, but not having a return makes the code/script easier to add the rules internally I'd image. If it doesn't have more rules in that chain, why waste a line when the firewall has already tracked it at the point?

Imagine they make an underlying assumption you're using the default firewall for that device. So hard to know if you wouldn't want "new" on the kid-control rules. That part I'm not sure on.

Are they not working right? Did you already change the firewall from the defaults in other ways?

@Amm0 Thanks for your thoughts.

Of course, I do have working firewall which is based on default firewall (in both input and forward chains).

My problem with the implementation of kid-control as I understand it, is, that the jump rule (basically for every connection in forward chain) to kid-control chains is added at the top of the firewall stack. The rules just for IPs of kid-controlled devices are added to the very bottom of the firewall and the action for each IP is either accept or drop connection.

If I understand the firewall implementation right if the first rule makes a jump to the kid-control chain for EVERY connection which started in the forward chain and no firewall condition in kid-control chain (which is added to the bottom) is met then it just ends its "journey" thru the firewall. It means that no other rules in forward chain are considered. If the kid-control chain ended with the return command it would at least continued checking other firewall rules in forward chain. And another problem could be that there could be firewall rules even for IPs of kid-controlled devices which would prevent connection (say tls-host matcher for facebook connections).

I don't know, it doesn't seem to me to be correct way how to implement a kid-control via firewall. I guess the reject rule for IPs of kid-controlled devices for the "off" time seemed more appropriate.

I don't have it setup. But if you post your firewall, that help visualize the issue.

If I understand the firewall implementation right if the first rule makes a jump to the kid-control chain for EVERY connection which started in the forward chain and no firewall condition in kid-control chain (which is added to the bottom) is met then it just ends its "journey" thru the firewall. It means that no other rules in forward chain are considered.

Your explanation above is not correct. Ordering of different chains does not matter, only ordering of rules within same chain matters. There are 3 special chains: input, output and forward. These are used by ROS depending on packet traffic case. The rest of chains are custom and are only used if packet matches the jump rule. After that, packet is matched against rules in custom chain. If none of rules in custom chain matches, rule execution continues in original chain right after jump rule. (which BTW allows to use same rules for packet inspection regardless the original rule selected by ROS originally. Example: some FW admins like to block ICMP, but not everything is safe to block; so they create custom chain which selectively deals with ICMP packets and that chain is used from both input and forward chain for ICMP packets ... after ICMP chain is done, execution is returned to original chain, no mixups happen).

Meaning that it doesn't matter if kid control rules are below forward rules. Packets, which trigger jump rule (transfering execution to kid control chain) and don't match rules in kid control chain, will traverse the rest of forward chain starting the next rule after the jump rule. In essence, custom chains have implicit "return" at the end.