Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
David_Herselman
Advisor

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

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:

r81.10_no_longer_matches_broadcast.png

Associated network object:

network_object.png

 

Regards

David Herselman

0 Kudos
8 Replies
Chris_Atkinson
Employee Employee
Employee

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?

CCSM R77/R80/ELITE
0 Kudos
David_Herselman
Advisor

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:

Check_Point_Rule.png

 

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:

CP_trusted_clients.png

 

 

Regards

David Herselman

Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
David_Herselman
Advisor

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

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
Naama_Specktor
Employee
Employee

@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
Advisor

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

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 .

 

YosiHavilo_2-1675679808255.png

 

 

 

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 .

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events