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

Thanks for your explanation and the link - that makes much more sense to me than the "Internet"  vs. "Any" proposition. (Not saying Bob is wrong, I just could not understand him.)
So basically as soon as I use an address in NAT somewhere, it ignores/bypasses all firewall rules for its un-NATed state (which includes the Any stuff, because that rule is only active on the INPUT chain)?
Can I see the actually generated rules somewhere?

Hi Chris,

1. you can see all of the rule via the command-line: 
iptables -n -L

2. in case it wasn't clear; the ANY network defintion does not include the UTM's interfaces nor the Network and Broadcast addresses.

I would include those (INT or EXT Address, INT or EXT Broadcast) in your REJECT rule if that's what you want.

Barry

Aha! Yet another idea. Excellent [:)] I'll test this tomorrow.

Does anybody know the rationale behind that? Do I really have to create a network group "really any" consisting of "any" and all the interface addresses on every single device?

Hrm. That was a confusing explanation of the "ANY" object.

The difference between "ANY" and "INTERNET" is simple

ANY is 0.0.0.0/0 , whch equals with any reachable IP address via any of the direct attached interfaces

INTERNET is 0.0.0.0/0 bound to all interfaces having a default gateway which equals anyreachable IP address via a uplink interface, but excludes all "internal" interfaces without def. GW

Simple said:
ANY is dangerous, as for example GuestNET (Network) - ANY - ANY rule allows unrestricted access to Internet, but also to your DMZ, LAN etc.

GuestNET (Network) - ANY - INTERNET rule allows only access to Internet, but disallows access to LAN, DMZ etc.

So general basic rule in UTM: "ANY" is evil. Always well consider, where to use that object...[:D]
[H]

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 :-/

What is in "all extern"?
Host objects with the interface IPs or the native interface addresses?

The native address objects.

Chris, I'm glad you got better explanations.  Now you'll understand what I tried to say in Post #5.  I'll be happy to go back and edit that post or any other of mine that isn't clear at the first reading.

Cheers - Bob

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...