VPN with source-NAT to 3rd party

[NorthernNetGuy]

I'm tryign to set up a VPN tunnel with a 3rd party and want to make sure i'm setting things up and understanding the checkpoint side correctly. The 3rd party provided us with a short list of subents that we can use for encryption domain, so we picked one and are opting to NAT to the desired IP range.

encryption domains are as follows (Example IPs):

Local Encryption domain:

Source Subnet: 10.10.1.0/28

Translated Source: 10.20.1.0/28 (using automatic NAT rules for the included host objects)

Peer encryption domain: 10.100.1.0/28

With the policy-based vpn (1 tunnel per subnet), do I need to include the original source and the translated source in our encryption domain? if so, does the 3rd party also need to have both included on their side too? and is there a way around this so that the tunnel will be formed without their need of including both?

Thank you!

[the_rock]

I would say yes, you need both in the enc domain. Well, you can test without them including both on their end, but I doubt it may work. Depending on the error you get, you will have a pretty good idea if thats the issue.

Andy

[Lesley]

I would see both real IP and NAT pool in enc domain and the other side should only configure NAT pool. If they also have to add the real IP then there still could be overlap and the NAT is useless 🙂 

[NorthernNetGuy]

I agree, I'm hoping thats the correct set up, otherwise I can't use NAT in this method.

I know I need to have the pre-nat IP in our encryption domain, as otherwise the traffic will not use the tunnel. Checkpoint flags the traffic as interesting for the tunnel before it is processed by NAT. 

My Concern is that if I include the pre-nat IP's in our encryption domain, and the 3rd party doesnt, then there might not be an exact match of proposed encryptions domains which could lead to issues. If this is the case then I'd need to find a workaround or different solution.

Right now I have the tunnel up but not getting bi-directional traffic. I also spotted a couple logs that indicated an error of " initial exchange: sending notification t peer: Invalid Key Exchange payload" and am awaiting further information from the 3rd party and have a maintenance call scheduled tomorrow.

[the_rock]

You can also do basic vpn debug on CP side to see if errors are similar. Im fairly positive it would be related to phase 2.

Andy

[Networksecurit1]

Did you get the resolution ?

[Duane_Toler]

You need both in YOUR VPN domain on your gateway.  I would suggest using encryption domain per community for this.  The remote peer only needs to use your NAT translated IP/subnet in the VPN domain representing your site.