In firewall rules there are options in-interface and out-interface allowing user to specify which interface rule applies to. It also allows negation on specified interface which means rule applies to all interface but one specified.

Problem arises when there are several interfaces on board but rule has to apply to selection of them (two or more). For example, there may be several wan and several lan interfaces and there is need to handle only all lan or only all wan interfaces (or anything but lan interfaces, or anything but wan interfaces).

There is no option to handle such situation with single rule, so user must create several rules to handle this. It is ok when there is one or two rules, but if there is whole system of rules that should be applied things become messy.

I would suggest for Mikrotik developers to allow setting list of interfaces for in-interface and out-interface.

I like this request.

Though an acceptable workaround would be to make a custom chain that does all the actual filtering, and then you can jump into it based on multiple rules referring to in- and out-interfaces. That way at least the actual logic isn't repeated.

I can imagine that it would be helpful to be able to have more flexibility in selecting from a list of interfaces but I don't think I would solve your stated issue that way even if it were able to be done...

Instead I would handle this situation by putting this "whole system of rules" in a separate chain. This would help in that I would not have to specify the interface and duplicate the rule for each and every interface involved under the current situation but it would also be better in that the rules would be easier to read through if the complex sets of rules were extracted into chains that are single purpose.

For example, assuming I wanted to block TCP ports 445, 135-139, 1433, 3389, 5800, & 5900 on ether0 and ether1 because they were my WAN interfaces I would do the following:

In the forward chain I might have rules like:
if the in-interface = "ether0" action: jump to chain: "WAN_Port_Drops"
if the in-interface = "ether1" action: jump to chain: "WAN_Port_Drops"

then in the WAN_Port_Drops chain I might have
if the protocol is TCP and the port is 445 action: drop
if the protocol is TCP and the port is 135-139 action: drop
if the protocol is TCP and the port is 1433 action: drop
if the protocol is TCP and the port is 3389 action: drop
if the protocol is TCP and the port is 5800 action: drop
if the protocol is TCP and the port is 5900 action: drop
then return from the WAN_Port_Drops chain to the forward chain for good measure

This example is 9 rules (including the return) rather then 12... the more complex and numerous the rule sets the more reduction of rules and simplification through abstracting complexities is achieved by using chains this way. I admit this is not a "complex" example but I think it makes my point.

That would help in some scenarios, but not all. Making chains each time you need some list of interfaces also becomes messy.

For example, what if you have to set rule to list of interfaces in both in-interface and out-interface? That would be chains of chains.

jumping between chains (action=jump) costs almost nothing. It could inflate overall count of rules, but in the end, packets could be jumping though less rules in the end. It does not matter how many rules you have, only thing that matters is how many of them is reached by packets.

Of course it matters how many rules are in configuration. It relates to readability and ease of maintenance.

We are not talking about two or three more rules, but about doubling number of rules with each new interface. it could be avoided of rules accept lists of interfaces.

I was not once in situation that I decided to split job to two routers in chain just to avoid having multiple lan and multiple wan interfaces on single router.

Actually golden rule of avoiding mess is 1:N rule which says: never have more than one lan interface against several wan in one router and vice versa.

do not mix 2 different things - number of rules in firewall in total and number of rules that packets has to pass through.

jump rules usually are quite simple, and thus, adds little to overhead, you can try to create 100 jump rules and then check how much that increases latency for packets passing through just jump rules.

But we will think about it.

But we will think about it.

let's call it 'usability' and mark with 'must-have' tag =)

as long as the addition / change to the existing code doesn't make things more latent even when using a single interface (as before)...

janisk, I am talking about user experience and usability.