Cannot use Option 1 mitigation in regards to CVE-2026-50751 - Uncheck "Allow older clients..."

[Joe_Kanaszka]

Good afternoon!

Dealing with CVE-20296-50751

We are running R81.20 T118.

We are going with option 1 in the remediation article - Disable "Allow older clients to connect to this gateway"

All of our Check Point Mobile clients are E89.x.


We had been using "Allow older clients to connect to this gateway" and "Allow newer clients  that support Multiple Login Options to use this authentication method."  After disabling this option per the sk185033 and configuring the "Multiple Authentication Clients Settings with our DUO Radius server - the same one that we were using in the "Compatibility with older clients section" - that we disabled, we can no longer connect. When we try and sign in to Check Point with the Mobile client, we input our username and then password, we then receive a Duo push. Immediately afterward we receive this error: "Negotiation with site failed" "Please provide a user name and password to authenticate"

In the logs, I'm seeing IKE errors:

Please see attached.

Screenshot 2026-06-09 134812.jpg

Thank you!

[ccsjnw]

I don’t need to tick “Allow older clients to connect to this gateway”, for my VPN clients to connect, but I do need to tick:

“Allow Legacy Authentication for SC (hybrid mode). L2TP (PAP) and Nokia clients (CRACK)”.

The latest Remote Access VPN Clients for Windows, can’t connect if this non-sensical option isn’t enabled… I am using CheckPoint Username and Passwords combined with CheckPoint certificates. I don’t use L2TP or CRACK (!)

I have the following client type options enabled:

Mobile Devices:

Capsule VPN / Connect (for iOS devices)

Desktops / Laptops

Endpoint Security VPN

Check Point Mobile for Windows

Some of the client VPN settings are so old, I don’t think anyone fully understands what they actually do in 2026 and the descriptions and documentation doesn’t give you any real information about when you do or do not require certain options to be enabled. It’s an area of the product that is well overdue an overhaul and requires much better documentation…

Hopefully R82.20 will *finally* overhaul the ancient VPN settings and archaic client encryption defaults…

We can but dream…

[Joe_Kanaszka]

Thank you!

So I have two gateways running R81.20 Take 118.  

Production and Disaster Recovery Site.

My DR gateway works fine when simply unchecking that option "allow older clients..."  My E89.x Check Point Mobile clients can connect.

However on my Production cluster, this is not the case.

I also have enabled

Desktops / Laptops

Endpoint Security VPN

Check Point Mobile for Windows

I noticed a difference between the two configs in Global Properties/Remote Access/VPN- Authentication  and Encryption:

On the DR gateway that's working, Under "Support authentication methods" - I have Pre-Shared Secret and "support L2TP with Pre-Shared Key" unchecked.  The other three options are selected.

On my Production gateway - The Pre-Shared Secret option and "Support L2TP" are both selected along with the other three options. 

Might this be causing my issue?

Thank you again!

[ccsjnw]

When I changed from using Passwords only to Passwords and certificates (in my lab) for Remote Access Client VPN authentication, I encountered an authentication problem and the option to use certificates was completely ignored.

I don’t have any site to site VPNs, so I had never enabled the IKE VPN blade. I had only enabled the Check Point Mobile Blade. However, enabling the IKE VPN blade and re-installing the policy allowed Password + Certificates to then work - so it may be worth checking what blades are enabled on both your Security Gateways…

[Joe_Kanaszka]

ok. I’ve noticed something after trying Option 1 and disabling “Older Clients”, implementing the reg hack and enabling in Global Properties “Enable  IKE 2 and support IKE 1 (I chose this one). I’m still seeing the same IKE errors in Smart Log. After I revert all the changes to get my clients working again, before my client works, I need to switch the authentication in the client settings to DUO instead of DUO default.  Might there be something here I’m overlooking??

[CaseyB]

If you are only using DUO radius to authenticate your users, make sure your configuration looks like this:

multi-2.png

You might be having issues if you have a secondary option configured like this:

multi-1.png

[simonemantovani]

DId you also select the right authentication settings in the Endpoint VPN client?

[Joe_Kanaszka]

Thank you!  Trying now but so far no luck.   Do you have Duo as well?

What are the actual steps you are taking to make this configuration look like this if you dont mind?

I'm clicking "add" - Default - Edit then change to Radius.  

[CaseyB]

We don't use Duo, but we use Imprivata as our RADIUS / MFA for VPN users. For ours to work I just had to uncheck the old clients box and then configure the RADIUS like in my top screenshot above.

This is what the RADIUS looks like:
multi-3.png

[Joe_Kanaszka]

Thank you so much for that.  I left my old Radius settings in the Multi Logon config but just moved it down in the order - having the new Radius on top.  Could that be the reason I'm getting these IKE errors?

[CaseyB]

If the old RADIUS IP address responds, I would imagine it could cause some issues.

[Duane_Toler]

Hey again, from the other thread..

Be sure you check your User Directories on the left so that this profile knows where to find/map the requested usernames.  You still need LDAP here so the gateway can do username lookups and pull LDAP (AD) groups for mapping to access roles.

In your RA VPN community, you can use All Users here rather than any specific list (and the generic* user).  You'll instead be able to control user-based or group-based access with Access Roles now.  In here, you can choose your AD groups, rather than having LDAP group objects.  Use the Access Roles in your policy instead of the "legacy" "Group@Any" object in the Source column.  With Access Roles in the Source column, you don't need to use the RA community in the VPN column either; leave this as Any. 

Check your gateway properties, Identity Awareness on the left, and in the list of identity sources on the right, be sure to check "Remote Access".  This makes the RA VPN contribute identities to the gateway for the Access Roles.

The AD lookup in the gateway authentication profile User Directories will map the user groups for all this.

[Joe_Kanaszka]

Good morning Duane and thank you.  My apologies as I was out of the office last week.