I'm hoping to understand the motivation behind an apparently undocumented change in behaviour, or that tier 1 simply isn't understanding the case we logged with TAC. I simply can not find the change in the list of resolved issues for R81.10 JHA updates:
The problem we are experiencing is that a rule setup to allow connections from a /29 subnet object no longer matches the first and last IPs in that subnet. TAC is telling me that the first and last IPs are reserved for the network and broadcast IPs and that this behaviour was changed on purpose.
My understanding is that whilst this may be a good idea when validating user input in Gaia, when configuring an interface, but that routing and firewall references should match the number of bits in the IP when converted to binary. In the above example, where the subnet is /29, it essentially means that it should match the first 29 bits of the object's defined IP.
It is, in my humble opinion, perfectly normal to match traffic to ANY IP covered by the network object, not somehow exclude the first and last IPs in that defined network.
We have a network object configured as 192.168.1.0/29, referenced as the source in a rule. IMHO, this should match traffic originating from 192.168.1.0, 192.168.1.1, through to, 192.168.1.7.
What's happening though since R81.10 JHA 81 is that traffic no longer matches this rule but doesn't match any subsequent rules either. It simply doesn't appear in any logs but traffic can be seen being dropped when running 'fw ctl zdebug drop | grep 192.168.1.7'.
Take the case where a security gateway may have its internet uplink configured to use a /29 subnet, in that case one can only configure 5 usable IPs on the interface. If one however then routes an additional /29 subnet towards the security gateway one could, on every firewall I've ever used including previous versions of R81.10, NAT traffic to any of the IPs in the additional subnet (yes, making use of all 8 IPs in the additional /29 prefix).
Was this behaviour really changed?
If so, is there a SK or change log entry describing the motivation therefor?
Is there a way we could disable this new behaviour?
Why would packets match the rule but not match the rule at the same time?
In the follow zdebug example, from a gateway running R81.10 JHA take 81, a network object was configured to allow access to the destination. The source is defined as .224/29, where IMHO this should match .224, .225, .226, .227, .228, .229, .230 and .231. The result is however that the connection doesn't generate a log in SmartConsole at all, only being visible in a tcpdump or zdebug:
Associated network object: