Interface Group turns out to be ^Rule Group^! Which is awesome !!

SteveITS

@louis2 There can’t really be a priority…packets are processed as they arrive on an interface. So they can’t arrive on LAN1 and then LAN2.

https://docs.netgate.com/pfsense/en/latest/interfaces/groups.html#group-rule-processing-order

I forgot they added that feature. Seems useful for say outgoing blocks from all networks, rather than copying the rule to each.

Bob.Dig

@SteveITS said in Interface Group turns out to be ^Rule Group^! Which is awesome !!:

There can’t really be a priority…packets are processed as they arrive on an interface.

He wants one interface in many groups.
I do that too but only use specific rules so that priority doesn't matter.

SteveITS

@Bob-Dig oh I read that backwards, no coffee

louis2

@Bob-Dig @SteveITS

Steve, of course packages are processed in order they arrive. But that was not what i meant. I meant the order the rules are processed!

Bob, Steve, I do object against the term interface, since since IMHO, the generated rules sets, have despite there name and what the GUI-suggests nothing to do with interfaces!!

It are just sets of rules which can be assigned to an interface, what is IMHO much much better!!

SteveITS

@louis2 Yeah Bob was right, I read it as you wanted to control the order within the group. Just disregard that part.

I get what you’re saying. Conceptually I’d think “rule group” would be more like a substitute…put Rule Group Web here, seventh in the list. An alias of rules if you will. Or I may still be low on coffee…

louis2

@SteveITS

Steve, I do not know if it is an alias like the other aliases. I doubt.
It is a set-of rules.

And within each set the order should be fixed.

But what I would like to control is NOT the order of the rules, but the order of the groups!!

Bob.Dig

@louis2 The firewall rules are maintained per interface and also there is a group of interfaces now, which in itself is correct, so I have to disagree with you.
Take a look at floating rules, maybe they can do what you want. But your usecase seems very special to me.

louis2

@Bob-Dig

Bob,

I have been thinking for years that interface groups are interface groups! But they are definitively NOT!

I discovered that by incident and are very happy with it. But just try for your self.

Define some interfaces and some groups. And notice that:

you can define (interface) groups completely independent from interfaces and
that you can assign multiple interface groups to one interface

And, I did test it! And up to now it all seems to work !!

I did a couple of tests:

I did start and end the interface groups with a rule having a recognizable dummy port
I did the same for NAT-rules, floating rules and the rules of a real interface
than I made a rule dump using pfctl -vvsr
And noticed that the generated rules where as expected

Than I used blocking and passing pings to a certain address to do some real filter testing. Also there the passing an blocking was as expected

And I did split a big rule set in two sets/groups

first set containing rules related to standard users
a second set containing additional rules for admin

Than I defined

a vlan for users having the first set / member of the first set and
a vlan for admins member of both sets
That also worked as expected

In fact I did create two user vlans and two admin vlans for redundancy purpose.
I also intend to use the first set for my guest network as well.

In general working with rule sets would make it much easier and less fault prone to maintain the firewll.

JeGr

@louis2 said in Interface Group turns out to be ^Rule Group^! Which is awesome !!:

Related to the rule group processing:
My actual impression is that the group you defined first in history is processed first,
than the second one
etc
So, I have one big wish , adding a priority field to a ^rule-Group^, which would allow me to determine the order in which the groups are processed.

Nope, we worked through the processing order in one of our workshops and the processing order is an alphabetically sorted.

So as an example you create 3 groups in that order:

Group
ZGroup
AGroup

and define a rule in every group, then the processing order would be:

AGroup rule
Group rule
ZGroup rule

If you need to check it, don't fret, you can. Go to Diagnostics / Command Prompt and enter the following command (or do it via SSH in a shell):

cat /tmp/rules.debug

