New rule system

[Seimus]

I thought reStructured supported flow diagrams (but maybe I am making things up).

It is bit lousy yes, but it as well says a lot.

Anyway got ya. But its something that sooner or later would be worth a while.

Regards,
S.

[keeka]

Thanks all for the pass clarification. That makes it clear and makes sense. I have been aware of the packet processing order but somehow got misled ;-)

If the source/destination criteria on the forwarding rule are sufficiently selective, then I suppose a 'pass' action is sufficient. In fact it now occurs to me that some of my associated rules may be redundant.

[meyergru]

If the source/destination criteria on the forwarding rule are sufficiently selective, then I suppose a 'pass' action is sufficient.

True, but there is a problem with it: Imagine you have some blocking rules. You can use them in the floating rules, but just for WAN. You can enable or disable each of them selectively and that combination works work all port forwarding and allow rules after that alike. I mean something like this:

You cannot view this attachment.

If you want to mimic that with separate source criteria for each port forwarding rule, you look at a lot of work. Also, some of the block rules cannot be combined in a single network group alias, because of their type (say, __qfeeds_malware_ip).

Therefore, you probably still need separate rules (I do) to be able to shift their priorities, but you must take care of them manually after 26.1, because they become disassociated from their respective NAT rules.

[keeka]

That leaves the question in which situations the "Pass" mechanism might be useful at all.

AISI pass may be useful when:
- source/destination criteria in the port forward rule will serve all needed filtering criteria.
- no egress filtering is needed.
- no tagging, policy routing, traffic shaping (or something else?) is needed.

Would that be about right?

@meyergru I have a couple of portforwards on the WAN where the pass action won't be satisfactory. However I also have some on the WAN and almost all those on the local interfaces, where I think it will be appropriate. Just that it never occurred to me use that option in the past and so I have, what I now think, may be redundant filtering.

EDIT Having said that, it may get confusing in the future having the cause of passed traffic not visible in the filter list. I'm sure that would catch me out especially with my memory these days. In fact I think this is a good enough reason for me not to use Pass and instead explicitly define filter rules to pass port forwards.

[Patrick M. Hausen]

- source/destination criteria in the port forward rule will serve as the filtering criteria.

Sure. Only thing is this is getting increasingly difficult in a single rule - regardless of NAT or filtering. Picture on WAN:

    block all known bad actors: free block lists, Q-Feeds, Crowdsec, ...
    permit inbound from GeoIP Europe but block everyone else

In a single rule you can have either source invert or not. You cannot combine in this fashion e.g.

    allow from (not (bad actors)) and (GeoIP Europe)

You can of course

    block from (bad actors) and (GeoIP except Europe)

only that the second variant generates an alias with orders of magnitude more entries.

So for me essentially "pass" is dead and I need two rules, one block, one allow.

[keeka]

I take your point. If on the other hand you have only known ASNs or subnets that you wish to allow, Pass would seem OK. But I am now feeling cautious about mixing Pass forward rules with those requiring explicit filter rules. It starts to feel messy.

[nero355]

This is a bit strange though. Port forwarding is not the same as DNAT.

It's true that DNAT is often used in combination with port forwarding, but that doesn't mean that port forwarding rules should be renamed to DNAT. Hmm, this is rather concerning.

I'm not familiar with other platforms but in OPNsense (at least) DNAT allows to translate both the destination host and/or the destination port.

Both functions in one.

It's better for stuff like this : https://forum.opnsense.org/index.php?topic=9245.0

Because having to "Port Forward" for something like that was indeed a bit weird...



But then again indeed :
It might not be as straight forward as some might like it to be when you are just looking for something as simple as a Port Forward for some application ?!

Oh well...

"You have to break a few eggs to make an omelette!" ;)

[Patrick M. Hausen]

The migration assistant produced one route in the CSV that the import complained about, because the interface does not exist:

Code Select Expand

660d1363-f0e0-4dac-985c-b963552f8e69,1,keep,,211,pass,1,0,enc0,in,inet,any,,,,,0,0,0,0,0,,,,,,,,,,,,,,,,,,,,,,,"allow all IPv4",0,any,,0,any,

Which is correct - I ran an IPsec tunnel once, but replaced it with WireGuard years ago. It's trivial to delete the rule from the CSV, then import, but how am I going to delete "all legacy rules", anyway? Do I really need to click on every single interface and remove every single rule? And how do I get at that enc0 rule?

If I have to edit the XML to remove that enc0 rule, anyway, I'm possibly better off using vi to remove everyting ;-)

What do you think/recommend?

Kind regards,
Patrick

EDIT: ah ... the "Remove all legacy rules" in the assistant is functional, not only documentation. OK, trying this first, then I can check the XML for leftovers.

EDIT^2: Looks good, no legacy rules.

EDIT^3: The migration turns an '&' in a rule description - a 7 bit ASCII character - into '&' Eager HTML escape.

[tessus]

Because having to "Port Forward" for something like that was indeed a bit weird...

Yep, I've thought about it for a while and I think the renaming makes sense in this case. The Port Forwarding UI in OPNsense always allowed to do things that are actually DNAT, so all is good.

My "outcry" came from the fact that I actually only used port forwarding rules, thus my previous opinion about the renaming of this item was wrong.