add alternate IP to the cert if it is not the main IP of the gateway then configuring the Sonicwall to accept that IP (Also for Sonicwall it has to be the first alternate IP in the certificate if there are multiple) And when creating the certificate on Checkpoint you need to add one e.g.

Some FW's like Sonicwalls you have to use them. But it is better to match the certs correctly.Īs for the DN IP and email, On the check point side they can be left blank. If it doesn't it will send it's default and auth will fail (as you don't have its CA otherwise it would have matched)įor a shot gun approach both sides will need to have the CA for all possible certs each will send. The other end will try and match one and send it. Your FW will send a cert request with all your installed CA certs including your CP internal cert. The peer will have a cert request and your FW needs to have the correct signed cert to send back or it usually sends it's Check Point Internal cert, and the peer will fail the auth. The same will happen in the other direction. if the default is differnet and sent it will fail) Your FW will only succeed authentication if a cert now arrives signed from that CA. If the peer does not have a cert signed by that CA in the request it will send it's default. In the VPN negotiations your FW will send a cert 'request' saying send cert from this CA only, and if you had IKEview app you would see the cert requests from each FW.

Matching criteria cert section is the CA you want the other end to send a certificate from. When you say ANY do you mean not selecting a certificate or not selecting any of the alternate options like IP DN or Email?

Check point certificate VPN