Messages

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.

For me it works, are you sure you are setting the color picker correctly?

E.g., in Chrome you have to click the colored box to where the color is. If you only use the slider, the actual color picker stays on black.

I am on macOS and Safari.
I click one one the small square boxes with the colors.
It used to work before I upgraded OPNsense.

After migration, I still see "Rules [new]" and "Rules".
Within "Rules" there are still 9 automatically added rules - and I am not sure if that means they now exist double, in the old and in the new rules.

A clear way would be to remove the "Rule" and rename "Rules [new]" to simply "Rules".

Can I do this somehow?
Will this be added later?

As there are still rules listed with in the old rules (), this is not just cosmetic.
It is quite confusing :-)

Also, even as I deleted all "Floating Rules" they are still listed for other Interfaces, see the screenshot.

After migrating to 26.1.1_5 I changed and added some firewall categories, but the color picker does not work!
You can select a color from the graphical color picker, but in the overview and in the rules, all of them remain black!