Received a cleartext packet within an encrypted connection

[ravindra692]

All

I have an L2L VPN tunnel with a Vendor. The vendor has a Cisco Firewall on their end and I am running a Checkpoint VSX GAIA R77.30. The tunnel is working fine, I recently added an inbound traffic flow from Vendor to me. This New traffuc flow includes three Hosts that Vendor targets. For one first everything is fine but for the other two hosts, I am seeing decrypts on my end but at the same time I am also seeing the drops with error "Received a cleartext packet within an encrypted connection". Even after this, the tunnel is working finefor all other traffic flows, I am seeing this error for these two hosts only and I dont understand why.


Any help would be much appreciated.

--Ravi

[ShadowPeak.com]

All

I have an L2L VPN tunnel with a Vendor. The vendor has a Cisco Firewall on their end and I am running a Checkpoint VSX GAIA R77.30. The tunnel is working fine, I recently added an inbound traffic flow from Vendor to me. This New traffuc flow includes three Hosts that Vendor targets. For one first everything is fine but for the other two hosts, I am seeing decrypts on my end but at the same time I am also seeing the drops with error "Received a cleartext packet within an encrypted connection". Even after this, the tunnel is working finefor all other traffic flows, I am seeing this error for these two hosts only and I dont understand why.


Any help would be much appreciated.

--Ravi

Most likely the destination IP address for those two servers they are failing to reach are not part of your own firewall's defined VPN domain. Or the source IP address they are using to initiate the connections to those two servers are not part of the VPN domain of the peer object representing their Cisco; it is also possible that they are incorrectly NATing the problematic traffic on their end to an address your firewall is not expecting before encrypting it into the tunnel.

[Bob_Zimmerman]

Most likely the destination IP address for those two servers they are failing to reach are not part of your own firewall's defined VPN domain. Or the source IP address they are using to initiate the connections to those two servers are not part of the VPN domain of the peer object representing their Cisco; it is also possible that they are incorrectly NATing the problematic traffic on their end to an address your firewall is not expecting before encrypting it into the tunnel.

Other way around. "Received a cleartext packet within an encrypted connection" means the Check Point side is expecting it to be encrypted, but the Cisco side isn't encrypting it. Either the encryption domains are too large or the Cisco-side crypto map is too small.

I occasionally post an explanation of the common drop messages related to VPN domains.

[themadhatterz]

Almost 100% certain this is due to receiving a packet the firewall has already decrypted a second time. Does someone down stream from the firewall have appropriate routing for the two hosts that don't work. Can you capture it and see?

[ShadowPeak.com]

Other way around. "Received a cleartext packet within an encrypted connection" means the Check Point side is expecting it to be encrypted, but the Cisco side isn't encrypting it. Either the encryption domains are too large or the Cisco-side crypto map is too small.

I occasionally post an explanation of the common drop messages related to VPN domains.

Ah yes, the situation I described was "According to the policy, the packet should not have been decrypted". Nice catch.

[Bob_Zimmerman]

Almost 100% certain this is due to receiving a packet the firewall has already decrypted a second time. Does someone down stream from the firewall have appropriate routing for the two hosts that don't work. Can you capture it and see?

This is also a possibility since the VPN decision happens so early in packet processing. Specifically, it would happen if the packet is encrypted on the Cisco side, decrypted by the Check Point side, routed to another device (we're good so far), then routed back to the Check Point device. That is, a routing loop after the decryption. The Check Point box will see that the source is in a peer's encryption domain and the destination is in its own encryption domain, so the packet should have been encrypted.

While in the TAC, I didn't see this as often as I saw simple encryption domain mismatch.

Ah yes, the situation I described was "According to the policy, the packet should not have been decrypted". Nice catch.

Yeah, those two are probably the most specific, but least intuitively obvious errors in the product.