Site-to-Site IPsec VPN using certificate-based authentication.

[Venue2185]

Hello 

Facing an issue with a Site-to-Site IPsec VPN using certificate-based authentication.

Previous setup:

• Check Point peer object: Static Public IP
• Authentication: Certificate
• VPN worked successfully.

Current setup:

• The remote peer ( fortigate ) has been changed from a Static Public IP to a Dynamic IP (DAIP).
• Authentication is still certificate-based.
• The VPN tunnel is not established after this change.

I followed the configuration described in the following article, but the issue still remains.

https://support.checkpoint.com/results/sk/sk182942

Has anyone successfully configured a certificate-based Site-to-Site VPN with a DAIP peer? Is there any additional configuration required  VPN community settings when changing from a static IP to a dynamic IP?

[AttiqRahman786]

Have you matched all the symptoms in sk182942? VPNd initiating the negotiation and IKEd handling the incoming packet?

[Venue2185]

Hello @AttiqRahman786 

Cannot confirm all symptoms yet. The only observation have is that the tunnel stopped working after changing the peer from static IP to DAIP. Before this change, the certificate-based IKEv2 tunnel was working fine.

[_Val_]

Versions in use? Is DIAP GW managed by the same MGMT server as the main GW? If not, what are the settings for the CA? What are the IKE errors that you see?

[Venue2185]

Hello  @_Val_ 

The Check Point version is R81.20. The DAIP interoperable object is FortiGate Firewall, and we are using an External CA server for certificate authentication.

The issue started after changing the interoperable object peer from static IP to DAIP. Before this change, the IKEv2 VPN tunnel was working normally.

Lab setup:

• External Root CA certificate is imported on both Check Point and FortiGate.
• CSR was generated from both devices and signed by the External CA.
• The signed certificates were imported back to the respective devices.
• The VPN configuration is using IKEv2 with certificate-based authentication.

Below are the Check Point configuration screenshots from my lab setup.

Currently, after changing to DAIP, the VPN tunnel is not established.

[_Val_]

Check that the GW is identified by DN and not by IP in each of the certificates. Also, double-check that the external certificate, and not those signed by the ICA, is used for VPN auth. If this is the case, the next step is to verify that the CRL distribution point is available for both central and satellite GWs. 

[Venue2185]

Hello @_Val_ 

Thank you for your replies and double-checked that IKEv2 is enabled on both the Check Point and FortiGate firewall.

To be honest, this is my first time deploying a Check Point and FortiGate VPN using certificate-based authentication, so I am still learning how Check Point handles this scenario.

Design is:

• Hub: Check Point Gateway (static public IP)

• Spokes: FortiGate firewalls (dynamic public IP)

• Authentication: IKEv2 with certificates

• Certificates are issued and signed by the same External CA.

I have a few questions because I am a little confused about the workflow.

1. For a certificate-based VPN, when creating the Interoperable Device object on Check Point, should the Certificate Authority be the Root CA, or should I import/select the peer's signed certificate?

2. When the peer has a dynamic public IP and the Interoperable Device is configured as Dynamic IP, how does Check Point identify and authenticate the peer during IKE negotiation? Does it verify the peer based on the certificate (CN/SAN or Distinguished Name), or is another matching method used?

3. Is there any official deployment guide or best practice for configuring a certificate-based IKEv2 VPN between a Check Point hub and FortiGate spokes with dynamic public IP addresses?

I also followed the DIAP VPN guide that I found on CheckMates and reproduced the configuration in my lab, but unfortunately the tunnel still does not establish.

Please find the attached screenshots of my lab deployment.

Any guidance, deployment examples, or recommendations would be greatly appreciated.

Thank you.

[_Val_]

I understand your desire to have all the answers in a single post. The issue is quite clear: one of the sides (not sure which, you should tell me) refuses to do IKEv2. Clear it out, and if it still does not work, look for another error message. 

In a general sense, in an S2S  VPN with a DIAP satellite, it is the spoke that always starts IKE negotiations. The reason is simple: the hub does not know which IP the DIAP GW has before the tunnel is opened. 

During the IKE phase, authentication is done. In your case, GWs are authenticating with certificates. Any time cert-based authentication is performed, each GW will try pulling and then caching locally a CRL from your CA, one that signed the certificates.

You should ask yourself: Is the CA and its CRL distribution point accessible from the lab? If the answer is no, the authentication will fail. You should, however, see an "Authentication failed" error message and not the one you presented above.

I still think there is something wrong with the IKEv2 on one of the sides. You can, however, check that by one of two ways:

1. Configure a pre-shared secret instead of cert auth on both ends and see if it works. If it doesn't, IKEv2 config is most probably faulty. If it does, dig into CRL availability for both GWs.

2. Disable CRL retrieval as part of the cert auth. Unfortunately, I don't remember how it is done on the Forti side. If the tunnel is now established, this is your issue. 

You can also check the CRL distribution point from each GW directly with "curl" to the CRL URL. You need to know that URL, of course. If you are using a closed lab environment, but your certificates are signed by a public CA, the CRL retrieval is most likely to fail. 

I hope it all makes sense. 

[Venue2185]

Hi @_Val_ 

I have double-checked the configuration and testing results.

When using certificate-based authentication with IKEv2 in a static-to-static configuration, the VPN tunnel is established successfully.

However, after changing the Interoperable object to dynamic DIAP in checkpoint side, the tunnel cannot be established anymore.

During packet capturing, noticed the IKE negotiation is stuck in a loop. FortiGate keeps sending IKE_AUTH requests, and Check Point only responds with IKE_SA_INIT. The tunnel is not established successfully. As below

10.1.3.1 -> Checkpoint / 10.2.3.2 -> Fortigate

10.2.3.2 → 10.1.3.1 IKE_SA_INIT MID=00 Initiator Request
10.1.3.1 → 10.2.3.2 IKE_SA_INIT MID=00 Responder Response
10.2.3.2 → 10.1.3.1 IKE_AUTH MID=01 Initiator Request
10.2.3.2 → 10.1.3.1 IKE_AUTH MID=01 Initiator Request
10.1.3.1 → 10.2.3.2 ICMP Destination unreachable (Port unreachable)
repeating....

Regarding CRL checking, I have already disabled it on both the Check Point and FortiGate sides.

Also, I would like to apologize for the previous information about the "peer is not IKEv2" message. That log was from the old configuration and was not related to the current issue.

Could you please advise what else we should check for the dynamic peer scenario?

Thanks.

[_Val_]

What is the error message? I don't see any in the screenshots

[Venue2185]

Hello @_Val_ 

Please find the previous attached Wireshark capture and  debug file is quite large. Could you please advise which keywords I should search for or which part of the debug logs I should focus on to identify the root cause of this IKEv2 dynamic peer issue?

Wireshare Packet result as below,

10.2.3.2 → 10.1.3.1 IKE_SA_INIT MID=00 Initiator Request
10.1.3.1 → 10.2.3.2 IKE_SA_INIT MID=00 Responder Response
10.2.3.2 → 10.1.3.1 IKE_AUTH MID=01 Initiator Request
10.2.3.2 → 10.1.3.1 IKE_AUTH MID=01 Initiator Request
10.1.3.1 → 10.2.3.2 ICMP Destination unreachable (Port unreachable)
repeating....

Thanks

[_Val_]

I think we have a miscommunication here. Traffic capture only shows packet exchange. Error messages should be showing in the logs on both sides. Look into them, they should explain the issue you are observing.

[_Val_]

Scratch my previous message. One of your GWs does not support IKEv2, it is clearly stated in the logs. Fix that, or force IKEv1 (not recommended for security reasons)