topic Re: migrating remote access client to IKEv2 in Endpoint

migrating remote access client to IKEv2

flachance — Mon, 22 Jun 2026 15:20:12 GMT

So we want to move or client from using IKEv1 to v2.

On the gateways we've selected Prefer IKEv2, support IKEv1.

We've started pushing registry changes to set disable_ikev2 to 0. I can't seem to find a way to verify if people connect with IKEv1 or v2.

vpn tu tlist doesn't show that info. I tried fw tab -t userc_key -f and it shows Schema: IKE(3). Anyone knows what IKE(3) means?

Or any other way to show which IKE version clients are using?

thanks

Re: migrating remote access client to IKEv2

PhoneBoy — Mon, 22 Jun 2026 22:37:56 GMT

I believe it will show in the log entry when the user connects.
That said, I've seen reports that suggest the registry change on clients will cause the clients to use IKEv2 only.

Re: migrating remote access client to IKEv2

Lesley — Wed, 24 Jun 2026 19:25:56 GMT

Indeed try to filter with: action:Connect AND "Remote Access" or action:Login AND "Remote Access"

Re: migrating remote access client to IKEv2

flachance — Wed, 24 Jun 2026 19:34:32 GMT

I can filter with action:"Log In" AND blade:"Mobile Access". All I see in the details is

Data Protocol IPSec

Data Encryption AES-256 + SHA256 + Group 14, Certificate

Nothing about IKEv1 or v2

Re: migrating remote access client to IKEv2

Lesley — Wed, 24 Jun 2026 19:39:31 GMT

can I have a vpn tu tlist output of a few clients? Just remove the external IP info, dont need that.

Also anything in cpview? There should a global counter for ikev1 and ikve2 tunnels to give you a global idea what is mostly used

Re: migrating remote access client to IKEv2

flachance — Wed, 24 Jun 2026 19:46:53 GMT

Didn't think to look at cpview. It does show the Concurrent IKEv1 SAs and IKEv2 SAs.

Unfortunately for me IKEv2 SAs shows 0. ☹️

So with the gateway set to Prefer IKEv2, support IKEv1 and the registry change on the client it' s still using IKEv1. Or it fails IKEv2 and reverts to v1.

Re: migrating remote access client to IKEv2

dunkelmorten — Wed, 01 Jul 2026 10:54:33 GMT

Yes, indeed to be found at cpview: software-blades > VPN > Overview

An additional indicator could be the FW log for 'action:"Key Install" which is showing information like:
VPN Feature: IKE

or in section "More":
Ike: Quick Mode completion (which is in indicator for IKEv1) as there ain't no Quick Mode on IKEv2.

Re: migrating remote access client to IKEv2

PeterH — Fri, 17 Jul 2026 13:49:05 GMT

vpn tu list ike

Peer 10.131.32.254, user md5 d5d97eebc9c840d3:

Realm: vpn

Machine cert authentication: false

IKEv2 SA <e9b394c9b4ac0872,d206797d57731d61>

Unfortunalty it works only once per client. Each time the user disconnect and reconnect again, he didn't not succeed, until the connection IKEv2 SA timed out and "vpc tu tlist" is empty for this user. Otherwise in our testing environment, we reboot the gateway and afterwards it works again, but only once.

TAC case is open

Re: migrating remote access client to IKEv2

flachance — Tue, 22 Sep 2026 14:34:22 GMT

After upgrading the gateway to R82.10 I finally got some clients to connect with IKEv2. In SmartView monitor I see XAUTH for the authentication method for the clients using IKEv2.

Re: migrating remote access client to IKEv2

dunkelmorten — Wed, 23 Sep 2026 08:31:56 GMT

Well, I am not sure that XAUTH is an exclusive indicator for using IKEv2. Afaik it reflects Cross Authentication methods like MFA relying on a third party authentication or MFA connected backend (i.e. certificates/PKI, RADIUS, etc.)

Re: migrating remote access client to IKEv2

flachance — Wed, 23 Sep 2026 11:59:34 GMT

Thanks for the clarification. It's just odd since everybody is using the same authentication method (certificate) but only the few clients that have switched to ikev2 shows XAUTH. There must be something else I'm missing but in my case, whatever the reason, I can use this to quickly see who is now using IKEv2.

Re: migrating remote access client to IKEv2

ccsjnw — Wed, 23 Sep 2026 18:13:11 GMT

Be careful - I have had endless problems trying to migrate Windows Remote Access VPN client's to IKEv2. (I'm running R82.10 on my Security Gateways). Upgrading the Windows Remote Access VPN client version will remove your Registry Tweak and revert to IKEv1.

The Windows Client IKEv1 / IKEv2 is still very buggy. I had a laptop that needed to connect to two different organisations. One origanisation was configured so that their Security Gateways *only* supported IKEv2, the other organisation was set to Prefer IKEv2, support IKEv1 clients.

The client had the IKEv2 Registry tweak applied. Initially everything seemed OK, but after connecting *once* successfully to the site that enforced IKEv2, the client then could not re-connect to that site, until the site was deleted, and reconfigured. Then it could connect just once again. The only meaningful solution was reverting the Security Gateway to Prefer IKEv2, support IKE1.

This issue is repeatable. For now, there is no way you can *reliably* enforce the use of IKEv2 on your Security Gateways and have the confidence that your Windows Remote Access VPN clients will be able to connect every time they need to.

The problem is, the Windows Remote Access VPN client, does not negotiate IKEv1 or IKEv2 with the Security Gateway. It uses one or the other (depending on the Registry value), and it can just plain break after performing a topology download from one of the sites, which seems to somehow effect connectivity with another site (?). The same set of problems have been present in many different versions of the client.

I really don't know why Check Point can't make IKE negotiation work properly for the Windows Remote Access VPN client / EndPoint Protection clients. The Capsule Connect VPN client for iOS works absolutely perfectly - it happily negotiates IKEv1 or IKEv2 with the Security Gateway and works every time.

The only issue with Capsule Connect VPN on iOS is that it only supports up to SHA265, it does not support SHA384 (the Windows Remote Access VPN Client happily supports SHA384 and has for sometime).

Everything works very happily with DF Group 21 - so that's good news.