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.