Switching VPN encryption method from IKEv1 to IKEv2 for a Cisco FPR peer

[George_Dumitru]

Hi,

We are looking to switch the encryption method from IKEv1 to IKEv2, between a Check Point 6700 gateway with OS version R82 and a Cisco FPR-1120 with Software Version 9.20(3).

Phase 1 and phase 2 negotiate ok, IPsec tunnels are up, relevant connections are encrypted inside the VPN community but there is no connectivity.

From the research I've done this behavior could be related to the fact that the source IP addresses behind the Cisco FPR are NATed on the Check Point side before reaching the destination (NAT cannot be eliminated).
In IKEv1 NATed traffic still matches the tunnel but this changes in IKEv2 where traffic selectors are negotiated before NAT happens.
If this is the issue, how can I solve it without removing the NAT?

Has anyone encountered this scenario before / had issues switching the IKE version? Is my assumption correct?

Any other things that I should check?

Thanks,

George

[simonemantovani]

Did you already tried to add the NAT ip address into the encryption domain?

[israelfds95]

Since Phase 1 and Phase 2 of the VPN are up, I believe the issue is likely related to security rules or traffic handling.
First, if the VPN is domain-based, it’s important to review the VPN Domain configured on the Check Point side and verify what is being negotiated on the Cisco side. Any mismatch here can cause problems with traffic selectors.
Second, validate the access rules and how the communication is being allowed, make sure the correct networks are permitted. Third, perform packet captures on both sides, or along the entire path, to understand what is happening with the traffic. On the Check Point side, you can use fw monitor to get a better view of the routing and packet flow.
Fourth, usefw ctl zdebug + drop | grep <ip-host-cisco>  the Check Point gateway to check if any packets are being dropped.
Fifth, review the logs for any additional clues.

If the VPN is route-based, it’s also worth reviewing the rules and routing to ensure everything is correct. There are many possibilities, but since the tunnel is up (Phase 1 and Phase 2), at least you can rule out issues with tunnel negotiation.

[George_Dumitru · Accepted solution]

Thanks for all the info!

We finally identified the issue...after switching to IKEv2 a NAT-T tunnel was negotiated instead of IPsec.

Disabling NAT-T on the Cisco side solved the problem.

[israelfds95]

Very good, happy that you find that problem. Thanks for your feedback ☺️