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.

[passeri]

@defaultuserfoo, your experience may not be widely shared. For example, I clearly remember the advice and warnings in the documentation on 26.1, before I tested then fully migrated without issue. It follows that assaulting OPNsense and its documentation may not be the most fruitful path to assistance.

To your problem, it appears to me you are creating a global rule then trying to punch a hole in it. This may not be the best initial design. In a corresponding position, at the interface level I allow to any from my primary device, then in a subsequent rule use inversion to limit all others locally, with specific allows (NAT) then general blocks as desired for internet. No holes are punched in any prior rule. These migrated perfectly. I do also have a couple of floating rules covering DNS and NTP for everything. Again, no holes need be punched in that.

In general terms, my advice is first allow what you must, then block the rest. Design and review is a task prior to construction, like any systems design, so in my view your problem existed before your migration exposed it.

no more warning than to back up your configuration and/or to take a snapshot

If you are not taking a snapshot before any similar system modification then you are making a mistake with which I cannot otherwise help you.

[Netlearn]

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.

It looks like you have not even read my post. There has been a whole lot of mentions to the new rules area, starting with version 26.1. To be clear, I will repeat it again:

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.

This just has been handled badly.

Did you absolutely need to migrate to a brand new rules GUI?
Did you check the exported ruleset on a spreadsheet?
Did you have a configuration backup?
Did you have an snapshot?
Did you try it on a test system beforehand?
Did you have a replicate machine to test the changes beforehand?
Do you have a written design of your ruleset?
Maybe it's you that are handling this badly?

Changes usually have some learning curve or adaptation from the user's perspective, but with the new-rules-GUI, you are not forced to change. Just stick to the well known rules-GUI. On the other hand, the best part of OPNsense is probably its active, participative and fast development, so I don't understand your anger with the devs about something absolutely new, and not forced until (at least) two more years (wow) of development.

You should always have a configuration backup (and best to add an snapshot) for your production firewall. If so, you simply recover the last good config are you are done, until you feel ready for the new-rules-GUI transition.

[nero355]

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 totally agree with you, but the reality is that A LOT of people simply DON'T READ them in general and I have seen it happen many times with all sorts of software... :'(

It's sad to say, but developers really need to take this in account and make things "Dummy proof" at some point when a huge change like this comes along : It's simply what people (sadly) seem to expect for whatever reason ?!

I've seen the new rules being there since quite a while, and I didn't want to update.

Then why did you ??

Because these assumptions :

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.

Are simply NOT TRUE !!

Moving from ISC to either KEA or DNSmasqd has been discussed in multiple topics by now which you can find in the 25.7 and 26.1 sections or just use the Forum Search ;)

IMHO it's not that complicated, but you need to know what you are doing, so please also read the information @ https://docs.opnsense.org/

Why would developers want to let us define firewall rules on a concept that doesn't exist?

They don't and making such statements isn't going to get you much help from them either...

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.

AFAIK it's explaned @ https://docs.opnsense.org/ and you can see there that they all have what are called 'Sequence Numbers' if I am not mistaken :
10000
20000
30000
40000
etc.

And if I have understood a couple of topics and GitHUB Issues correctly (Please note : Maybe I did NOT!) the big discussion is now what to do next :
Use just these numbers or create some kind of hybrid between the current system and them...

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.

AFAIK there should be, but I don't mess around with the Firewall Rules enough to give you the best advice about that.

'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.

Actually the current system makes a lot of sense to me, but as with everything : You need to read the documentation and get used to new things!

Now I do have to admit that I did not do that for a lot of OPNsense things because I knew what I was doing from the start, but for some things you simply have no other choice and IMHO it's not something to complain about either...

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.

The message that appears after checking for updates clearly displays it : Your choice to read it or not.

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.

Sorry you had to go through that...

I know the feeling : I left a forum last year that I was a member of since 2002 because of the same reason!

I clearly remember the advice and warnings in the documentation on 26.1, before I tested then fully migrated without issue.

Yep! :)

In general terms, my advice is first allow what you must, then block the rest.

Actually a Firewall should always be : Block First then Allow what you need to allow.

OPNsense does this too : When you create a new network there is no Internet access at all : It's blocked.
_{(This is simply put ofcourse. We all know it's not exactly like that, but most people experience it like that!)}

Did you check the exported ruleset on a spreadsheet?
Did you have a configuration backup?
Did you have an snapshot?
Did you try it on a test system beforehand?
Did you have a replicate machine to test the changes beforehand?
Do you have a written design of your ruleset?

To be honest : I just backup my config.xml on a regular base on two different systems and that's it!

If everything goes soo wrong that I need to reinstall : So be it! :)

Maybe it's you that are handling this badly?

Hate to say it, but that's probably the case here...

Changes usually have some learning curve or adaptation from the user's perspective, but with the new-rules-GUI, you are not forced to change. Just stick to the well known rules-GUI. On the other hand, the best part of OPNsense is probably its active, participative and fast development, so I don't understand your anger with the devs about something absolutely new, and not forced until (at least) two more years (wow) of development.

AMEN! :)

You should always have a configuration backup (and best to add an snapshot) for your production firewall. If so, you simply recover the last good config are you are done, until you feel ready for the new-rules-GUI transition.

