Problem with access to WebService

[Matlu]

Hello, everyone.

We currently have a Cluster R81.10, in which we are having problems consuming a web service, which is on the Internet.

The destination is the IP 38.43.137.39 (tied to the domain (apostillaconsulta.rree.gob.pe).

In the logs, I see the following.

I do not see "dropped" packets in the logs,
What I see are "Accepted" packages, but when I check the LOG, it sends me to check the sk113479.

My question is "why"?

Has anyone had any similar experience?

It is worth mentioning that on top of the Firewall Cluster we have, we have an AntiDDos service in the cloud.

Can the AntiDDos be the cause of my client's network having the experience that the web service "does not load"?

Greetings.

[the_rock]

Hey bro,

I remember working with customer once and TAC T3 guy was on the phone and we encountered exact same issue, related to same sk you provided. Its essentially fancy way of telling you its NOT cp issue lol

Anyway, that time, turned out to be some service running on the other end that was preventing the connection.

Andy

[Matlu]

I have read the contents of the SK, and it is clarifying the doubts, but I have a concern, with the famous "CPNotEnoughDataForRuleMatch".

This, can it be an "informative" message only?

I have working separate layers, FW layer + APPC&URLF layer.

And at least the log, when I open it and check, in the APPC&URLF layer, it "matches" with the CPNotEnoughDataForRuleMatch message.

[the_rock]

Im not 100% sure of the meaning of that message, but Im fairly certain it simply implies that 3-eay handshake is not completing. SYN-SYNACK-...nothing

Andy

[Chinmaya_Naik]

Hi @the_rock and @Matlu 

This is the same details:

We have 12 cluster where in the most of the policy packages we follow the below layer wise rule:

Layer 1: Network Rule
Layer 2: Application and URL Filtering Rule
Layer 3: Content Awareness Rule

This is the below rule we configured in the one ABC Policy Package

In Layer 1 Rule: Source:Any Network Objest,Destination:Any,Service:Any,Action:Accept
In Layer 2 Rule: Source:Any ,Destination:Any,Service:All Services Object(PORT:80,443,x),Action:Accept
In Layer 3 Rule: Create rule as per the compliance

When we try to access the URL:https://gem.gov.in/(IP:14.140.34.123) then we able to access the URL from one cluster but unable to access from the another cluster.

FInd the below details the we get:

In Layer 1 Rule: Implict Cleanup Action:Accept
In Layer 2 Rule: CPNotEnoughDataForRuleMatch Action:Accept
In Layer 3 Rule: CPNotEnoughDataForRuleMatch Action:Accept

Now my question is that if the Default gateway is not the Checkpoint firewall then I check the internal L3 devicesand analyze the traffic  but if my source machine L3 is checkpoint firewall then still issue come or not? (My answer is YES)

Also as final what is the solution recommendation?

My one plan is to create a rule on top and check the status. (Correct me If I am wrong)

Regards

@Chinmaya_Naik 

[the_rock]

There has been MANY posts about cpnotenoughdata message. In short, 99% of the time its NOT Check Point issue...essentialy, even if you read the sk about it, long story short, it pretty much tells you that firewall does not have enough data to pass that connection forward.

See below, hope this helps.

Andy

https://community.checkpoint.com/t5/Security-Gateways/CPNotEnoughDataForRuleMatch/m-p/198942#M37254

[Chinmaya_Naik]

Thank you  @the_rock 

But rule base optimization can resolved this issue?

But as per my search also "Firewall does not have enough data to pass that connection forward"so its not a firewall issue right?

But after some hour its automatically resolved why?

We also enable the HTTPS inspection but my understand that HTTPS inspection is not the cause because other URL is acessable.

Some situation wher the Outlook Application is work properly but access through browser is not work getting the message "CPNotEnoughData" or some cluster "CPEarly Drop".

Please help me I need to understand echnically then its Great.

Regards

@Chinmaya_Naik 

[the_rock]

You can try that, but cant guarantee it will work, as usually that message indicates firewall is NOT dropping anything.

Andy

[PhoneBoy]

The only way to avoid this issue entirely is to ensure the relevant traffic is accepted on a service that a simple TCP service early in the rulebase.
That points to rulebase optimization.

Consider the following rules and assume BackupServer is located in the ServerZone:

A connection from InternalZone to BackupServer can be matched on the first packet because the service HTTPS is used.
HTTPS is a simple TCP service.
Other traffic to the ServerZone (even "Web Browsing") requires multiple packets to correctly identify, thus is Accepted.
If the connection from InternalZone to ServerZone terminates BEFORE this identification can be done, the traffic is accepted with the message CPNotEnoughDataForRuleMatch.

For CPEarlyDrop, it means that only drop rules matched when the connection is evaluated against the rulebase based on source/destination/service.
Note that rules for applications with an action of Drop apply on all ports (even if the application itself doesn't specify the specific port).
There an example of this in sk: https://support.checkpoint.com/results/sk/sk111643

None of these are problems, but expected behavior.
The behavior can be eliminated through proper rulebase (re)construction.