Recent posts

#1
Quote from: Monviech (Cedrik) on Today at 10:35:20 PMPlease keep your annoyance in check, it's quite hard to go from a historically grown legacy implementation to a new one without having some edge cases. That it seems to overly affect you personally is nothing that could have been anticipated.

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


Don't be surprised when users are very annoyed.  Having the so-called migration assistant and no more warning than to back up your configuration and/or to take a snapshot makes users think that it's an easy and simple migration that will take maybe 5 minutes, if that, and that in the unlikely case in which one might find an issue, it'll be easily resolved by skimming over the exported rules in ones favourite spreadsheet.

You need to tell users that this is NOT a migration but merely an export and import of existing rules.  You need to tell them that their old rules will inevitably mean something else in the new rule section and that the old rules will only give you some clue as to what was intended with the old rules.  You need to tell them that they will have to set up their whole firewall again as if from scratch.

You also need to tell them that they have at least 2 years before making this change and that they better don't do it but wait until they actually want to rebuild their firewall from scratch and do that with the new rules.

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.

Only if you do that, the users may not be too annoyed but might even be glad that there was an improvement made (or prepared) by switching to the new rules.

#2
Quote from: Monviech (Cedrik) on Today at 10:09:21 PMThe easiest way to create a floating rule right now if you really need to for some reason is to create a random loopback interface(Interfaces -> Devices - Loopback), assign it, name it "Floating" for example, and add it as second interface to any rule that should be floating.

But please keep in mind that this is not the intended way to use the ruleset, only a workaround if you really need it for some reason.

I made floating rules because I needed them, without creating extra interfaces :)  I still need rules that do what the floating ones did, only now floating rules don't work anymore and group rules are required instead.

Quote-----

Also group and floating are not concepts of PF (the paket engine thats configured) Check out /tmp/rules.debug, there is no floating or group in there. PF only goes by a global order.

Mmh, that's what I thought.

QuoteIf you unhide the advanced options in a new rule you can see the priority group and the seqence. Ideally, there should only be a global sequence and no priority group (group and floating), but getting to there and resolving the sins of the past is still up in the air.

If that's so easy, then why did the GUI prevent me from moving my LAN rule above the blocking rule?  Is that a bug in the GUI?
#3
Yes that is true, there is already a global sequence and priority groups. Everything is in place for more flexibility. But it has to start somewhere.

Enable advanced mode in a rule, see the sequence and the sort order.

Unhide them inside the Grid, you can do so with the button next to the number of items to be shown.

Please keep your annoyance in check, it's quite hard to go from a historically grown legacy implementation to a new one without having some edge cases. That it seems to overly affect you personally is nothing that could have been anticipated.

https://github.com/opnsense/core/issues/9652
#4
26.1, 26,4 Series / Re: SUPPORT NEEDED - Reply-to ...
Last post by Oriann - Today at 10:34:33 PM
Bumping this because 26.1.6 still have this bug and I am starting to see people on forums that have same problem like me.
#5
26.1, 26,4 Series / Re: Multi WAN load balancing v...
Last post by Oriann - Today at 10:29:26 PM
Quote from: franco on April 15, 2026, 07:29:33 AMWell, I'm not hiding. Your problem scope fits our support offering but clearly exceeds community support due to the lack of code-bound evidence and not many other people having the issue, which could also mean it is local to you and then it would only be solvable with local analysis which we don't do in community scope.


Cheers,
Franco

Hi there, just to clarify I have found out this bug really by luck. There is the problem if you have almost same speed dual WAN then it looks like its all working fine so nobody cares(many services dont mind assymetric routing). If I would not set up traffic shaper I would never found out that upstream traffic is going elsewhere. You know the bug is kinda hidden so maybe thats why nobody cares because their infrastructure "just works". I am really tring to sell this on forums and convince somebody to test more but I feel like nobody have time to test this even when I have provided reproduction steps...So sorry for my dissapointment this way.
#6
Quote from: Monviech (Cedrik) on Today at 09:36:05 PMSure here is the relevant section. Please note group rules are not a new concept, they also exist in the old firewall rules since ages.

Well, I never had to mess with group rules before.  I'm finding interface groups for things like VPNs very strange, if not to say annoying.  What's the point of forcing entirely different, unrelated interfaces into a group?  I have to have specific rules for each connection anyway, and only if I should ever need to have the same set of rules for a bunch of connections (interfaces), only then I should be able to optionally create a group interface.

