- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
I have a weird outtage today where somehow the licensing on my cluster got all out of whack. I've fixed it and cluster is now all green.
However what I now notice is that ICMP to a Remote Office is broken as soon as I have a community setup on the CP side.
Checkpoint Public IP: x.x.x.x
Checkpoint VPN Encryption Domain: 10.10.171.0/24
Remote peer Public IP: z.z.z.z
Remote Peer Encryption Domain: 192.168.1.0/24 and 192.168.11.0/24
As soon as I configure this community (star or mesh), z.z.z.z can no longer ping x.x.x.x
Checkpoint logs report "Clear text packet should be encrypted".
I went as far as blowing out all the VPN communities, disabling IPSEC VPN. Pushing policy. Then reenabling and readding the community. I'm rather confused, as I know for a fact before this used to be fine.
On top of this, Checkpoint Mobile stopped working entirely.
"Clear text packet should be encrypted" means a packet was received that was not encrypted that, by policy, should be.
That points to a configuration error.
sk108600 Scenario 3 is the main issue here (the fact the gateway IPs are always included in the encryption domain).
The fact you're getting this error in the remote to local direction implies the remote VPN peer is managed by a third party and is most likely a third party device.
To resolve this, you will need to have the remote end change the configuration to include their peer IP as part of their encryption domain OR apply the fix described in sk108600.
If both ends of the VPN are gateways managed by the same management and you're experiencing this, it might be worth a TAC case.
The Check Point Mobile issue is something completely different, most likely.
Please start a new thread related to this issue with appropriate details about this issue (error messages, exact version/JHF used, etc).
sk108600 - scenario 3?
Did this work on a previous version or the same?
The same gateways and versions didn't change and that is whats confusing.
I've certainly never modified the file in that sk for scenario 3 before.
"Clear text packet should be encrypted" means a packet was received that was not encrypted that, by policy, should be.
That points to a configuration error.
sk108600 Scenario 3 is the main issue here (the fact the gateway IPs are always included in the encryption domain).
The fact you're getting this error in the remote to local direction implies the remote VPN peer is managed by a third party and is most likely a third party device.
To resolve this, you will need to have the remote end change the configuration to include their peer IP as part of their encryption domain OR apply the fix described in sk108600.
If both ends of the VPN are gateways managed by the same management and you're experiencing this, it might be worth a TAC case.
The Check Point Mobile issue is something completely different, most likely.
Please start a new thread related to this issue with appropriate details about this issue (error messages, exact version/JHF used, etc).
Thanks. I will try adding the peer IP.
That worked. Thank you.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 19 | |
| 17 | |
| 14 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY