Hi There

Posting our issues and fixes to get Ikev1 IPsec VPN (site2Site in SonicWALL lingo) using a 3rd party certificate Authority (CA)

Issue 1. SonicWALL logs Invalid ID after Packet 5 is sent from Check Point.
SonicWALL Default IKE ID is Distinguished Name (DN)
Check Point does not care what it receives but sends IPv4 and IP address as IKE ID.
Fix for Issue 1:
SonicWALL configured PEER IKE-ID to expect IPv4 and IP address that Check Point sends as the ID Payload.

Issue 2. Check Point failing Authentication with the Certificate received from SonicWALL.
Certs sent from the SonicWALL firewall did not contain the full certificate chain.
The full chain in this case was
(root CA) (Intermediate CA) (Issuing CA) (Certificate)
The arriving cert only had the Cert name and the Issuing CA .
The Recommended Check Point config which was confirmed from recent tests for another VPN cert conversion. Was to have the Root cert added into the Trusted CA section of Check Point and any Intermediate and Subordinate CAs installed in the Subordinate section of Check Point.

Because the SonicWALL cert only had its issuing CA.
Check Point checked the Trusted CA section and failed the authentication.

Fix for Issue 2:
Moving the (Intermediate CA) and (Issuing CA) into the Trusted CA section of the Check Point Config.

Issue 3. SonicWALL failing Authentication with the Certificate received from Check Point.
The Certs received by SonicWALL from Check Points, the IKE ID did not match an Alternate Name within the cert

Check Points sends its VPN IP address as ID Payload.
This IP is taken from the Link Selection section of the Gateways config.
This is usually the main Gateway IP but can be configured to a different IP for reasons known to the individual that changes it.

The IP used in the ID payload must be an Alternative Name added to the certificate when creating the CSR (certificate signing request), so it will be in the certificate when used for the VPN.
From Trial and Error we found that the SonicWALL needed the ID Payload to match the first Alternate Name if there are multiple.

Fix for issue 3:
Recreate the Check Point certificates with the ID Payload as the only Alternate Name.


Auth would work when initiated from SonicWALL
We could not get this to work when initiated from Check Point.
The last authentication step failing with only a failed Auth error on the SonicWALL.

These results are at the level of testing we got to to get the VPN working. There could have been more refinement but we had to organize two teams at different locations to test each time then go away and review, after weeks of testing we had to find a point to stop.

  • Since all CA's are now in trusted, will it work with a new firewall FW using the same CA that sends the full chain in the cert.
  • We guess just adding the issuing CA into trusted CA's would be suffice.
  • Is it the way the SonicWALL creates the cert during the CSR that only has the issuing CA and not the full chain and can that be changed to include the full chain.