Then check for the anchor "userrules/*" and have a look at the lines after it. There should be a floating rules first (if any, don't recommend using them) and Group rules after, then after those you should see the first rules from your actual interface tabs.
In our example case, it'll look like this:

anchor "userrules/*"
pass  in  quick  on $AGroup inet proto ah  from x.x.x.x to y.y.y.y ridentifier 1707311717 keep state label "USER_RULE: Test 3" label "id:1707311717"
pass  in  quick  on $Group inet proto ah  from x.x.x.x to y.y.y.y ridentifier 1707311699 keep state label "USER_RULE: Test 1" label "id:1707311699"
pass  in  quick  on $ZGroup inet proto ah  from x.x.x.x to y.y.y.y ridentifier 1707311708 keep state label "USER_RULE: Test 2" label "id:1707311708"

As you can see the second rule was created first, then the last one and the first rule and group were actually created last but got in front because of alphabetical sorting order.

Otherwise the processing order is "Floating", "Groups" (and yes, IPsec, OpenVPN and Wireguard Tabs are Groups, too! Especially if you have defined multiple OVPN servers that's important!) and Interface rules.

A word of warning though: Don't assign WAN interfaces to an interface group like that. You are actually removing features that may or may not be needed in your use case from the ruleset in that case (as the PF reply-to feature can't be added to groups)!!

Cheers
\jens

louis2

@JeGr

Thanks,

I regard rule groups really as very very handy!

and I had hoped for more and more positive responces ....
and a formal statement from Netgate that it was OK to look at this as ^rule groups^
IMHO it are really rulegroups are NOT interface groups!

I have been considering to split rules in favor of an interfface like this:

floating
01_<somename> highest prio, reserves for interface specific interface starting rules
(to be executed before more generic rule groups)
02_<next prio> relevant for a couple of interfaces
03_<next_prio> idem
04_<next_pro> idem
05_ etc where 5 prio's will probably more than enough
final interface specific rules defnied at fw-rules as related to the interface itself

JeGr

@louis2 said in Interface Group turns out to be ^Rule Group^! Which is awesome !!:

@JeGr

Thanks,

I regard rule groups really as very very handy!

and I had hoped for more and more positive responces ....

and a formal statement from Netgate that it was OK to look at this as ^rule groups^
IMHO it are really rulegroups are NOT interface groups!

Your differentiation is only artificial. There is no difference - it's only wording. An interface group is a group, spanning multiple interfaces. That's it. This group can be used - like any interface - as a place to put in rules.
pfSense already has multiple interface groups, even when people aren't calling them like that. OpenVPN, IPsec or Wireguard already function in exactly the same way. You put rules on your OpenVPN interface group? Then those are working for ALL OpenVPN server/client interfaces. That's why not using "any" as source on OpenVPN rules is important so you don't accidentally grant access to all servers when you don't (as an example). The same goes for the IPsec group, that spans virtually every VPN tunnel you define with IPsec, thus combining the rulesets for all of them.

Manually crafted Interface groups work the same way. You create them and they are entered and used in the pf ruleset like another interface:

#System aliases

loopback = "{ lo0 }"
WAN1 = "{ ix3 }"
table <WAN__NETWORK> persist { 192.168.178.0/24 }
WAN__NETWORK = "<WAN__NETWORK>"
L1_MGMT = "{ igc0 }"
table <LAN__NETWORK> persist { 192.168.1.0/24 }
LAN__NETWORK = "<LAN__NETWORK>"
WAN2 = "{ ix3.997 }"
table <OPT1__NETWORK> persist { 192.168.177.0/24 }
OPT1__NETWORK = "<OPT1__NETWORK>"
V123 = "{ igc0.123 }"
table <OPT2__NETWORK> persist { 10.0.123.0/24 }
OPT2__NETWORK = "<OPT2__NETWORK>"
V100 = "{ igc0.100 }"
table <OPT3__NETWORK> persist { 10.0.100.0/24 }
OPT3__NETWORK = "<OPT3__NETWORK>"
OpenVPN = "{ openvpn }"
GroupABC = "{ GroupABC }"
table <GROUPABC__NETWORK> persist { 10.0.123.1/24 10.0.100.1/24 }
GROUPABC__NETWORK = "<GROUPABC__NETWORK>"

In the above example we have a 6100 demo box with WAN1 being a 192.168.178 network, LAN/MGMT being the pfSense default 192.168.1.1, a second WAN configured as a VLAN on top of WAN1's ix3 interface (just as an example) as OPT1 in 192.168.177.x space. Then we have OPT2&OPT3, 2 VLANs that simulate simple LANs. Both in the 10.x address range, running on igc0 (LAN1 port). And finally we create an interface group "GroupABC" that spans both VLANs as can be seen in the table definition. So no surprise and no special sauce. Just don't simply use it on WANs but that info is already in the tooltip below "Group Members" when you set the groups up. Don't use it on WANs and believe it to work in any circumstance as it removes the "reply-to" parameter from the rules.

I have been considering to split rules in favor of an interface like this:

floating
01_<somename> highest prio, reserves for interface specific interface starting rules
(to be executed before more generic rule groups)
02_<next prio> relevant for a couple of interfaces
03_<next_prio> idem
04_<next_pro> idem
05_ etc where 5 prio's will probably more than enough
final interface specific rules defnied at fw-rules as related to the interface itself

Floating I'd avoid entirely or only use in very specific special cases (e.g. outbound reject rule for RFC1918 traffic, it's the only way to create outbound rules). Besides too many groups will be contra-productive and take away transparency as to WHAT actually runs on what interface. If you stack groups that way you won't grasp easily what rules are matching on an interface at all. That would be way too much hassle in case of debugging as to where exactly a certain pass or block comes from. That can be working if you're the alone master of your box and understand the system and immediatly know, which IF is in which group. But I've seen such constructs or things too much in support cases, where they were introduced meaning good and creating a great big ruleset but after the initial setup and the person it created was gone, and little to no documentation left, no one had a grasp as to WHY it is working in the first place and WHERE to enter WHAT to make new things work.

Adding groups after groups of interfaces and even using interfaces in multiple groups - for me personally - spells disaster in the making with a capital D, as the first time someone tries to understand why a specific thing is working instead of it being blocked, the time to look for the right rule will be tedious.

