R81.10 JHA take 81 - Network objects no longer work properly since new JHA

[David_Herselman]

Hi,

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:

https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/R81.10/R81.10-List-of-all-Resolved-Issues.htm

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.

For example:

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:

Regards

David Herselman

[Chris_Atkinson]

To my knowledge this fundamental matching logic should not have changed (sounds like a bug or other issue).

Are you able to share the corresponding rule screenshot that the traffic should match?

Also how does the referenced rule 17 look?

[David_Herselman]

Hi Chris,

The zdebug example above is from a MDS managed security gateway were rule 9.9 (so 8 + 9 = rule 17) is configured to use a network group where this in turn includes a network object for .224/29:

This problem also occurs when configuring 'Trusted clients' to define an allowed IPv4 Netmask as the source. The following is from another non MDS deployment where R81.10 with JHA take 81 does not allow access unless we reconfigure the allowances to make use of an IPv4 Address Range where we can then stipulate the starting and ending IPs:

Regards

David Herselman

[Chris_Atkinson]

Thanks David, will enquire internally and revert but please continue to pursue it with TAC and your SE in parallel.

[David_Herselman]

Much appreciated!
By the way, this also affects R80.40 with JHA take 180

[Chris_Atkinson]

Noted. Can you please share the SR number with me in private for follow-up?

[Naama_Specktor]

@David_Herselman 

Hi David , 

My name is Naama Specktor and I am checkpoint employee ,

I will appreciate it if you will share SR# with me, here or in PM,

Thanks ,

Naama 

[David_Herselman]

Thanks guys!

Herewith the SR from December, affecting R81.10 with JHA take 81:
6-0003495893

Herewith the SR from yesterday, affecting R80.40 with JHA take 158:
SR6-0003531775

[YosiHavilo]

Hi

When you define network with netmask / 29

And the broadcast is included , the rulebase matching code add the ranges  to the correct cell .

For example 192.168.1.0/29 was added to rule 1 source .

We add ranges 192.168.1.0 - 192.168.1.7 to the source of rule 1 .

This behavior did not change in R81.10 .

When you have security zone in the destination ,

The code call function that get the interface based on routing and according to the destination ip.

We need to  understand what will be the interface for the outbound connection ,  so we can understand what zone associate with this interface (this is done before the actual rule matching ).

You put the errors that indicate that we failed to understand what is the out interface .

Because you describe a problem in the source,  this error is confusing, because it is not related to the source ip,  but to the destination ip  and the routing that you have .

What I suggest :

Check the destination ip and see that you have a routing for this destination .

(in this calculation we consider NAT – so if you have static nat on this destination we will check the routing after the NAT )

If you still have problem , please open a task with the support

Once you have the task number,  send me the task id so I can be involved .

If we like to understand why the function that get the interface according to the routing failed  , we need kernel debug with route flag .

fw ctl debug -buf 32000

fw ctl debug -m fw + vm drop route

fw ctl kdebug -f >& debug.txt &

to stop

 fw ctl debug 0

if the problem is related to the rulebase matching and it is not related to the zone calculation error that you put ,

We need to get rulebase matching debug – I will provide the debug plan in case this is the problem .

Best regards .