Floating rules seem fine.  I made some floating rules according to https://forum.opnsense.org/index.php?topic=28447.msg138309#msg138309 because, unless that changed in the meantime, is the only way to deal with IPv6 when you don't have a static prefix.  It required to make an interface group but no group rules.

After this migration it seems that the floating rules need to be converted into group rules because they aren't working anymore.

QuoteFloating is an annoying concept that still has to be decided on most likely at some point. For now it is what it is.

Floating is very nice indeed.  Mankind has been dreaming of it for thousands of years before we finally managed floating :)

I think the problem is more with the arbitrary numbering of rules.  What matters is the order of the rules, not their numbers, but with the new rules, things got worse because the arbitrary numbering didn't go away but the distinction between different types of rules did.

I'm not sure if would make sense, but I might suggest to explicitly introduce types of rules, and for each type its own number range.  Each of the number ranges could go from 0 to N to order the rules of each type in a desirable way.  And the overall order of rules would be determined by their types.  It would be more user friendly to have types of rules.

It kinda shows in the GUI with the new rules in that the new rules are in a particular order.  That even begs the question why there are different types of rules.  What's the point of having these types?  It seems the order of the rules matters, not their types ...

All it currently does is preventing me from moving my LAN rule before the blocking rule.  If I could do just that, things would be much easier, and there wouldn't be a need to create overkill rules (unless I'd actually need one).

QuoteAlso you are not forced to migrate yet. The old rules stick around for 2 more years at least. No rush.

Why didn't it say that?

But I'll have to do it anyway, eventually ...

Quote-----

Since Firewall ‣ Rules [new] and Firewall ‣ Rules implementations exist side by side, there are some additional considerations regarding the processing order of rules.

If a Firewall ‣ Rules [new] filter rule has:

a single interface defined, it is an Interface Rule
a group interface defined, it is a Group Rule
any number of interfaces or one inverted interface defined, it is a Floating Rule

Ah yes, I saw that but couldn't find it when I tried to find it again later.

This makes no sense.  The order of the rules should matter, not what their arbitrary types are.  The GUI to create rules is already the same for all of them.  It only needs to allow us to move our rules to where we want them.
#7
26.1, 26,4 Series / 26.4 upgrade errors
Last post by mooh - Today at 10:20:49 PM
Upgrading from 25.10.2_12, I came across this bit in the log:
69/196] Extracting os-OPNBEcore-1.8: .......... done
/bin/sh: /usr/local/opnsense/scripts/firmware/register.php: not found
pkg-static: DEINSTALL script failed
/bin/sh: /usr/local/sbin/pluginctl: not found
/bin/sh: /usr/local/opnsense/scripts/firmware/register.php: not found
pkg-static: POST-INSTALL script failed
What went wrong? Auditing the system doesn't indicate any problem. Full log file attached.
#8
Zenarmor (Sensei) / Re: ZA 2.5 release?
Last post by sy - Today at 10:19:14 PM
Hi,

It was released yesterday and is currently rolling out in phases. We expect the full rollout to be completed for all users by early next week. Please stay tuned for further updates, and feel free to reach out to our support team if you have any questions during this transition.
#9
26.1, 26,4 Series / Re: Thin disk / ZFS / Unmap?
Last post by dinguz - Today at 10:11:41 PM
I'm not familiar with the intricacies of ZFS in a VM, but regarding autotrim: this does only trim recently freed up disk space, locally so to speak. It doesn't do full disk passes periodically; you would need zpool trim for that, as you have already found out.
#10
The easiest way to create a floating rule right now if you really need to for some reason is to create a random loopback interface(Interfaces -> Devices - Loopback), assign it, name it "Floating" for example, and add it as second interface to any rule that should be floating.

But please keep in mind that this is not the intended way to use the ruleset, only a workaround if you really need it for some reason.

-----

Also group and floating are not concepts of PF (the paket engine thats configured) Check out /tmp/rules.debug, there is no floating or group in there. PF only goes by a global order.

There is no special mythical behavior to a floating rule, its just a hardcoded cheat to set it earlier in the global order. Most of the time that is never even needed.

If you unhide the advanced options in a new rule you can see the priority group and the seqence. Ideally, there should only be a global sequence and no priority group (group and floating), but getting to there and resolving the sins of the past is still up in the air.