- Products
- Learn
- Local User Groups
- Partners
- More
The Great Exposure Reset
24 February 2026 @ 5pm CET / 11am EST
CheckMates Fest 2026
Watch Now!AI Security Masters
Hacking with AI: The Dark Side of Innovation
CheckMates Go:
CheckMates Fest
I've been working on a site to site VPN to a Palo Alto recently, that needs to be certificate based.
We have finally made progress, but now have a very unusual situation, or at least it's unusual to me, but I'm hoping someone else has come across this before!
From the PA end, a ping brings up the tunnel, but from the Checkpoint end a ping does not bring up the tunnel, it gives an authentication failure!
I'm sure this must be related to the certificate but I don't know why.
Has anyone else seen this before I raise it with TAC?
Interesting issue Steve. Any relevant logs in smart console ot just says authentication failure?
Nothing relevant I can see, just authentication failed in the vpn debugs, and in the PA logs too!
Just curious, is it set as permanent tunnel on CP side? IM referring to this setting:
No it's not set to permanent, and it's set to one tunnel per subnet pair.
K, fair enough, probably not overly relevant here. What do you see if you search logs in smart console, just filter for community name, thats it.
Like below:
I get a repeating pattern of key installs and rejections (Auth failure):
Thats typical message people would see, but really begs the question why it gets rejeced...is tunnel showing as UP or keeps getting reset constantly?
I don't see the tunnel as up in SmartView Monitor at all, vpn tu confirms this.
I really have a gut feeling its something related to the cert on CP side. Are you able to send some screenshots of how its configured? Please blur out any sensitive data.
I tend to agree, but can't see what!
The interoperable device has the community listed with matching criteria, but there is not much else to configure.
They provided their CA and sub ordinate certs and I created objects for them. I then created the CSR using the sub ordinate, sent it to them to sign, and completed using the returned file. So the certificate is listed in the grid of available certs under the IPSEC VPN tab of the cluster.
What bothers me is that the matching criteria say that the gateway must present a certificate issued by the named CA, which suggests this is for incoming connections, and maybe I need to do something more for outgoing connections (which is whats failing)
Might be worth TAC case...hard to say for sure without doing remote.
Yeah, thats were I was heading but this customer has collaborative support which takes a lot longer to get raised.
In the meantime, maybe check this link, just to make sure the steps were followed.
Thanks Andy, I've had a look at this and the previous link. The link refers to CP to Cp connections so nothing much in there, but this document is interesting. It details adding topology on the Interop device, which I've never had to do in the past but may be worth a try!
I've also had info back from the PA end, the error they are seeing is "RSA_verify failed on 256 bytes sig using SHA256", It then falls back to SHA1 and fails again in the same way.
I've opened a ticket with collaborative support now to see what they come up with.
Just wondering...is it possible certificate itself might be using wrong auth methods?
I didn't think so as it works when initiated from the PA end
Might be worth simple vpn debug:
vpn debug trunc
vpn debug ikeon
-generate some traffic
vpn debug ikeoff
fw ctl debug 0
Look for vpnd and iked* files in $FWDIR/log dir
Yes, this is the exact process I used yesterday, it shows that the peer failed to authenticate the cert.
I'm thinking of dong a full debug but need some time out of hours to do this really.
K, got it. Might be worth TAC case as well to see if they may have different suggestion.
Great minds!!
I've opened one with Collaborative support, and sent them the debug logs too, so waiting for a response now 🙂
Excellent.
Hello Steve,
Your configuration looks good to me. Were you able to collect a debug during the failed negotiation? you can check the certificates you send with ikeview utility and there you will know if the issue is on CP or PA side. The file you must open on ikeview changes depending on the version of IKE and version of the gateway. See sk30994
https://support.checkpoint.com/results/sk/sk30994
Regards
Hi Daniel,
The log shows that the issue is the PA is failing to authenticate the certificate. The tech the other end also believes it's the PA not decoding the cert correctly, their log shows "RSA_verify failed on 256 bytes sig using SHA256"
But it's really strange that it works if the PA is the initiator.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 53 | |
| 40 | |
| 14 | |
| 13 | |
| 13 | |
| 11 | |
| 11 | |
| 8 | |
| 8 | |
| 8 |
Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesMon 23 Feb 2026 @ 11:00 AM (EST)
Latest updates on Quantum Spark including R82 features and Spark Management zero touch - AMERTue 24 Feb 2026 @ 10:00 AM (CET)
Latest updates on Quantum Spark including R82 features and Spark Management zero touch - EMEAThu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesMon 23 Feb 2026 @ 11:00 AM (EST)
Latest updates on Quantum Spark including R82 features and Spark Management zero touch - AMERTue 24 Feb 2026 @ 10:00 AM (CET)
Latest updates on Quantum Spark including R82 features and Spark Management zero touch - EMEAFri 06 Mar 2026 @ 08:00 AM (COT)
Check Point R82 Hands‑On Bootcamp – Comunidad DOJO PanamáAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY