Multiple connection states in one rule is recent feature in RouterOS (less than a year old), so the examples are either older or their authors did not notice the new feature yet. Or they may like to have separate counters.
If you know that the packet is invalid, why not drop it right away? There’s no point in letting it try to be matched by several other rules before you finally drop it. Ok, it’s just one rule in this case, but you will probably add more with most configs.
I know multiple matches in connection state is a recent 6.x feature. I’ts a great feature, so why not document it so more users can benefit from it!
The fewer rules you need in your firewall, the better performance. And I don’t see why the invalid packet path shall be optimised by dropping it as early as possible? Why not optimise the valid packet path so the router doesn’t have to traverse all firewall rules for the normal use case.
If you don’t drop them at the beginning, they can be matched by later rules (like your accept with in-interface=inside) and allowed. Do it in forward chain and then you can wonder about things like this.
I really don’t see any problem with drop invalid rule at the beginning (after established & related). Sure, it looks like an unnecessary extra rule, because most packets won’t be invalid. On the other hand, the vast majority of packets will be matched by first established & related rule and accepted, so they won’t get this far. The rest are either new or invalid and even though there will be much more new than invalid, I doubt that one simple rule like this could make any noticeable difference. Not that you have too many options how to do it differently (and efficiently at the same time). Right now I can think of only one (probably) slightly more efficient solution (assuming there would be more than one rule for new connections and you wouldn’t ever want to accept an invalid packet) and that’s making the second rule:
Interesting thread there about connection-state invalid and packets not being NAT:ed correctly. Would be very interesting to fully understand why the invalid connection state appears though. Do you think it is necessary to drop invalid connection states both in the input chain and the forward chain (I noticed the thread also put a drop rule in the output chain)?
Under usual circumstances, most invalid packets seem to be caused by expired or otherwise broken connections. Some look like they are resent for some reason. I tried to watch it for a while and break things intentionally in a limited way, but I would lie if I said that I know all about it, far from that.
I drop invalid packets in both forward and input chains. If it was just a little inconvenience, like occasional internal address leaking out, in most cases I wouldn’t care too much. But I’m thinking that some of those invalid packets might be actually something bad. Some nmap scans supposedly produce packets seen by iptables as invalid. Perhaps there might be something even worse, I don’t know. I don’t expect it to catch everything either, but at least something.
Dropping invalid in output chain seems unnecessary, I don’t expect there will be anything there. But don’t take my word for it.