Encryption Domain Questions

[Jeff_Post]

Hi Everyone,

 I have some questions on Encryption Domains.  We often run into problems setting up site to site VPNs, and the solution usually revolves around the encryption domain we have setup for our gateways.  What is supposed to be in the encryption domain that is set for the gateway?  Is that supposed to be our network ip address that other site to site VPNs need to access or should it be ip addresses of resources we need to access on the non local side (other company\partner\etc) of the VPN.

For example, lets say we have the following networks that have resources our partners need to access all defined in the group

Group_Our_Resources:

192.168.1.0/24, 192.168.2.0/24, 10.245.0.0/16, 10.30.22.0/24. 

Our partners will be coming over the site to site VPN from the following ip ranges, which I'll show as groups

Group_Partner_one_incoming

10.203.5.0/24

Group_Partner_two_incoming

10.205.8.0/24

And our partners have the following networks with information we need to access defined by the below groups:

Group_Partner_1_resources:

10.127.2.0/24

Group_Partner_2_resources:

172.28.5.0/24

Group_Partner_3_resources:

192.168.57.0/24

Our encryption domain defined in the gateway under Network Management\VPN Domain\Manually defined is a group called:

Group_Our_Encryption_Domain

What should be in Group_Our_Encryption_Domain?  Is it the group that contains the resources our partners need to access?  Is it the groups that contain the resources located at our partners that we need to access?  Is it both?

I am pretty sure that the encryption domain defined for the interoperable Devices under Topology\VPN domain would be group that contains the networks that our partners will be coming from (ie Group_Partner_one_incoming for Partner 1's interoperable Device, Group_Partner_two_incoming for Partner 2's interoperable Device, etc.)

To add to the mix, if we have a remote access VPN, can we set a separate Encryption domain and would that encryption domain be all the resources we want available over the remote access VPN?  I assume that is possible as there is a set domain for remote access community button in the gateway under Network Management\VPN Domain\

Currently our Group_Our_Encryption_Domain contains every network we have.  This is most likely a by-product of the gateways getting updated from previous devices, and the config just imported in to make sure everything still works.  Add to the mix that there is a second cluster of firewalls in another location that has the same Group_Our_Encryption domain defined so that in the event our internet link in our primary datacenter goes down, we can change DNS to point to the internet link in the secondary datacenter and all our VPNs still work.  The two checkpoint clusters are managed by the same Checkpoint security management server.

Our current version is R80.20 JHF 188. 

Hopefully this isn't too confusing.

Thanks,

Jeff

[Chris_Atkinson]

VPN Domain - A group of computers and networks connected to a VPN tunnel by one VPN Gateway that handles encryption and protects the VPN Domain members. So locally significant, you'll note the default choice in the security gateway properties is "All IP addresses behind Gateway based on Topology information".

R80.40 Security Management and higher provides greater flexibility here:

• Configure different VPN encryption domains on a Security Gateway that is a member of multiple VPN communities. This provides:
  • Improved privacy - Internal networks are not disclosed in IKE protocol negotiations.
  • Improved security and granularity - Specify which networks are accessible in a specified VPN community.
  • Improved interoperability - Simplified route-based VPN definitions (recommended when you work with an empty VPN encryption domain).

[Jeff_Post]

Thanks.  Good to know about R80.40 allowing you to specify different VPN encryption domains.  We know we need to upgrade off of R80.20, just haven't had the time. 

[the_rock]

I strongly recommend R81.10 to all customers now...works very well and its 100% stable.

[Jeff_Post]

That's what our local sales team engineer was recommending as well, R81.10. 

Jeff

[RS_Daniel · Accepted solution]

Hello,

What should be in Group_Our_Encryption_Domain? --> All your local networks that need to go trough the vpn, it includes real IP's and NATed IP's in case it applies. Basically, on the encryption domain you have to include all the networks behind the gateway that need to be encrypted in the vpn. 

the encryption domain defined for the interoperable Devices under Topology\VPN domain would be group that contains the networks that our partners will be coming from --> Yes, that is how it works.

can we set a separate Encryption domain and would that encryption domain be all the resources we want available over the remote access VPN? --> yes

Add to the mix that there is a second cluster of firewalls in another location that has the same Group_Our_Encryption --> I have seen the same scenario with many customers with no problem at all. You can also use CheckPoint VPN HA solution "MEP", but it needs to enable PDP on remote site to monitor connectivity IP reachability.

Take a look to the admin guide so you can understand better how CheckPoint works with VPN domains and MEP:

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_SitetoSiteVPN_AdminGuide/Top...

Regards

[Jeff_Post]

>>Add to the mix that there is a second cluster of firewalls in another location that has the same Group_Our_Encryption --> I >>have seen the same scenario with many customers with no problem at all.

You would think so, but we have been admonished by CP Support more then once about having "overlapping Encryption domains" between the two firewalls.  It has been a while since we hit this issue, but it was probably when we were trying to setup VPNs to the same endpoint from both locations for DR reasons.

>>What should be in Group_Our_Encryption_Domain? --> All your local networks that need to go trough the vpn, it includes real >>IP's and NATed IP's in case it applies. Basically, on the encryption domain you have to include all the networks behind the >>gateway that need to be encrypted in the vpn.

Thanks.  I think we need to look at a redesign in the future, as that group currently has way more then it needs in there.  Moving to R80.40 or higher (I'm assuming the same feature is in R81.10) would allow us to be specific about what needs to get advertised to each VPN community instead of just lumping everything into one group.

[the_rock]

Believe it or not, this questions comes up way more often than one would think. As guys already mentioned, your encryption domain would consist of anything LOCALLY you want to participate in VPN tunnel, so nothing related to the other side, in simple terms.

Andy

[Jeff_Post]

>>Believe it or not, this questions comes up way more often than one would think.

To be honest, it doesn't surprise me.  I find the VPN setup on the checkpoint to be difficult.  Well, the setup is easy.  It is the troubleshooting, turning on debug options, dealing with spoofing false positive issues, getting cryptic .elg files that you need support to read, except for the ike.elg file, that is difficult and time consuming.  I usually dread creating new VPN connections and always finish with the thought that it just shouldn't be this difficult to troubleshoot a VPN connection.

Jeff

[the_rock]

Just my personal opinion, but yes, while set up is easy, debugs can be rather difficult. I find vpn debugs on Fortigate and Cisco to be much easier and more inclusive as far as where the issue lies.

[Jeff_Post]

+1 to that.