IPSec VPN between Fortigate 60C and Checkpoint R76

[Kong_Tan]

I have a FG 60C on my side and the VPN is setup using " Policy-Based" as the vendor using the CheckPoint does not support NAT. The VPN seems to be working from my side and I can ping the remote network. For some reason, they cannot ping my network. Every time they tried to ping my network, VPN event log showed a bunch of IPsec phase 2 failure during negotiate. They claimed that the issue is on my side. Any suggestion what I can do to narrow down this issue. Thanks for all the help.

[AndreaSoliva]

Hi that CP is not supporting NAT is not right. This means what I suggest to you is following: - Delete your VPN configruation based on Policy Mode because it is out to date and slow because of no accelleration. - Create a Phas1 as 2 and leave all positions default. Deliver the information within a printscreen to the CP site. - After creating Phase1/2 create static route for the subnet on the other site pointing to the phase1 Interface which is visible for routing stuff - Create within the policy normal Policy Rules nothing VPN Policy Mode etc. meaning under normal Address mode. Within the policy for source and/or destination use Phase1 interface. - If you have to nat the traffic for incoming and/or outgoing use Central Nat Table and/or VIP Objects. There is absolutly no problem to establish with CP a VPN and CP does not require a VPN based on Policy Mode. Hope this helps have fun Andrea

[ede_pfau]

Just 2 thoughts: - why would you use NAT for tunneled traffic? - I doubt that IPsec is not accelerated when using Policy Mode. Nonetheless, please follow Andreas advice and use IPsec Interface Mode. You can debug this with standard methods, sniff the traffic, tweak the routing etc. etc. Just because the examples in the KB often use Policy Mode doesn' t mean a thing. Many are just outdated since v4.0 came out.

[Christopher_McMullan]

HMAC offload can be configured globally, but to offload tunnel traffic itself, the tunnel interfaces need to be addressed, which should more or less rule out policy-based VPNs from full offloading. By the way, Ede, my wife and I visited Heidelberg about five years ago. I love the Philosophenweg! The views of the town across the river are a real treasure.

[ede_pfau]

Wow, great! This is truely a small world. The castle ruin, the old town quarter and the lovely Neckar valley upstream are worth a visit. As is the university campus (30.000+ students) with a lot of hi-tech institutions here. Next time you step by just send me a PM!

[emnoc]

Kong One more thing to point out, you can do snat in route-based model just like that in policy-based mode vpns.

- why would you use NAT for tunneled traffic?

Ede, A lot of vendors I worked with currently and in past, use SNAT to ensure no collision between clients lan segments for accessing there hosted business applications. The do this primarily to ensure the burden of ip-management is on the clientside of things. Mostly, I' ve seen this in the financial verticals and gov agencies. Here' s a writeup for the common Another Sorry Appliance with 9.+ code. http://socpuppet.blogspot.com/2014/05/source-nat-based-on-destination-for-vpn.html The Fortigate and juniper security-appliances are even easier

[ede_pfau]

OK thanks, I got it why. Makes a lot of sense. The ISP would need a static route to this public IP pointing to his VPN. Now, I can see how this would be done in FOS having a static public IP address (IP pool=a.b.c.d/32). How do you manage this if the client is assigned a random public IP address which changes every day? I know I can sNAT to the egress interfaces' s address in a regular policy but with a tunnel interface? Where do I get the current public WAN address from?