Also don't forget, that you will be severly limited in using REJECT or BLOCKs in those groups. As the ruleset is top-down-first-match (pf's quick keyword) if you block or reject something in Group 1, you don't get a second chance to allow it in Group 3 or 4 or even at the interface level as the rule parser won't go on. So you have stacked 5 groups above the interface (in your example) you have 5 chances to make a rule (mis)behave until it reaches the interface itself and finally can parse the rules there. That's way too much lack of transparency for me. It's similar to Alias and Alias Groups (e.g. stacking Aliases into Aliases). One level is absolutely fine, as you can see it in the tooltip. Stacking an already grouped Alias into another one starts to actually hide information about the content of an alias. And more often then not we've seen exactly such constructs exploding in real life constructs as people used those for their name only (hey, that's the one with those Exchange servers in it) and adding stuff to it but completely ignoring, that another Alias is using that one to group/add another and another host/alias to it "for simplification of the ruleset" but in the end, these Alias groups had hosts in them that weren't even meant to be included just by being so opaque that no one had the overwatch as to what exactly was inside.

Perhaps it's just me, but personally I'm seeing exactly that with stacking and using too many interface groups or even using the same interface in multiple ones. It's a great tool for e.g. adding a couple of infrastructure rules to multiple interfaces that would get the exact same rules. Like all client VLANs getting a "pass" rule for DNS, NTP, access to an internal proxy or multiple server networks getting access to the same, DNS, NTP, a package cache/proxy, internal resources, deployment, monitoring access - without needing them to be declared multiple times. Just add another interface to the group and BAM, that interface immediatly has internal access to those hosts. We're also using it for that.

But adding multiple layers or multiple use of the same interface seems at least problematic to me. But I'm curious to read what you'll make of it :) Just wanting to get out feedback to you.

Cheers

louis2

@JeGr

Thanks for your extensive replay !!

I will give some reactions here and perhaps more in the future. Lots of things in your replay :)

Your differentiation is only artificial. There is no difference - it's only wording.
Yep I largely agree to that, however IMHO very important wording. It are rule groups, not interface groups!

That's why not using "any" as source on OpenVPN rules is important
Generally speaking, a vlan whatever type, should block sources not belonging to the vlan itself. So every interface should start with a yes or no hidden rule. Block if source not me!
I did add a rules like that in the past "block if source not my subnet" (I hope that works also for IPV6). And I am not sure if that rule is there as hidden rule

Manually crafted Interface groups work the same way. You create them and they are entered and used in the pf ruleset like another interface
This feels like defining rules in aliases. I do not yet understand. Have to study this

Floating I'd avoid entirely or only use in very specific special cases (e.g. outbound reject rule for RFC1918 traffic, it's the only way to create outbound rules).
Let me start saying that the way firewalls work are more or less the opposite from what IMHO should be. Let met compare with a house. It is the house owner who decides who is allowed to enter the home. It is are not the neighbors who decide that they are allowed to enter my house (VLAN/INTERFACE). So from that perspective it is very strange that interface rules are defining who is allowed to leave the vlan and not who is allowed to enter the vlan !!

To put it in other words, rules defining who is allowed to enter the interface, do IMHO belong with that interface and not belong to a special group like floating!

Having said that, I am using float for multiple reasons:

to block incoming traffic towards e.g. my green zone
to make sure that certain blockings are there and are processed first (quick)
for performance reasons, placing peformance critical rules, related to file transfers there. Since floating is processed first and the less rules to process is more performance.
I tend to use floating more and more to accomplish this!

much hassle in case of debugging as to where exactly a certain pass or block comes from
Yep an no. off course, I enable logging where necessary.
However, in general, my feeling is exactly opposite! In a lot of situations vlans need largely the same rule set. And if that is really one set of rules, that set of rules is much easier to maintain and to correct, than to maintain the equivalent of all those rules at the different vlan's!! If I make a change in the group, it is automatically there for all interfaces using the group.
What should be nice / should help, is if rules could be defined using
^my-subnet^ and "my-address" in opposite of "vlan-x-subnet^ and ^vlan-x-address^

Also don't forget, that you will be severly limited in using REJECT or BLOCKs in those groups. As the ruleset is top-down-first-match (pf's quick keyword) if you block or reject something in Group 1, you don't get a second chance to allow it in Group 3 or 4
This is complex, perhaps I will come back on this one later on. But for now a short reaction.

Up to now, I always assume that rules are processed in the same order as they are visible (apart from floating first etc). At this moment I do not yet policy based routing. Related to floating rules, I always use quick

In general was surprised with my new finding. And I did some testing verifying that my suspect was correct. I did not yet do testing to verify the order in which rule-sets are processed, which is important.

So at this moment, I do not yet use the rule-set options as I see them to there full extend. But I use them all ready. Examples:

a vlan available on the 1G network and the 10G-network being there with the same reason
the guest network and the private network having more ore less the same rule set
websites each having there own vlan, but are further more or less the same

As said still playing around with the ^new^ possibility