Let's talk firewall rule order ...

[Patrick M. Hausen]

OK, I just noticed a thing after upgrading to 26.1 and using the new rule interface. I suspect the issue was present in previous versions in the same manner, I just did not notice it.

So rule order watched from the highest level is:

Floating > Interface group > Interface

This is well documented and has not changed ever I could remember. And I use it more or less extensively to get a maintainable structure and a low number of rules.

Floating:



I really do think that blocking ICMP echo is silly, that it's the most important debug tool of all in IP, so I generally allow it, even when other traffic across the same interfaces is forbidden.

Interface groups:

I have one interface group "Internal" which is all my interfaces but WAN and the one to the DSL modems's management interface. I have another group named "Restricted" which is the same as "Internal" but without LAN. These are the interfaces for which I block any "cross talk". LAN after floating and groups applied has a final "allow all" rule just like the default setup.

These are the rules for the "Restricted" group:



This allows essential services to the respective firewall interface plus Internet access to arbitrary services but no access to any other local network. If you look closely you recognise that this set of rules does not yet prohibit e.g. SMTP out to the Internet. It's only "allow" rules, so the first three simply do not match and then the last two still allow DNS, NTP and SMTP outbound.

But I take care of that in the "Internal" group:



Since my LAN is generally "allow all" but I still want to restrict DNS, NTP and SMTP, the block rules for these go into the "Internal" group. Remember, that contains all "Restricted" interfaces plus LAN.

Result:

This works. I just verified by disabling all "Internal" rules - SMTP from a host on a restricted interface to the Internet is open. Enable again - SMTP blocked.

Fine.

My question is: why?

Why are the group rules for the "Internal" group applied before the rules for the "Restricted" group? As is obviously the case? And how can I guarantee a certain order of certain groups, because I want block before allow? Is it the metric system ... er ... alphabetical sorting?

Kind regards,
Patrick

[meyergru]

Made me laugh, Patrick, because I have exactly the same distinction between "internal" and "restricted" (this one even with the same name).

As for your question: Look under Firewall: Groups, the interface group have an assigned "sequence" which I believe to determine the order.

[Patrick M. Hausen]

Look under Firewall: Groups, the interface group have an assigned "sequence" which I believe to determine the order.

I never noticed this exists. Bummer! Thanks!

They are both set to 0 - so it's alphabetical or order of creation or whatever, but at least now I know how to force a specific order.

EDIT:

I could not find that in the docs - lowest number wins. All automatic groups (IPsec, OpenVPN, WireGuard) are set to 10 by default, all user created ones to 0.

If I set "Internal" to 1 and "Restricted" to 2, outbound SMTP is still blocked, if I change "Internal" to 3, it's allowed.

*phew* What a rabbit hole :-)

[meyergru]

*phew* What a rabbit hole :-)

I wonder what percentage of people can still follow what we are talking about here... ;-)

Yet, I had only the typical "Block RESTRICTED to local networks" and "Allow any to internet" rules in the RESTRICTED group, which I switched out for explicit interface rules at some point. Unless you have a large number of VLANs, it seemed more explicit that way to me.

[Seimus]

Indeed the sequence order in the groups sets the order of those group rules when inherited into an Interface.

And you are right its not mentioned in docs just slightly hinted in
https://docs.opnsense.org/manual/how-tos/security-zones.html#setup-interface-groups

I have several groups created, cause I look at them as policies, and policies are inherited into Interfaces (I look at them as Zones). So when you do groups its necessarily to consider the sequence order because of

groups use 300000

This means 300000 + the sequence number in groups

https://docs.opnsense.org/manual/how-tos/security-zones.html#setup-interface-groups

At least that was my interpretation when doing the design.

Regards,
S.

[opnessense]

In my  setup I combining interface groups as security zones (similar Internal/Restricted model) with a multi‑layer DNS stack (dnscrypt‑proxy on localhost, Unbound as validating resolver and AdGuard Home on a separate VLAN), and we've just added Q‑Feeds domain/IP feeds on top.


Being able to control the group rule order via the sequence field is exactly what we need to keep the "global block policies" applied before the more permissive per‑zone rules without exploding the number of interface rules.

Since the sequence field essentially controls policy precedence between interface groups, it might be worth surfacing this more clearly in the UI and docs.
For example, a short note or tooltip like "lower sequence = evaluated earlier (group rules are ordered by 300000 + sequence)" under Firewall → Groups would make it much easier for people using policy‑style groups (Internal/Restricted, IoT/Guest, etc.) to design their rulesets intentionally instead of discovering the behaviour by trial and error.