3rd party VPN/Invalid ID information/No valid SA (Summary subnet sent)

Scenario 1 – Wrong IPsec IDs are negotiated during IKE Quick Mode:
Symptoms:
“Invalid ID information” log in SmartView Tracker when the Security Gateway initiates a Quick Mode.
“No valid SA” logs in SmartView Tracker when creating IPsec VPN tunnel with an interoperable device.
Remote Access Client cannot access internal resources over the Site-to-Site tunnel with 3rd party VPN peer.

Explanation:
VPN tunnel can be initiated from 3rd party side to the Check Point Security Gateway side, but not from Check Point side to 3rd party side.
During IKE Quick Mode negotiation, the IP addresses, which define the VPN tunnel (also known as IPSec IDs, or traffic selectors) are negotiated. The IP addresses can be a set of discrete IP addresses, or a subnet.
When negotiating a VPN tunnel between Check Point Security Gateway and certain 3rd-party devices, IKE Quick Mode may fail, if the subnets are defined differently on each end of the VPN tunnel. One reason is that Check Point Security Gateway dynamically supernets subnets to reduce the amount of SA overhead.

Solution:
Define the IP ranges that the Check Point Security Gateway should negotiate with this 3rd party peer in the “subnet_for_range_and_peer” table in the relevant “user.def” file on the Security Management Server / Domain Management Server.

The “subnet_for_range_and_peer” table is designed to force Check Point Security Gateway to negotiate IPsec SAs using a specific subnet mask for a given IP address range:

subnet_for_range_and_peer = {
<peerGW_IP, first_IP_in_range1, last_IP_in_the_range1; subnet_mask>,
<peerGW_IP, first_IP_in_range2, last_IP_in_the_range2; subnet_mask>,
… … …
<peerGW_IP, first_IP_in_rangeN, last_IP_in_the_rangeN; subnet_mask>
};

Location of user.def file on the management:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239