how to create floating (and group rules) after migrating to new firewall rules?

[Netlearn]

Please, read the release notes before upgrading. They are posted on a dedicated section of this forum and they are showed to the admin before upgrading, either by GUI or console.

26.1 release notes are from January 28, 2026.

The OP's post is from April 21, 2026.

Meanwhile, in Announcements...


From https://forum.opnsense.org/index.php?topic=50544.0:

o firewall: added a rule migration page (use with care)

Migration notes, known issues and limitations:

o The firewall migration page is not something you need to jump into right away.  Please make yourself familiar with the new rules GUI first and check the documentation for incompatibilities.  Single interface from the floating interface will not be considered "floating" in priorities.
o Firewall: NAT: Port Forwarding is now called "Destination NAT".  Firewall rule associations are no longer supported, but the old associated firewall rules remain in place with their last known configuration and can now be edited to suit future needs.
o Firewall: NAT: Source NAT is from the set of pages formerly known as automation, but Outbound NAT is still the main page for these types of rules.


From https://forum.opnsense.org/index.php?topic=50704.0:

We are very happy with the current state of the new rules GUI and all the
discussions we have had on how it can be further improved.  It is just the
beginning.

o firewall: validate UUID on rules migration import
o firewall: fix overload table setting being written as UUID into pf.conf in new rules GUI
o firewall: local-port field in destination NAT does not support range and well-known name
o firewall: change toggle_log icon to help visibility in new rules GUI
o firewall: add missing schedules support for new rules GUI
o firewall: make statistics column responsive for new rules GUI
o firewall: add link to states and put it first in list in new rules GUI
o firewall: add "any" interface filter option and make it the default


From https://forum.opnsense.org/index.php?topic=50868.0:

o firewall: use local-port as target when specified in destination NAT
o firewall: fix missing reply-to when not specifically set in new rules
o firewall: live view: fix parsing of combined filters stored as converted strings
o firewall: fix group rename in source_net, destination_net and SNAT/DNAT target fields
o firewall: add tcpflags_any in new rules GUI for parity with legacy rules
o firewall: exclude loopback from interface selectpicker in new rules GUI
o firewall: well known ports added to filter rule selection
o firewall: undefined is also "*" in new rules grid
o firewall: add download button for validation errors in rule import


From https://forum.opnsense.org/index.php?topic=51145.0:

o firewall: check for schedules in use in new rules
o firewall: add import/export function and missing lock on set action
o firewall: implement missing ICMP types in new rules GUI (contributed by Bjoern Jakobsen)
o firewall: adjust for parseReplace() for icmp-type "skip"
o firewall: fix NAT rule enabled checks display (contributed by Aaron Rogers)
o firewall: add validation to prevent using both gateway and reply-to in the same rule in new GUI
o firewall: add a command button to open the live log with pre-filled rule ID in new GUI
o firewall: move download and upload commands out of partial into global commands in new GUI
o firewall: reduce complexity in URL hash handling and when using firewall_rule_lookup.php in new GUI


From https://forum.opnsense.org/index.php?topic=51239.0:

o firewall: when repopulating the interface selectpicker, always restore current selection in new rules GUI
o firewall: remove hardcoded colors where possible in new rules GUI
o firewall: fix category colors in new rules GUI
o firewall: merge read of groups and interfaces in new rules GUI
o firewall: make MVC protocol selection match the old rules pages


From https://forum.opnsense.org/index.php?topic=51402.0:

o firewall: fix regression in alias summary not shown in new rules GUI


From https://forum.opnsense.org/index.php?topic=51570.0:

Further UX tweaks reached the new firewall rules GUI

o firewall: adjust sort order in networks and aliases in new rules GUI
o firewall: change sorting to interface/group name and stop caring about counted rules in new rules GUI
o firewall: change category sorting using names instead of counted rules in new rules GUI
o firewall: remove tokenizer from categories and use selectpicker instead  in new rules GUI

[defaultuserfoo]

Maybe also tell them that the new rules are a work in progress which is in its early stages; that it will be improved upon and that it might be easier later to create a new firewall with the new rules.

I totally agree with you on this one considering the amount of people on this forum that did not know about the fact that the migration is not mandatory at all and can be ignored for a long time into the future :)

