Interface Groups: Firewall rule evaluation order

[helge000]

Hello,

I seem to have a problem or maybe an issue understanding the evaluation order of firewall rules for interface groups. My thought was I wanted to Reject rather than Block traffic on outbound interfaces and save myself some work and put these in the interface groups rather the the final 'catch all' rule on the each interface:

My Setup, simplified:
LAN1 Interface rule:

IPV4  LAN1 Subnet  *  *  *  *  none  Pass

Interface Group OutboundIF (LAN1 is Member):

IPV4  *  *  *  *  *  none  Reject

This setup is effectively rejecting all traffic on LAN1, but the pfSense 2.1 book states on p. 98:

The interfaces can still have their own individual rules, which are processed before the group rules.

This makes the most sense to me as well - but it rather seems to be the other way around (I only have some very specific pass rules on my interface group, these work fine).

Am I doing something wrong here?

Thanks a lot for some insight!
Helge

[phil.davis]

You are right - the interface group rule/s are listed first in /tmp/rules.debug
I just setup and interface group with a test pass rule and got this sort of order in /tmp/rules.debug

# User-defined rules follow

anchor "userrules/*"
pass  in  quick  on $MyIFs inet from 1.2.3.4 to 5.6.7.8 keep state  label "USER_RULE: Test interface group rule"
pass  in  quick  on $OpenVPN inet from $INT_subnets to $INT_subnets keep state  label "USER_RULE: Allow all between internal subnets"
then WAN rules...
and then LAN rules...
block return  in  quick  on $LAN inet from $LAN_DHCP_Pool to any  label "USER_RULE: Reject DHCP Pool"
block return  in  quick  on $LAN inet from any to $LAN_DHCP_Pool  label "USER_RULE: Reject DHCP Pool"
...

Because "quick" is on the rules, pf does "first to match wins".
Either the book is wrong, or the book is what was intended but the software implementation is wrong.

[helge000]

Hello  phil,

thanks for your effort!

I further read though the book - which is still draft by the way - and there is also a section titled 'Rule processing order' at p. 153:

1. Floating Rules
2. Interface Group Rules
3. Interface Rules

This describes the current behavior.

I still think since you have Floating rules as well it might be desirable to have Interface groups processed last. IMHO this is more real life; since I often cannot have very specific rules on interface groups as I need them to apply to all the interfaces. I then could create specific rules on interfaces to counter the interface group rule if needed.

[cmb]

Thanks for noticing, that was correct in the firewall chapter, typoed in interfaces. I fixed it in the source, will have an updated version up with that and other revisions in the next couple days.

[ErorZ]

Can someone confirm the issue I am having with the listed order ?

I've confirmed with other rules that the order does indeed seem to be as mentioned, Floating, Group, Interface…
However when adding the Block Bogon/Private addresses options, the rules are added to the Wan interface, which should be processed after my Quick Floating Rule, this does not seem to be the case, as the traffic is blocked even if my Quick Floating Rule says to allow a specific address.

Side question, which is processed first, snort or firewall rules ? I would guess it should be Firewall then Snort, but this does not seem to always be the case, more testing is required on my end once I get confirmation of which order these rules are processed.

Thanks.

[sealeg]

The interfaces can still have their own individual rules, which are processed before the group rules.

This makes the most sense to me as well - but it rather seems to be the other way around…

I agree. Admittedly I am quite new to pfsense (but not to firewalling in general) and possibly I am missing the point of interface groups. How I imagined using them was to contain generic rules that apply to many interfaces. e.g. outbound internet policy. Having interface specific rules (e.g. block traffic not from the connected subnet) on the interface tabs.

[phil.davis]

Yes, I think there are situations where you need to be able to choose, for each group rule, if it is applied before or after the individual interface rules.
e.g. you have LAN1 to LAN9, WAN1, WAN2, gateway group Balanced with WAN1 and WAN2 on Tier1. Interface group AllLANs with LAN1 to LAN9 in it. Alias InternalNets defined to cover all the internal private subnets of LAN1 to LAN9.

AllLANs interface group - pass source InternalNets destination InternalNets description "Pass all internal traffic between LANs"

LAN1 - pass source LAN1 destination any gateway WAN1 description "Force LAN1 traffic out WAN1"
LAN5 - pass source 10.20.30.42 destination any gateway WAN2 description "Force traffic from LAN5 10.20.30.42 client out WAN2"

AllLANs interface group - pass source InternalNets destination any gateway Balanced description "Pass everything else to load-balancing gateway group"

For this to work, you need an Interface Group rule before, and one after, the individual interface rules.
Of course, you can just put all the rules on the tab for the Interface Group and they can work just by matching on LAN1net, LAN5net… but that obfuscates the system a bit, and kind of defeats the point of being able to have both Interface Group and Interface rules that combine together.

[sealeg]

You have pretty much described my exact scenario.

As you say i am faced with the choice of duplicate rules on each interface or put all rules on the interface group.

The choice to specify whether a group rule is evaluated before or after interface rules would be the solution. I suppose it would not matter if it was done on a rule by rule or group by group basis.

[gexat]

Hi,

this has changed between 2.0 and 2.1.

@ 2.0 you had interfaces and then interface groups; to order the interface group you could use small and capital letters.

so, if you setuped group firewall rules and update to 2.1 you will run in problems.

For me the best solution would be to set a before or after interface rules value.