100% AGREE !!!

[defaultuserfoo]

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.

It's not my intention to put words into anyones mouth.  Where do you think I would have done that?

I haven't attacked opnsense either.  Are you putting words into my mouth?

[defaultuserfoo]

In general terms, my advice is first allow what you must, then block the rest. Design and review is a task prior to construction, like any systems design, so in my view your problem existed before your migration exposed it.

That's what I have been doing and am still doing.  Once something has been blocked there is nothing a hole could be punched into.

no more warning than to back up your configuration and/or to take a snapshot

If you are not taking a snapshot before any similar system modification then you are making a mistake with which I cannot otherwise help you.
[/quote]

I did take a snapshot and took a backup of the configuration.

That doesn't mean that better information and warning about switching to the new rules should have been and should be given.  It's not like that would be difficult to do, and it can still be done.  Instead it's being suggested that there's the so-called migration assistant which users are supposed to use soon before it goes away, and which would make the transition smooth.  After all it's a 'migration assistant', so obviously, nothing could go wrong.

[Patrick M. Hausen]

Instead it's being suggested that there's the so-called migration assistant which users are supposed to use soon before it goes away

Where exactly has this been suggested? Particularly the "soon" and "goes away" parts?

[Monviech (Cedrik)]

Nowhere :)

Not sure where all the alarmism, actionism and finger pointing is coming from in this thread. xD

[defaultuserfoo]

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.

It looks like you have not even read my post. There has been a whole lot of mentions to the new rules area, starting with version 26.1. To be clear, I will repeat it again:

I have not read your post in detail.  I saw you put a bunch of links to forum posts and lists of changes.  At that point my firewall rules were already screwed up.

Like I said, I usually don't look into this forum because I was basically told not to do that, and there is insufficient information and warning about these new rules outside of that.  The so-called 'migration assistant' suggest that user will experience a smooth and trouble free transistion.  The documentation about the new rules is also insufficient.

o The firewall migration page is not something you need to jump into right away.

I didn't jump into it but dreaded the switch and waited a while, being afraid that after one of the next updates it would be too late to do it.  It doesn't say anywhere except maybe somewhere in the forum that it would take years before it might be too late.

Just use the 'migration assistant' and it'll be fine obviously ...  If you don't trust the developers you can't use what they're making.  Opnsense updates have always been working without issues over the years, and it's not feasible for me to set up an up to date system to test it in production before updating every time.  There are other precautions.  So after making good experiences with it, why not use the so-called 'migration assistant'.  It'll be fine.

Why is it so difficult for you to admit that better information and warning about the new rules should have been given to the users during updates and on the page of the so-called migration assistant?  Why are you going to all these lengths to defend this oversight?

This just has been handled badly.

Did you absolutely need to migrate to a brand new rules GUI?

No, but I had to do it before the option to switch would have been removed.  Or what would the alternative have been?

Did you check the exported ruleset on a spreadsheet?

Yes, and there isn't anything wrong with the old rules and apparently nothing wrong in the spreadsheet.

Did you have a configuration backup?
Did you have an snapshot?

both

Did you try it on a test system beforehand?
Did you have a replicate machine to test the changes beforehand?

No, I don't have test system for that.  Once you understand how freaking expensive electricity is in this country (on top of everything getting more expensive and worse every day), you might understand why.  Also I have only limited room.  Do you expect everyone to buy additional machines and rent some office space to set up a bunch of testing environments for every update and every change?

And why would I have done that?  Just use the migration assistant and it'll be fine.

Do you have a written design of your ruleset?

No, I don't need one.

Maybe it's you that are handling this badly?

No, definitely not.

so I don't understand your anger with the devs about something absolutely new, and not forced until (at least) two more years (wow) of development.

I'm not angry about the new rules.  I like them better than the old ones, and they seem like a really nice improvement has been made.  And of course I appreciate that development goes on and that so much work is being put into it.

I'm merely saying the transition needs to be handled better by giving better information and warning at the very place users actually look at.

How do you suggest that users know about all the forum posts you provided links to before you put them into your post --- especially when they were told to stay away from the forum --- and when the documentation doesn't have sufficient warning and information either?

[defaultuserfoo]

Instead it's being suggested that there's the so-called migration assistant which users are supposed to use soon before it goes away

Where exactly has this been suggested? Particularly the "soon" and "goes away" parts?

It's being suggested by the so-called migration assistant showing up in the web interface.  It makes it obvious to users that things are changing and that they better keep up with the changes and andjust and adapt before its too late.

Why doesn't that page simply tell the users something like "Don't use this feature, it'll be years before this becomes relevant, and if you use it, your firewall rules will probably be screwed up."?  At least that way users would know.

[Monviech (Cedrik)]

Most migrations happen automatically under the hood without user interaction.

For firewall rules an automatic forced migration would have been far worse than an optional one.

After an upgrade nothing is broken, everything is 100% transparent. You can even compare old and new ruleset before deleting the old rules.

We did the right approach here, your reaction shows nothing would have been appreciated except 100% perfection. But thats not feasible because whatever we would have done, some concepts would have been lossy one way or another.

Having an optional instead of a forced migration is great for the user.