Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Cypress
Contributor
Jump to solution

Encryption Domain and co-existing Domain Based and Route Based VPNs

I know sk109340 addresses this exact issue, but I am still a little confused about the topic after reading it.  The use of Empty Group Object in encryption domain is an confusing matter to me.  This is the scenario I'm facing.

I have a pair of Cloudguard HA Cluster virtual gateways, and they have a couple Route Based site-to-site VPNs set up, with Virtual Tunnel Interfaces (VTIs.)

An Empty Group Object is created in the policy and that same Empty Group Object is being used as the Encryption Domain on both the Interoperable Device remote gateways, and the on the local Gateways.  Everything is working with this configuration.

Now I have to set up a new VPN on this Cluster, to a different peer, that will be a Domain Based VPN (from what I understand, this basically just means a VPN without Virtual Tunnel Interfaces, and without the "Internal Clear" stuff in the policy rule.)

 

I believe what has to be done is removing the Empty Group Object from Encryption Domain of the local gateway, putting a new Group Object in as the Encryption Domain with the endpoints the new Domain Based VPN peer will be reaching to, and leaving the Encryption Domain of the Existing Route Based VPN Interoperable Objects as the Empty Group Objects.

My biggest concern is provisioning this new VPN without causing the existing ones to stop passing traffic.  I don't like the possible scenario where after installing policy, the existing VPNs may start getting "according to policy we shouldn't decrypt the traffic" since I changed that local Encryption Domain to not be an Empty Group Object any more.

My lack of understanding about using an Empty Group in Encryption Domain is causing some doubt.  Is there a good resource that explains why Empty Group is used in Check Point and what the difference is between using an Empty Group or a non empty one for Encryption Domains?

0 Kudos
1 Solution

Accepted Solutions
Lesley
Leader Leader
Leader

Is it not better to make one VPN community that will be domain based and use user defined encryption groups on both sides?

Just define the encryption domains in the community itself in that way you can leave the empty group

-------
If you like this post please give a thumbs up(kudo)! 🙂

View solution in original post

(1)
7 Replies
the_rock
Legend
Legend

I think if you read what @Bob_Zimmerman said in this post, it will make lots of sense.

Best,

Andy

Btw, personally, I ALWAYS put empty groups for both enc domains for route based tunnels, NEVER had an issue 🙂

 

https://community.checkpoint.com/t5/Security-Gateways/Unnumbered-VTI-to-3rd-party-gateway/m-p/137319...

(1)
Lesley
Leader Leader
Leader

Is it not better to make one VPN community that will be domain based and use user defined encryption groups on both sides?

Just define the encryption domains in the community itself in that way you can leave the empty group

-------
If you like this post please give a thumbs up(kudo)! 🙂
(1)
the_rock
Legend
Legend

That would work, for sure.

Andy

0 Kudos
Cypress
Contributor

Thank you, this worked great.. I did not know per-community domains was an option.  Very useful.

the_rock
Legend
Legend

Screenshot_1.png

0 Kudos
Timothy_Hall
Legend Legend
Legend

Leave the empty group defined as the VPN domain on your gateway object and the objects representing your route-based peers.

However on the Participating Gateways screen of the VPN Community object for your domain-based VPN, override the VPN Domain definition for your gateway and the object representing your domain-based peer.  Try to make these defined VPN Domain overrides as specific as you can; they should exactly match whatever rules you have permitting the traffic to/from that tunnel.  This will minimize the chance of disrupting your existing route-based VPNs.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
(1)
Cypress
Contributor

This is what we ended up doing, thank you.  per-community domain configuration.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events