So I'm not the only one ... and it's still time to give better information to the users.

I've seen the new rules being there since quite a while, and I didn't want to update.  But it looks as if it won't be long before the so-called 'migration assistant' will be gone and you'll suddenly find yourself without a way to switch after an update.

Things like this need to be handled way better.  I guess next time everyone needs to ask on the forum when something new shows up.

Is there a way to switch from DHCP to kea yet?  When will DHCP be gone?  It would really suck if we had to convert everything manually.

[defaultuserfoo]

But where do they come from then and why were they invented the way they are ?

I didn't know this coming in to OPNsense but interface groups are a BSD networking construct, not at all related to the firewall: https://man.freebsd.org/cgi/man.cgi?ifconfig. 

The manpage isn't very illuminating about this concept.  What's the idea with these groups?

It makes sense now why groups are printed in 'ifconfig' output and I can appreciate why developers would want to let us define rules at that level.

Why would developers want to let us define firewall rules on a concept that doesn't exist?  Is there any kind of relation between interface groups and firewalls?  You're saying there isn't.

I don't understand why group rules would have to be in a specific order, i. e. between floating rules and interface rules.  I can understand that they can be useful in the way I'm using them, but that isn't a good way at all and only due to a lack of better alternatives.  I wish there were a better way.

The way it is now makes it so that having to have the one group rule I actually need leads to a requirement for a bunch of other (overkill) group rules which shouldn't be needed.  That's only because there is no other way to put the rules in the desired order.  That makes me feel like that this is a pretty bad design.

It might be messier in the back end ruleset and lead to higher rule counts, but as an administrative abstraction it's quite useful.  Especially paired with non-'quick' rules that can be overridden at interface level (though these can lead to subtle ruleset bugs which are not obvious if they're used sloppily; you have to mind the ordering of pass/block rules and the successive scope of the matches).

That sounds like a recipie for chaos.  I like it that the new rules are now all in the same place and thus in the 'right' (obvious) order instead of kinda hidden over a bunch of interfaces where you can't really see them unless you flip around all these interfaces all the time.  That alone would make a distinction between different types of rules obsolete, but then there still needs to be a way to block traffic between interfaces wich comes about through interface groups.  If there was another way to do that, what would we need interface groups for?

The 'floating' concept confused me as well because the pf manual makes reference to 'floating' also, so as a newcomer I conflated them.  Totally separate things: pf talks only about floating states, not rules.  @Monviech's explanation above is much needed context for new users, IMO.

'Floating' seems like a kinda random term for the rules that get applied first.  You could as well, or better, call floating rules, group rules and interface rules first rules, second rules and third rules, respectively.  (That's ignoring that such a distinction isn't great for the new rules ...  They are already in some (i. e. one) order and we can actually see that now; only we can't change the order the way we would like to (yet?) because the distinction into types of rules is in the way.  Maybe that makes things difficult to explain.  But if you explain it like the other way round like this (I mean kinda backwards), it's probably easy to understand once a user thought about it for a while.)

Why didn't the developers just do that?

[defaultuserfoo]

Please, read the release notes before upgrading. They are posted on a dedicated section of this forum and they are showed to the admin before upgrading, either by GUI or console.

I always read the notes that are being shown when I'm about to update.  I don't recall any mentioning of the new rules at all, though my memory isn't what it used to be.

Yet if there had been a suitable warning about the new rules like I suggested in my previous post, I would have remembered it.

I usually don't look into the forum.  One of the moderators drove me away by telling me to stop posting when I was trying to help, so now I only come here when I can't avoid it.

This just has been handled badly.

[OPNenthu]

@defaultuserfoo - my response to @nero355's question really has nothing to do with your topic.  Apologies, we got off on a tangential discussion.  Nothing changed with regard to groups in 26.1 that I'm aware of.

AFAIK, the only impactful change is that floating rules now require more than one interface to be considered floating, else they move to the respective interface rulset.  That's nothing to do with the history of Floating as a concept.  Just a functional change in 26.1 (I'm not defending it).

You're a little bit all over the place with some of your interpretations and you're putting words in my mouth while trying to draw me in to your attacks against OPNsense.  For example I never said groups don't exist or that they cause chaos.