- Products
- Learn
- Local User Groups
- Partners
- More
CheckMates Fifth Birthday
Celebrate with Us!
days
hours
minutes
seconds
Join the CHECKMATES Everywhere Competition
Submit your picture to win!
Check Point Proactive support
Free trial available for 90 Days!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
The 2022 MITRE Engenuity ATT&CK®
Evaluations Results Are In!
Now Available: SmartAwareness Security Training
Training Built to Educate and Engage
MITRE ATT&CK
Inside Check Point products!
CheckFlix!
All Videos In One Space
I want repeat what was already written elsewhere is this community:
That design decision on how CP calculuates its own encryption domain for IKE phase 2 handshakes (IPsec SA) is just a mess.
It was always a mess (just remember that old implied supernet calculation "feature") and as this sk shows, it is still a mess after the improvement for R80.40 shown here was introduced.
When comparing to competitors, it is really hard to do 3rd party VPNs with this design. Not all 3rd parties are cooperative and agree to a subnet which works for you on your CP side.
You still have to hack vpn.def file to get simple thinks working like showing 10.0.0.0/24 to one 3rd party peer and 10.0.0.0/16 to another.
I guess many other people who have to handle a large amount of 3rd party Site-to-Site-VPNs on a CP gateway would agree with me, that CP R&D really should think this over again.
It should not be hard for customers, to specify exactly which encryption domains a CP gateways offers during IKE phase 2.
Our customers and we were happy when we saw the improvent for R80.40 beeing anounced 2019 (or early 2020), but the limitation now shown in the sk was a sad surprise.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY