Upgrade to RC1 successful

[Maurice]

Just a quick report that I upgraded from the 25.7.11 development version to 26.1.r1, so far without issues.

Switching back to Community doesn't replace the automatically installed os-isc-dhcp-devel plugin with the non-devel version, but I think that's expected. It's an additional manual step which might be worth mentioning in the upgrade instructions.

I keep hostwatch disabled for the time being, so no statement about that.

Cheers
Maurice

[patient0]

Same for me, I did pgrades two OPNsense installation.

One from an installation which was on the Development channel, by switching as France explained, no issue.

The other was on the Dev channel too (not that it matters), exported config (to be sure) and reinstalled using the DVD ISO. The config was found on the ZFS pool and installation when smooth, and with the config found on the ZFS pool.
The only confusing thing was that after the installation and before the reboot the text on the console told me that the OPNsense GUI will be reachable on 192.168.1.1. That specific installation is IPv6 only, so I wasn't sure if the config was applied correctly - but it was.

[franco]

Ah, oui, naturellement.  ;)

I added a note about the plugin situation in the forum announcement post.

The "https://192.168.1.1" is a bit of a hardcoded relic.

https://github.com/opnsense/core/blob/e75192ca461dfa/src/sbin/opnsense-installer#L53

From an imported config where "lan" may not exist it can be difficult to extract the correct value from. Let's call it an artefact for now.


Cheers,
Franco

[meyergru]

I switched to 26.1-RC1 as well. Most things worked OOTB, however, I found that the NAT rules filter associations were gone, showing only "Manual" instead, although some link still exists as evidenced by the associated firewall rules being non-editable as usual.

After I tried the first steps of rules migration, all new style rules had no categories and were disabled per default.  I wonder what would have happened if I followed the instructions and just removed the old rules at that point.

I tried to understand how the NAT rule linkage relates to new/old rules, but failed. Since it was a production system, I did not dare to remove the old rules.

What is irritating is that "floating rules" now are just the ones that have more than one interface, so if you add an interface to any existing interface rule, the rule shifts to floating rules (and also the other way around). However, I like that, because with the old style rules, you manually have to re-create a rule in the floating section. One has to get accustomed to this, however, because I also used 1-interface-only floating rules for blocking in the floating section just because of the priority being greater than implicit port forwarding rules.

[franco]

Uwe, can you check the CSV if the enable flags and categories are exported correctly for you?


Thanks,
Franco

[franco]

Scratch that, here's the fix for the enabled https://github.com/opnsense/core/commit/94081fd82f

And this is for categories: https://github.com/opnsense/core/commit/d1519593

Thanks!

Edit: Since were at the topic Stephan found this earlier today as well https://github.com/opnsense/core/commit/ba8194de

[franco]

> I tried to understand how the NAT rule linkage relates to new/old rules, but failed.

The old page added a separate "association rule" which is a bit of a broken firewall rule.

The new system will create a shadow rule in in "Register rule" mode somewhat resembling the old approach but without injecting a real firewall rule. Manual and pass are still the same.


Cheers,
Franco

[meyergru]

As you have found, the enabled flag was not exported correctly nor were the categories.

I now used:

Code Select Expand

opnsense-patch ba8194de
opnsense-patch 94081fd82f
opnsense-patch d1519593
configctl webgui restart

And then re-exported the old settings. This time, the enabled and categories settings seemed correct in the CSV.

BTW: In the migration assistant list of steps, it says: "Deselect anti-lockout in advanced settings" - it should be "Enable anti-lockout in advanced settings".

The thing with the manual rule is that with 25.7.11, you saw the associated firewall rule name there, so you would know which one it was. This gets lost immediately upon update, you do not have to use the migration assistant. That means I see that there is an associated rule:

You cannot view this attachment.

Yet in the NAT rule, it does not identify which any more (before you would see the description "Allow DNS via IPv4" instead of "Manual"):

You cannot view this attachment.

[franco]

> The thing with the manual rule is that with 25.7.11, you saw the associated firewall rule name there, so you would know which one it was. This gets lost immediately upon update, you do not have to use the migration assistant. That means I see that there is an associated rule:

Yes true but it's now disassociated (manual) and the display of the firewall rules is exactly the same as before and still has the same description. Functionally after the upgrade it's the same. It only starts behaving differently when modifications are being made to destination NAT rules.

We don't have a lot of leeway leaving this concept behind other than making this cut.  I can make sure to add this to the migration notes.


Cheers,
Franco

[Patrick M. Hausen]

If floating is now defined by "active on more than one interface" does that change the rule processing order?

I use block rules, floating, with only a single interface - WAN. I do this because I want them applied before NAT rules on WAN. This way I can use "pass" for inbound NAT but "floating before interface" still beats NAT in processing order.

I am worried if ticking more than one IF moves a rule to floating, that a floating rule with just a single IF ticked will be moved down to interface specific.

I hope I could explain the problem - if there is one at all.

[meyergru]

That would be my question as well, as I already hinted at... with the new logic, priorities would potentially change just depending on whether you add or remove interfaces...

[meyergru]

Yes true but it's now disassociated (manual) and the display of the firewall rules is exactly the same as before and still has the same description. Functionally after the upgrade it's the same. It only starts behaving differently when modifications are being made to destination NAT rules.

Yet the disassiciated rule is not editable (only the rule order is and I can delete the rule)? Then if I change something in the underlying NAT rule (say, change the port), I could not even make the corresponding change in the firewall rule? See my screenshots above for what I mean...
 

[franco]

Yes, that was how it always was.  There was a point in time where they were editable but it also led to strange results so at some point it was disabled. Now in theory the edit could be re-enabled.

I'm not sure what the issue was.  Only remember that the associated rules were very partial rules and this lead to expectation vs. reality situations too during the time edits were allowed.


Cheers,
Franco

[meyergru]

The edit really should be re-enabled: The lack of editing of associated rules was fine as long as they were associated, IMHO - if they become disassociated, they should gain "full freedom" during upgrade (i.e. become editable) and not stay around like they were still associated.

By not being able to edit them or see their details, it would be error-prone, because everyone used to the old scheme (like me) would assume they are still linked to and controlled by their respective NAT rule - which they are not.

[franco]

Yep, I already agreed. I'll bring it up tomorrow.