About "CPNotEnoughDataForRuleMatch" and connection reset

[JPR]

Hi there,

I've (partly) asked about this before (https://community.checkpoint.com/t5/Security-Gateways/quot-CPNotEnoughDataForRuleMatch-quot-and-quot...), but now I have another related question regarding this behvavior.

I have a service that connects to an external ip address, but every time the connection gets terminated by a reset from the destination. The log in my firewall says "Accept", however, it is getting  "terminated before the Security Gateway was able to make a decision: No SSL applicative data."  ("CPNotEnoughDataForRuleMatch").

As I got told in my other post (see link above) the behavior is by design and expected, however, I do have a question to why it happens.

The connection in question gets HTTPS Inspected and the log is as follows:

And the "Accept" ("CPNotEnoughDataForRuleMatch") log looks as below:

I tried to establish the connection with a Wireshark running on the client (not the firewall) and as far as I can see the handshake completes, but then it gets disconnected by a reset from the destination:

I have the same service on another endpoint WITHOUT HTTPS Inspection and there it connects fine.

So my question is: Is it possible that the packet somehow gets "malformed" in the HTTPS Inspection process and therefore the destination sends a reset back to us and kills the connection? Or is something different going on? I really can't figure it out!

Looking forward to your comments 🙂

Thanks!

[Lesley]

The error states there is no data in the connection, that is true according to the capture so the error is valid. 
You state without https inspection connections it works so we should focus on that. Could start is to see if the chosen encryption ciphers are accepted on both sides. In the capture the source is the fw right? That is starting with syn?

[JPR]

No, that's the client. I haven't done a capture on the firewall.

It seems like the Handshake and thus cipher suites goes through and it is after that, that the destination endpoint sends a reset packet. I just can't figure out why.

And again if I bypass HTTPSi it works, so my theory was that it had something to do with that...

[PhoneBoy]

Like @Lesley said, you should check from the gateway (specifically from the gateway to the remote site) with tcpdump.

[the_rock]

Check out below links, hope it helps. In short, this is literally never CP issue, as 3 way handshake is not completing, but its not because of the fw, but rather the fact that server did not send back syn-ack.

Andy

https://community.checkpoint.com/t5/Security-Gateways/quot-CPNotEnoughDataForRuleMatch-quot-and-quot...

https://community.checkpoint.com/t5/General-Topics/When-does-CPEarlyDrop-occur-with-ACCPET-action/m-...

[JPR]

I just don't understand why it then works if I bypass HTTPSi... 😞

[the_rock]

But then it sounds like its httpsi issue...

[the_rock]

Now that I think about it, say if you have httpsi enabled, you can always add bypass rule for affected IPs/destinations.

Andy

[JPR]

Yeah, you're right.

Are there any way of troubleshooting that myself or should I involve TAC? And is it okay to bypass destinations that causes problems? Obviously, it wont perform HTTPS Inspection on traffic between whatever source and destination hosts I have defined, but is it a known issue that HTTPSi in some situations will break the connection? It is not a general problem, but I do experience it occasionally.

Thanks.

[the_rock]

Yea, you said it exactly how I would put it. Not a generic problem, but it happens from time to time. Well...if destination causes problems, then I would NOT bypass it, better to involve TAC. However, if it does not cause issues, I would do it.

Andy

[JPR]

Well, it happens all the time for this specific destination and for now I have just created a bypass rule for it. I will consider getting TAC involved.

Thanks 🙂

[the_rock]

sounds good!

[Lesley]

Focus on checking HTTPS inspection part, not the CPNotEnoughDataForRuleMatch error. 

HTTPS inspection can go wrong between client <-> FW or FW <-> remote server

Mismatch in ciphers but also CA that is not up to date on FW.