Site-to-Site VPN between Check Point and Cisco ASA

It's a common occurance that we have to configure Site-to-Site VPNs between Check Point firewalls and Cisco devices (ASAs and routers).
But configuring a Site-to-Site VPN in Check Point with a 3rd Party Device is sometimes a bit tricky. This is because the auto-summarisation or supernetting of networks in Check Point end.
When we are creating the Site-to-Site VPN we have to follow these basic steps.

• Enable VPN feature on the Check Point firewall
• Configure the Encryption Domain
• Create an Interoperable device for the remote end VPN terminator
• Configure the Encryption Domain
• Create a VPN Community and configure the parameters for the VPN (IKE, IPSec parameters)
• Configure Firewall rules for the communication

After configuring all these things correctly we will (most of the time) fall into the famous
"No Valid SA when creating IPSEC tunnel with an interoperable device" problem.

According to sk39419:

"The nature of this problem is due to the ability of the Check Point Security Gateway to dynamically supernet subnets to reduce the amount of SA overhead normally generated by VPN traffic. Most third party vendors are inherently static and therefore do not have the ability to understand this dynamic behaviour."

This article also provides 3 possible solutions for this.

But if you just play around with this you will find an interesting behaviour.

This is what I observed when I played with one of the VPNs I had to troubleshoot.

Our Encryption Domain (behind the Check Point Firewall) is a straight forward 10.16.0.0/24 network.
Remote end Encryption Domain (behind Cisco ASA) had three hosts 192.168.1.240, 192.168.1.241. So if I create two host objects for the above two IPs, add them to a group object and configure that group object to be the Encryption Domain of the Interoperable Device, this is what happens.
IKE Main mode completes correctly.
In the Quick mode negotiation the ids are sent as (10.16.0.0/24 - 192.168.0.0/16) from Check Point to ASA.
As the ASA is not configured to accept 192.168.0.0/16 as the id it will not establish the IPSec tunnel.
On solution we can provide (also mentioned in sk39419) is to set "One VPN Tunnel per each subnet pair" option in VPN Commmunity -> Tunnel Management section.
The problem with this is it will increase the number of phase 2 SAs. This is not desired though it solves the problem.

So luckily we can supernet the IPs used for the two hosts to 192.168.1.240/31 (thus following the solution C in sk39419). So we created a Network object (say Net_remote_enc_domain) with IP address 192.168.1.240 and net mask 255.255.255.253 and added it to the encryption domain of the Interoperable device.
It worked.!!! :)

But later, there was a requirement to add an additional host to remote end's encryption domain - 192.168.1.218.
If we are to have a supernet to the three hosts, eventually we will be adding 64 hosts to the encryption domain. This was not desired from the remote end.
Still we are following the solution C of sk39419:
"Change the encryption domain of the Security Gateway to use a specific subnet instead of using hosts or groups. This will stop the Check Point Security Gateway from supernetting hosts since they now are part of a subnet which has been manually defined."

Now I wanted to play around a little bit.
First I created a group object (grp_remote_enc_domain), added the network object Net_remote_enc_domain (which is 192.168.1.240/31) and host object (say remote_host3) with IP 192.168.1.218, and configure it as the encryption domain to the Interoperable device (i.e. the remote end VPN terminator)

Note: We were informed that there are two ACLs created in the ASA end matching 192.168.1.240/31 and 192.168.1.218/32

I enabled ike debugging in out Check Point firewall (using vpn debug ikeon) and initiated traffic from our end.
First to 192.168.1.240, then to 192.168.1.241 and finally to 192.168.1.218.
The first two communications were successfull, but the final one failed.
When I examined the ike.elg using IKEView, I observed the following phase 2 IDs being exchanged
(10.16.0.0/24 - 192.168.1.240/31) - completing Quick mode
(10.16.0.0/24 - 192.168.0.0/16) - Quick mode failed

So I came to a conclusion that when ever a host object is encountered in the Encryption Domain it Check Point will try to summarise or supernet the IP address.
So what I did was instead of the host object, created a Network object with /32 prefix length.
Net_remote_host2 (with IP address 192.168.1.218 and net mask 255.255.255.255).
So now grp_remote_enc_domain group object has two members:
 - Net_remote_enc_dmoain
 - Net_remote_host2

Saved the policy and installed it in the gateway.
Now when I initiate the traffic (with ike debug on) it WORKED!!!!!!! for the three remote hosts.
When I examined the logs there were two ids negotiated (thus 2 SAs created).
(10.16.0.0/24 - 192.168.1.240/31) for 192.168.1.240 and 192.168.1.241 hosts
(10.16.0.0/24 - 192.168.1.218/32) for 192.168.1.218 host.

So I didn't have to go with editing objects_5_0.C and change the variable ike_use_largest_possible_subnets to false
or
Configure the "max_subnet_for_range" table in $FWDIR/lib/user.def on the management console (SmartCenter)

We don't like to have the above two options because will be not visible in the Dashboard and eventually if it is not well documented the future firewall admins will loose track of it.