S2S VPN issue with 3rd Party VPN gateway

[Nandhakumar]

Hi,

We have site to site VPN tunnel build with our vendor. Our gateway is Checkpoint R80.40 and remote gateway is Cisco ASA. Now the issue is, In remote side if they create Access list with specific source IP address, Destination Network and specific ports and protocol, the VPN connection initiated from our side fails on remote side gateway. Vendor side gateway not accepting our proposal because of we are negotiating connection with 'Any' ports and protocols but they allowed specific ports on their side. If they allow 'Any' ports and protocols on their side, connection will work without any issues. 

Considering Security importance in mind, they are insisted us to use with specific ports and protocols.

Kindly some expertise can help me here, how can we negotiate with specific ports and protocols during phase 2 negotiation?

[Timothy_Hall]

I don't believe this level of granularity is possible as the Check Point negotiates what will be legal in IKE Phase 2 as subnets with all ports and protocols allowed.  The Cisco side will need to accept all ports and protocols for the subnets in the "interesting traffic" ACL associated with the VPN tunnel, but then explicitly specify what is allowed into the network after decryption in a separate ACL.  There may well be some kind of secret *.def file hack that enables the Check Point to negotiate ports and protocols along with the subnets for a certain peer, but I'm not aware of it.  I can't imagine this is the first time something like this has arisen, so it might be worthwhile to have your Check Point SE (not TAC) check with the Solutions Center to see if they have some existing special code that can accomplish this.

It is a bit of a philosophical difference, as far as what will be considered "legal" in the tunnel for IKE negotiation purposes vs. what is actually allowed by the security policy.  Kind of like setting up an automatic static NAT which NATs all 65,535 possible ports from one IP address to another, but then controlling which specific ports are allowed to/from that IP address separately in the Network/Firewall policy layer rules.

[PhoneBoy]

I ran into this exact issue configuring an interoperable VPN with a Cryptocluster device back in the day.
The only service definition accepted on the Check Point side of an IKE negotiation is “any.”
Not aware of a way to change this.

[the_rock]

With all respect, I totally disagree with responses you got here. I did this many times with specific services and I never had a problem (different vendors...PAN, cisco, fortigate). What specific error do you see? Message me privately, happy to do remote and see if we can fix it.

Andy

[PhoneBoy]

It depends on how you define those "specific services" in the 3rd party VPN.
The issue is specifically with the IKE Protocol, which can be configured to negotiate the specific ports/services that are allowed over the IPSec tunnel.
Check Point allows for IPs/subnets to be negotiated, but only supports the use of "Any" port/service as part of this negotiation.
To my knowledge, there is no way to change this.

[Nandhakumar]

Hi,

Please see below rejection log in remote side gateway, which is cisco ASA.

Mar 22 13:17:18 [IKEv1]Group = A.A.A.A, IP = A.A.A.A, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy X.X.X.X/255.255.0.0/0/0 local proxy Y.Y.Y.Y/255.255.255.255/0/0 on interface outside

A.A.A.A ----> Checkpoint Gateway External IP address
X.X.X.X -----> Source Network (X.X.X.X/16)
Y.Y.Y.Y ------> Destination IP (Y.Y.Y.Y/32)

Here it negotiates port and protocol as Any i.e., 0/0 in the above log.

[Timothy_Hall]

That is expected behavior and you can't change how the Check Point proposes port and portocol, unless the Solution Center has something.  Your question has already been answered.

[Nandhakumar]

Was it normal Checkpoint TAC? How can we reach out Solution Center?  Can you guide me?

[Timothy_Hall]

Contact your local Check Point SE, they can get you in touch with the Solutions Center.

[the_rock]

That looks more like the vpn subnet issue, rather than the service itself though...

Andy

[Nandhakumar]

For sure its not VPN subnet issue. As both sides we allowed same network subnet mask.

[the_rock]

You might be correct, but just going based on the error you provided previously in the thread. If you do debug on CP side, where exactly is it failing in ike.elg? Phase 1 or 2? Which packet?