Remote Access IKEv2 for R81 and R82 Quantum Spark (comments on IKEv1 being deprecated)

[sx8n20394]

So this post is just for everyone who may be pulling their hair out (or what is left of it) regarding the CVE and IKEv2.

I also just wanted to point out that in their CVE article, Checkpoint called IKEv1 deprecated and essentially implies that it shouldn't have been used in the first place. The hilarious part is that it never worked for Remote Access in R81 and is still broken for R82. 🤓Brilliant!

IKEv2 is NOT supported on R81 at all even though it is in the advanced settings. Why they would put it in there and never have it actually capable of working is beyond my comprehension. If you have a locally managed R81 device your only option is to upgrade to the latest firmware because none of the 3 mitigation options are possible (confirmed by TAC).

IKEv2 is broken on R82 (🤣hilarious!). If you turn on IKEv2 you will notice the following behavior (confirmed by others who have posted on here):

1. Drop off exactly after 1 hour and require re-authentication. I have also seen some fun behavior when using Entra SSO where the browser will keep opening authentication tabs at such a rapid pace that the user has to hard boot (awesome!).

2. Drop off at completely random times. (makes getting logs hard😢)

3. Connected remote access clients may not show up in GUI or in CLI using the "PEP S U A" command. I connected myself, looked at both and it didn't show my user connected at all. This is kind of a roll of the dice because I had some users should up and some didn't. Also I would rerun the pep command or refresh the GUI and users would disappear and reappear (magic!).

[PhoneBoy]

IKEv2 has been supported for Site-to-Site VPN for a while.
Having said that, it shouldn't be offered on R81.10.x for Remote Access if it truly isn't supported.
This option should work on R82 (where maintain supports IKEv2 for Remote Access clients). 

Please PM me the relevant TAC case. 

[ccsjnw]

Nobody is talking about IKEv2 for site to site VPNs!

We are all talking about the very misleading communications coming out of CheckPoint, giving the impression that IKEv1 is deprecated and IKEv2 has been *fully* supported for Windows Remote Access VPN clients for quite sometime, when it absolutely and unequivocally has not.

CheckPoint give the impression that this incident is only affecting customers who have been slow to migrate from IKEv1 to IKEv2, when it’s actually been CheckPoint who have been *very* slow to make IKEv2 work reliably, and have been down-playing the need for IKEv2 for Remote Access VPN clients,

IKEv2 is still *not* natively supported today without the manual Registry Hack.

Please address the misinformation in your communications. There are a lot of angry customers right now.

[PhoneBoy]

Just FYI, the IETF is deprecating IKEv1: https://datatracker.ietf.org/doc/rfc9395/

[sx8n20394]

That is fantastic. Maybe Checkpoint should make IKEv2 work for Quantum Spark remote access without tons of bugs. There is a reason why we are complaining. R81 doesn't work with IKEv2 at all. Checkpoint even stated in their SK it is not supported. R82 is super buggy and drops VPN connections. Read my original post instead of posting useless responses that don't pertain to the concerns.

[ccsjnw]

I completely agree with you.

The CheckPoint narrative about IKEv1 being ‘deprecated’ is very misleading and it’s disrespectful to the technical community who have to support this stuff…

I’m not at all happy about how this incident has been handled or communicated by CheckPoint. I expect better.

[tobiasruf]

We also experience different issues with IKEv2:

The one hour logoff problem.

Connection problems from some WiFi networks in comparison to IKEv1 mode.

Currently we think about switching back. Waiting for TAC if there is a solution available until weekend.

I do not understand what is the currently proposed setup from Checkpoints perspective.

[perfect4situa]

I can confirm a very similar issue on my side.

I have a Smart-1 Cloud managed Quantum Spark 2000 that was upgraded to the latest R82.00.10 build 2216 to address the recent VPN-related CVEs. Immediately after the upgrade, all Remote Access VPN connections started failing with a generic "Negotiation Failed" error.

My original configuration was:

• Prefer IKEv2
• Support IKEv1
• AES-128 / AES-256 only
• DH Group 14 or higher

With this configuration, VPN access completely stopped working after the upgrade.

What makes this even more confusing is that the only workaround I found was to change the VPN connection method to IKEv1 only. As soon as I disabled IKEv2 and forced IKEv1, users were able to connect again.

This seems counterintuitive considering that the upgrade was performed specifically to address recently disclosed VPN security issues. From my perspective, it looks like something in the new security controls or authentication/negotiation process may have affected IKEv2 compatibility.

I'll probably open a TAC case to better understand the root cause, but for now the only way I could restore VPN connectivity was by switching to IKEv1 only.

Has anyone else observed the same behavior on build 2216 with Smart-1 Cloud managed Spark appliances?

[ccsjnw]

It's a problem with the Windows VPN client, not your firewall Gateway.

The Windows VPN client only supports IKEv1 by default. It can support IKEv2 via a hack, but it won't support both and won't negotiate with the Gateway. CheckPoint have done a terrible job of communicating this to the community!

If you want to enforce the use of IKEv2 on your Gateway, then you need the Registry hack on every Windows VPN Client to enable IKEv2 - but be careful, because a client upgrade will remove the hack and it will revert to IKEv1 only (which means you clients can't connect again) - hopefully CheckPoint will finally fix this nonsense in the next Windows VPN Client release...

This problem with the Windows VPN Client being unable to negotiate IKEv2 or IKEv1 with the Gateway has been with us for literally years now... it's exasperating!

The iOS Capsule Connect VPN Client for iPhone and IPad does negotiate IKEv2 or IKEv1 exactly as you would expect it do. This is the behaviour we desperately need in the Windows VPN client. The only negative I have found with the Capsule Connect Client is it only supports up to SHA256 - it doesn't support SHA384 or SHA512. CheckPoint need to work on providing feature parity across all the supported clients.