- 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
Hey Everyone I created a technical whitepaper on how to connect and send all traffic through an unnumbered virtual tunnel interface (VTI)
Correct me if Im wrong when I say this, but I always set up route based VPN (in this case either with numbered or un-numbered VTI) with empty enc domain for BOTH CP gateway and 3rd party and it always works.
You only actually need one of them to be empty. The purpose of the empty group for the encryption domain is to break the domain-based logic for flagging "interesting" traffic. That logic says if the source is in my encryption domain and the destination is in a peer's encryption domain, flag the connection for encryption to that peer. This matching is done before any NAT can be performed. By setting one encryption domain to an empty group, either the source isn't in yours, or the destination isn't in the peer's.
That leaves the traffic free to route "out" the VTI, which is what triggers encryption with a route-based VPN.
The encryption domains are also used for a sort of anti spoofing. If you've ever seen "According to the policy, the packet should not have been decrypted", that means the packet was decrypted from a particular peer, but either the source was not in that peer's encryption domain or the destination was not in your encryption domain. Similarly, "Received a cleartext packet inside an encrypted connection" means the packet was received in the clear, but the source is in some other firewall's encryption domain and the destination is in yours, so it should have come over a VPN between those peers. Route-based VPNs' use of an empty group for one or both of the encryption domains means you should never see either of these, though you may still see normal antispoofing drops.
@Bob_Zimmerman ...we tried to make it work that way many times and even TAC could not figure it out, so we finally opted for empty groups on both ends and never had an issue.
Weird. I've set up route-based VPNs with an empty group on only one peer in at least 30 different management domains. It definitely works in general. I wonder what was wrong.
We even worked with escalations team and could not get it working on 3 different tunnels. But as soon as we did empty group on both sides, we never had an issue.
@mbennett1 Is there any reason why you defined 3rd party peer object as "external managed checkpoint gateway" instead of just "interoperabel device"? You even named it "cisco", so I guess it was no CP box 🙂
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY