@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
