Rule precedence between interface and group

[clarknova]

2.0-RC3

If interface A is a member of interface group 1, my last firewall rule on group 1 says "reject all from subnet A" and the first rule on interface 1 says "pass all from host A1", will traffic from host A1 get passed or rejected?

[Metu69salemi]

Rules work on ingress and top-to-down order.
first matching rule gives the order where the packet goes, if no suitable rules are found -> implicit deny

So answer in short: First rules pass everything and last denies, everything goes out. Unless subnets A and A1 differs some how.

[clarknova]

Your response is correct within the context of a single interface, but doesn't answer the question that I was trying to ask.

It is possible in 2.0 to create an interface group, composed of one or more interfaces on the firewall. This interface group then appears as its own interface in the firewall rules section, and rules can be created on that group. My question was what if I create a rule in an interface group, then a conflicting rule on an interface that is a member of the same group. Which rule will take precedence?

The answer, after limited experimentation, appears to be that the rule on the group page will take precedence over a conflicting rule on the page of a member interface.

[Metu69salemi]

What happens when group has no rule for something and interface itself has a rule, does pfsense work this cases in this order

1. Group rule check
2. Interface rule check

[stephenw10]

@clarknova:

The answer, after limited experimentation, appears to be that the rule on the group page will take precedence over a conflicting rule on the page of a member interface.

This would seem to make sense. If you applied a rule to a group and it could be overridden by an interface rule you would have to check all you interface rules to make sure it didn't happen. If you have a lot of interfaces, when groups are really useful, that would be a PITA!
This should be added to the wiki page.

Now, what about floating rules?  ;)

Steve

[jimp]

Would have been easier to look in /tmp/rules.debug to see the actual order of the rules :-)