Default drop although last rule is "reject any any any"

I understand that using "any" in allow rules can be dangerous if you don't know what you are doing.
But my problem is with reject/drop rules, so using ANY there should be LESS dangerous than INTERNET, no?

But anyway, I did a litte test.

First rule:
Source ANY, service ANY, target ANY, action DROP + LOG.

Second rule:
Source ANY, service ANY, target "all extern" (a network group consisting of all external UTM addresses), action DROP + LOG.

Result: The first rule is never triggered for incoming packets, regardless whether I try to connect to IPs that have a NAT rule somewhere or not. It's always the second rule that is logged. (The first rule IS triggered for outgoing packets, though). Switching the source to INTERNETv4 did not change a thing. Adding "all extern" as target made it work.

This behavior is consistent on the two UTMs that I can play around with.

Now I'm confused :-/

I understand that using "any" in allow rules can be dangerous if you don't know what you are doing.
But my problem is with reject/drop rules, so using ANY there should be LESS dangerous than INTERNET, no?

But anyway, I did a litte test.

First rule:
Source ANY, service ANY, target ANY, action DROP + LOG.

Second rule:
Source ANY, service ANY, target "all extern" (a network group consisting of all external UTM addresses), action DROP + LOG.

Hi, 

This is fine.

FYI, if you had a firewall without NAT, you would see hits on the first rule, for the internal addresses.
With NAT, that doesn't happen and you need your second rule if you want to change the default drop to something else.

Barry

if you had a firewall without NAT, you would see hits on the first rule, for the internal addresses.
With NAT, that doesn't happen and you need your second rule if you want to change the default drop to something else.

So the behavior of the ANY object changes as soon as I have a NAT somewhere, regardless of which interface it's on?

If so, what's the rationale behind that? I already mentioned I find that unintuitive, but the more I think about it, it's potentially dangerous as well. If enabling a NAT somewhere changes the existing allow/deny logic without the user touching any of the rules...

So the behavior of the ANY object changes as soon as I have a NAT somewhere, regardless of which interface it's on?

Hi,

No, the behavior doesn't change; but your network changes.

The firewall interfaces addresses are NEVER affected when you have a rule with ANY as the destination.

What I was saying is that if you have public IPs internally, they would be affected by the ANY rules.
If you're using NAT, you have no public IPs except the firewall IPs.

Barry

So the behavior of the ANY object changes as soon as I have a NAT somewhere, regardless of which interface it's on?

Hi,

No, the behavior doesn't change; but your network changes.

The firewall interfaces addresses are NEVER affected when you have a rule with ANY as the destination.

What I was saying is that if you have public IPs internally, they would be affected by the ANY rules.
If you're using NAT, you have no public IPs except the firewall IPs.

Barry

The firewall interfaces addresses are NEVER affected when you have a rule with ANY as the destination.

Got it, thanks for the patience. So I'll put my "all extern" object anywhere where I have just ANY now. (I have both NAT and "internal" public IPs, so the external addresses alone are not enough.)

Just curious now: Does anybody know the reason for that design decision? I still maintain that calling something ANY and then having implicit and invisible exclusions to that is not intuitive.