i have 2 rules like this to protect management ports (ros management ports, as well as for other dst-nat ports for devices on network).

/ip firewall filter
add action=drop chain=input in-interface=ether1-ISP dst-port=20-55,80-445,2000,8022-8729 protocol=tcp src-address-list=!adminPublicIPs
/ip firewall filter
add action=drop chain=input in-interface=ether1-ISP dst-port=53,161,2000,8291-8729 protocol=udp src-address-list=!adminPublicIPs

2x questions:
1- would it be more efficient (less router resource usage) if i were to add "connection-state=new" to these 2x rules?
2- if i did add "connection-state=new" , are there any downsides or traffic that might be missed versus NOT having "connection-state=new" ?

thanks

If it's in the same filter, I don't think that one more matcher (new) will make a difference. And I don't think you'll miss anything with that. If you want to use it, maybe do new AND invalid in the same filter.

What I would suggest is to allow what needs to be allowed such as "related-established" (input + forward) and drop the rest (same chains). Then you won't need to bother with connection states anymore.

Again, just make sure you allow what you want to come in, such as DNS REPLIES (don't laugh, I've made that stupid mistake in the beginning) and NTP. I also allow echo replies (Established) since I want the pongs to my pings to be accepted. If you have VPNs, that too. Lig ang Drop the rest.

For the most is basic firewalls, it's not that complicated. It gets worst when you add services.

Cheers

Sent from my tablet with Tapatalk. Sorry for my typos.

Assuming that RouterOS has some inteligent way how to check multiple conditions, i.e. that it does simple checks first, then connection state should probably become the first condition checked, if you'd add it. Connection tracking happens anyway and the check alone is just looking for some flag. So yes, I'd expect it to be a little more efficient. But not a major difference, unless almost all packets go to these ports.

But I think even better is the usual:

rule #1: accept established & related & untracked (takes care of most packets)
rule #2: drop invalid
rule #3-x: <everything here is new connection>

Thanks for the replies and inputs, I do realize the pros/cons of how im doing FW vs the more standard (even default-config) of add rules to accept what you want, then DROP ALL ELSE.

In regards to my main question of performance / efficiency, my idea/theory was that in using connection-state=new , the firewall rule would match (or "be processed") for many fewer packets which would = less router resource load. In thinking about it more, I came up with a rough way to test my question/"the performance" impact:

by doing the "opposite" of each possible rule (ie using 2x action=passthrough rules , one with connection-state=new , the other without any connection-state set), and then seeing how each packet/byes couter increments, i can get a rough idea of how often connection-state=new is being matched VS no connection-state set , in general

(part of my theory is the more often a rule's "bytes" or "packets" increments , the greater CPU or other load it is placing upon the router/rOS - thus as im solely protecting management ports with these specific drop rules, connection-state=new should match less, which = less resource load, while still protecting management ports just as well as using no connection-state set ).

When i tested this (one rule at a time, for 30 seconds)- ofcourse the no connection-state set action=passthrough rule had ALOT more traffic than the no connection-state=new. But the difference was pretty large!

for 30s (in-interface=my ISP modem, chain=input, src-address-list=!myApprovedPubIPs proto=tcp) :
no connection-state set = 838 packets / 121k
connection-state=new = 42 packets / 3k

(of course this will vary for different people, and my premise may be entirely incorrect if im wrong about: the more often a rule's "bytes" or "packets" increments , the greater CPU or other load it is placing upon the router/rOS)

It would be interesting to know, what were those not new packets in your test. Because if you're testing with WAN interface and you don't really allow any connections from internet to router, then aside from few invalid packets, everything else coming from there can be only new. Also e.g. some icmp packets can be related, but your rule is only for tcp. Scratch that, you don't block everything, and there could be also some connections to internet initiated by router.

Generally you're right, the less processing, the better. And I'd expect connection-state=new to be checked before other conditions, so it could help (although with two rules, I don't think there will be any measurable difference).

What I don't understand is what you have against the usual way (first accept established, etc...), since the connection tracking (the heavy part which gives you connection state) happens anyway, so you won't save anything there.

.... I also allow echo replies (Established) since I want the pongs to my pings to be accepted. If you have VPNs, that too. Lig ang Drop the rest.
...

I will also add ICMP Type 3, Code 4 for path MTU discovery to work properly

I will also add ICMP Type 3, Code 4 for path MTU discovery to work properly

This should be covered by action=accept connection-state=established,related rule if it exists. So once he adds that "permit icmp type 3, code 4" rule as a separate one, he wrecks the whole idea he coins, to have the "new" packets handled first.

As @Sob has already written, nothing can beat, in terms of performance, having "accept connection-state=established,related" as the first rule in the chain. Because that way, most of the traffic will only make it to this rule, and only a few packets (garbage, connection-state=invalid, and initial packets of new connections, connection-state=new) will get past it for a detailed analysis.

If you skip connection tracking, you save a lot of CPU but you lose a lot of useful attributes of the packets - namely, connection-state and connection-nat-state. And you lose fasttracking, which helps a lot on weak hardware (for the price of losing some other features).