Recent posts

#1
26.1 Series / Re: New rule system
Last post by Monviech (Cedrik) - Today at 10:03:17 AM
When you press "Inspect" in the new rules page it should show all automatic, legacy, new rules, floating group interface etc... in the correct order filtered by the current interface.

When you press "Tree" it will also group the automatic rules in folders like the old view (only if Inspect is also active)

If a rule is missing in that overview and you have steps to reproduce it, let us know. (best as a github issue)
#2
26.1 Series / Re: New rule system
Last post by meyergru - Today at 09:43:54 AM
Although I second the opinion that the migration tool will spark much more interest (and problems) with the existing user base on release of 26.1, I have to object OPNenthu's potential rationale here:

Based on what Patrick and I (and obviously, OPNenthu) believed until Friday last week, a floating rule was the only thing that preceeds a port-forwarding "PASS" rule. Thus, our workflow was based on that false assumption. For example, we used port-forwarding rules with "PASS" for simplicity, but has floating rules to black any access from blocklists like Firehol, Blocklist.de or QFEEDs.

Last week, we found - to our surprise - that the docs were correct in specifying that this is not the case. Floating rules are in fact less prioritized than implicit NAT "PASS" rules. You have to create an associated rule, which then goes to the interface rules and thus is always preceeded by floating block rules.

On a side note, such rules will get disassociated during update to 26.1, as discussed here.

And BTW: This is why both Patrick and I asked basically the same questions there. Consider them obsolete.

The only thing about order that I find irritating is that, after migration, the only spot were you can really see what order all al the rules (i.a. automatic, floating, interfaces, groups, automation, "old") are being used in, is the old rules - and those will presumably be removed at some point.
#3
26.1 Series / Re: New rule system
Last post by OPNenthu - Today at 09:29:02 AM
I'm familiar with that :)  It doesn't answer how existing Floating rules for a single interface will get migrated (or not) to MVC.  If there is already a migration document, I haven't found it.

What I do understand from that document, is that MVC has a design restriction that a single-interface Floating rule is not possible.

Ergo, do some uses cases not transfer?  Do those types of existing Floating rules simply remain in the legacy UI, or...?
#4
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by franco - Today at 09:25:17 AM
No, that's not something we're considering at the moment.


Cheers,
Franco
#5
25.7, 25.10 Series / Re: Interfaces: Neighbors: Aut...
Last post by franco - Today at 09:18:27 AM
It's likely, but I'm not sure which version.  We're at 1.0.9 now which goes into RC2 tomorrow and then we'll decide.


Cheers,
Franco
#6
26.1 Series / Re: Rules [new], unable to edi...
Last post by franco - Today at 09:12:30 AM
Yep, RC2 on Monday. There have been a few nice reports in that area. Exactly what the RCs are for.  :)


Cheers,
Franco
#7
26.1 Series / Re: New rule system
Last post by franco - Today at 09:05:00 AM
I was under the impression this has been documented for a while and yielded no extensive feedback...

https://docs.opnsense.org/manual/firewall_automation.html#processing-order

Not sure if and how this will fundamentally change.  "Automation" rules are already used in production environments by many users and from support experience setups can have a few thousand rules which are easy to administer and perform nicely (compared to the old rules pages where this is not the case as much).


Cheers,
Franco
#8
26.1 Series / Re: Upgrade to RC1 successful
Last post by franco - Today at 09:00:11 AM
No, Identity association mode is a trick that enforces "Allow manual adjustment of DHCPv6 and Router Advertisements" so you can still use RA and DHCPv6, but only if configured manually. You can also mix and match the Track interface mode and the new one for LANs.

The relevant patches illustrates this clearly for reference:

https://github.com/opnsense/core/commit/f8da6e147b2
https://github.com/opnsense/core/commit/e790033253c


Cheers,
Franco
#9
26.1 Series / Re: OpenVPN legacy plugin
Last post by franco - Today at 08:56:59 AM
Correct, you can read about support tiers here https://docs.opnsense.org/support.html#supplemental-tier-2

There are no plans to remove either this year so they will keep working. If a problem appears with them (like a major OpenVPN update) it's likely the legacy plugin will not be updated until that is shipped for the MVC version in core, which could introduce incompatibilities for example.

At some point we will make an inventory for feature parity and when there's enough overlap we will let go of the old plugins (maybe 2027, 2028, who knows yet). The tier switch is an encouragement to move to the new core GUI and report issues and missing features to reach for feature parity (as far as that's possible or wanted for a couple of reasons like design, security and robustness).


Cheers,
Franco
#10
26.1 Series / Re: Kea IPv6, random allocatio...
Last post by franco - Today at 08:51:44 AM
No problem. The advanced rules are relatively hidden for mostly good reasons and the Kea documentation on our side is not all that complete, see

https://docs.opnsense.org/manual/kea.html

where the option is not mentioned (yet).


Cheers,
Franco