"Recent posts
#21
26.1 Series / Re: New rule system
Last post by meyergru - Today at 10:34:04 AMGood question, but I think you could create that rule as the first interface rule as well. Creating a floating rule as suggested only makes extra sure it gets processed first.
#22
26.1 Series / Re: New rule system
Last post by OPNenthu - Today at 10:23:18 AMQuote from: meyergru on Today at 09:43:54 AMLast 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.Thanks, this explains that use case.
One more I'm curious about, pertaining to VPN killswitch floating rule as per: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html#step-11-add-a-kill-switch-optional
I have such a rule with direction "out" on WAN, which I believe is processed post source-NAT (but irrelevant in this case- it's just matching on a tag and dropping packets). That is another case of a single-interface floating rule. Will the migration tool just convert this to a WAN interface rule?
#23
26.1 Series / Re: New rule system
Last post by meyergru - Today at 10:14:16 AMIt is true that you can inspect the rules. What I miss is the quick overview where you can see the list of rules with all preceeding rules before them like so:
You cannot view this attachment.
You cannot view this attachment.
#24
26.1 Series / Re: New rule system
Last post by Monviech (Cedrik) - Today at 10:03:17 AMWhen 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)
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)
#25
26.1 Series / Re: New rule system
Last post by meyergru - Today at 09:43:54 AMAlthough 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.
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.
#26
26.1 Series / Re: New rule system
Last post by OPNenthu - Today at 09:29:02 AMI'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...?
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...?
#27
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by franco - Today at 09:25:17 AMNo, that's not something we're considering at the moment.
Cheers,
Franco
Cheers,
Franco
#28
25.7, 25.10 Series / Re: Interfaces: Neighbors: Aut...
Last post by franco - Today at 09:18:27 AMIt'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
Cheers,
Franco
#29
26.1 Series / Re: Rules [new], unable to edi...
Last post by franco - Today at 09:12:30 AMYep, RC2 on Monday. There have been a few nice reports in that area. Exactly what the RCs are for. :)
Cheers,
Franco
Cheers,
Franco
#30
26.1 Series / Re: New rule system
Last post by franco - Today at 09:05:00 AMI 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
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
