Messages

Boot the older version, uninstall the os-microcode plugin, redo the update.

That did it, great many thanks!

I also compared /conf/backup from the older snapshot and the original (now bad) snapshot, and as it seems there was no new config - I did not loose any changes, luckily!

- power cycle with keyboard and monitor attached
- abort the boot process and escape to the boot loader prompt
- disable the loading of the microcode update

This should get you going with a search engine, possibly AI, or search function of this forum - I don't have the time to research the details of each step just right now, sorry.

HTH,
Patrick

OK, thanks already!

I managed to select another snapshot and could boot it, create a new copy from it and then retry the update - the same happened again!
So indeed, something is wrong for my PROTECTLY firewall.

I will seek out disabling the microcode update but at least am running from an older snapshot again!

I did sadly not create a new snapshot or downloaded the latest configuration, yet I clicked on Update in the Lobby.

I noticed that the downloads were very slow, but finally the system did get down (with it's sound).
But I did not come up again.

I attached monitor and keyboard and saw this (actual photo attached):

I tried to find something in the boot menu, but it just boots to fast for me to even read it.

Any idea what I could do now?

It may be the case that interface totals in FreeBSD cannot be collected for abstractions like interface groups?  In that case some process in OPNsense would need to aggregate the data for the groups.

Assuming that's true, and if there's no plan to implement that, then I would rather have the groups omitted from RRD and Netflow to de-clutter them.

Let's see what the official response is.

Yes, I had the impression that Interface Group should just not show up there....

Open an issue on Github to get developer attention. Stick to the provided template, i.e. fill it in or the bot will de-prioritise your issue.

I will try, thanks

That is already fixed on master and will be released soon.

Fantastic news, thanks!

If it is in Rules [new] that will be fixed at some point.

Great, many thanks!!!

Before the update, I could hover over Aliases in the firewall rules to see the ports that I configured.

Not, only the descriptions get's shown - which is quite disturbing and requires me to have a second window open to check the content of those Aliases.

That was much better before.

I started to copy Ports into the description as well, for a mitigation.

I was working on my firewall rules, but editing some rule and saving it, the view get's refresh and I am at the start of the rules again.
This requires me to scroll down again, search for the last rule I was editing and continue with the next - and then the same happens again, and again, ...

I seem to remember that the behavior was different in an earlier release - nothing got refresh or reloaded and I was not pushed back to the first rules over and over again.

Oh yes, a fix for this would be great!

I started to use multiple windows as mitigation.

Not MUCH replies 😅

Nobody knows whether Interface Groups should appear in Health and actually work there?
For me, they appear and do not work!

Who and where to ask, if nobody here knows?!?

And then, the problems that I cannot switch to Traffic in Health instead of Packets - the display is broken!
And it was OK until I updated!

Within Health, I can check "Packets" for my enabled interfaces.
Strangely, I also see Interface Groups in the "Subject" selection, but those do not work!
No packets are shown for the groups - so either this is a bug, or the bug is that Interface Groups are shown in the selection.

I can see that the timeline is different, but "Reset Zoom" does not change anything - the screenshots.


Also, when switching to "Traffic" instead of "Packets", I have one Interfaces that does NOT shown any traffic anymore - while for Packets, it can be seen. It seems like this Interface is handled like a Group.

And in Insight, I see daily packets from an Interface where the attached computer is shut down!
I cannot produce traffic, but still it get's shown:

To hunt this down, I let tcpdump run on the firewall to capture those packets - but there are no packets:

root@OPNsense:~ # ls tcpdump_igc4.out
-rw-r--r--  1 root wheel 0 Mar 12 17:45 tcpdump_igc4.out
root@OPNsense:~ # fuser tcpdump_igc4.out
tcpdump_igc4.out: 55959w
root@OPNsense:~ # ps auxwww | grep -w 55959
root    28731   0.0  0.0   13744    2464  0  S+   17:44       0:00.00 grep -w 55959
root    55959   0.0  0.0   21912    7952  0  SC   17:45       0:02.19 tcpdump -i igc4 -n -e -vvv -s 0 -XX -tttt


Yet... see screenshot ... the WebGUI shows them!

Thinking again about this, it just feels like a bad idea to define "floating" rules by the number of affected interfaces.

Floating rules need to be a separate group, executed before all other rules - but they should also be possible for just one interface - they just have a generic character.

And on the other hand, regular interface rules should be definable for multiple interface without affecting the sequence.

There are plenty of reasons to allow or block something at a certain points of the rules and being able to do this for more than one interface.

Disallowing this just makes the rules more messy and I need now to add any such rule for each of the required interfaces!

Not sure I understand this, but I'm interested.  Can you elaborate on what you mean by "late" rule?

See below

There's a kind of open challenge from the devs to come up with cases that no longer work in the new Floating system:

https://github.com/opnsense/core/issues/9652

That's great, going to check this!

For example:

I could have allowed some port from interface A to interfaces B an C, only.
And this rule, add a generic block for this port for all local interfaces and all remotes IP (on WAN).

But adding this "late" rule, will now move it to the top, to the floating rules, as I need to add all interfaces.
So, now it blocks this port everywhere and the original rules cannot be reach anymore.
That is ... stupid, or? ;-)

Yes, I still can add ALL interfaces one by one, so that the late rules don't get moved to the top - but that's also stupid, right?

I think so far the devs are winning with the caveat that you have to use a dummy or loopback interface to avoid splitting related Floating rules across interfaces :P

I don't understand.
Could you elaborate?

Unsolicited advice: once you've migrated, don't look back at the legacy UI for any reason.  Just forget it exists and try to acclimate to the new one (which is a lot like a spreadsheet).  The exception is for Outbound NAT as that isn't migrated yet.

That was very informative.
Those multiple groups of automatically created rules were confusing.

BUT, in my Interfaces below the old rules, I still see "Floating rules" and those are clearly MY floating rules, not automatically created!

They seem to be the same as from the new rules, at least I can see one new rule that I added in the new rules section after the upgrade.
But they have no Delete button.

Really, this is confusing!
But I hear you and will try to ignore :-)
Thanks!

BTW, in the old version, you could create a floating rule for any and all selection of Interfaces - now, adding a second Interface, will change the rule to a Floating rules and vice versa!

That means, adding a second Interface moves a rule automatically up to the Floating rules, which are handled before other rules.
And removing all but one Interface, removes the rules from the Floating rules, dropping it in priority!

This seems to be a fundamental change to before, where changing such things would never change the priority (rule-number)!

And, I cannot have "late" rules anymore for more than one Interface! Now, such a rule get's moved to the front.
Before, "Floating" was simply separate, not decided by the number of Interfaces.