- Products
- Learn
- Local User Groups
- Partners
- More
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
Join our TechTalk: Malware 2021 to Present Day
Building a Preventative Cyber Program
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
Be a CloudMate!
Check out our cloud security exclusive space!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
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 🙂
Can you elaborate on configuration of the unnumbered interfaces for a cluster? This part was missing from the PDF. Thanks!
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY