Windows 11 24H2 Remote Access VPN

[preverite]

Since the general availability of Windows 11 24H2, we're noticing around 50% of Windows machines updated to 24H2 are failing to connect with the Remote Access VPN.

I noticed that with the release of Enterprise Endpoint Security E88.41 (https://support.checkpoint.com/results/sk/sk182237) issues with W11 24H2 were addressed, however the latest version of Remote Access VPN is 88.40.

Are other people experiencing similar issues? Since the RA VPN hasn't been updated but the Endpoint Security client has, I'm wondering whether its known there are issues with the RA VPN.

[_Val_]

Can you please explain what you mean by your statement: "however the latest version of Remote Access VPN is 88.40."

All Endpoint Security releases and latest versions are listed in sk117536, and E88.40 is definitely not the latest release for Windows. 

Concerning your issue, you are advised to upgrade your Endpoint Security Client on the problematic machines to E88.41 or later.

[preverite]

Hi chief, our issue is we don't use the Endpoint Security Client, but the standalone remote access VPN client.

On the 88.41 release page the Standalone VPN Client is 88.40

So I'm not sure if this (1) an oversight, (2) a new version will follow later, or (3) no issues are expected with v88.40 of the VPN client with W11 24H2.

[PhoneBoy]

The bugs fixed in E88.41 are relevant to the full Endpoint only, I believe.
Does the problem exist in E88.60 (latest for Windows)?

[George_Casper]

We're having the issue with 24H2 and all E88.x versions.   It is hardware independent, multiple makes/model laptops, and also affected our M365 Cloud PC VM's.  Rollback of 24H2 seems to be fixing it. 

I have TAC SR open since Monday, supplied logs from both sides including Zoom support session, awaiting response.  R&D needs to get on this right away.

[TT1]

We are seeing an issue with 24h2 and vpn as well, have tried the latest versions e88.40,41,60   vpn will connect but then drops the network connection in 10-20 seconds.  disconnect vpn, then you can reconnect wifi or ethernet

[George_Casper]

Rollback to 23H2 is the only option to fix.   E88.41 or above will only work with 24H2 Early Access versions from Microsoft.  24H2 GA released by Microsoft October 1 must have a major change in it to break VPN.  Checkpoint support holding firm on policy that they require 2 months from release of GA version from Microsoft to support it.   Hoping Checkpoint can do better but that's their official policy. 

See Phase 3 in https://support.checkpoint.com/results/sk/sk115192

[Ddoughty]

This is the only work-a-round I was able to come up with as well.  Wondering if you came a crossed a more feasible fix?

[jandvorak]

Same issue. After disconnecting eth/wifi doesn't work. You have to either reboot the computer (non-admin) or ipconfig /release, renew as admin from cmd

[Valentin1 · Accepted solution]

Please, can you try to set the "route_conflict_resolution_method" parameter to "modify" in trac_client_1.ttm file on the gateway and install policy. End users should reconnect in order new value to take effect. Here is excerpt of TTM code:

:route_conflict_resolution_method (
    :gateway (
        :default (modify)
    )
)

Trac.defaults has the same option

Documented in: https://support.checkpoint.com/results/sk/sk182749

[sid_cp]

sk182749

[preverite]

Thank you. This appears to be working for us (around 20 endpoints) - we will resume the rollout to another testing group.

[peppereg]

hello,

I would change my trac.defaults. file.

now I see the following string:

route_conflict_resolution_method STRING "delete_create" GLOBAL 1

how do I have to change it with the reported parameters?

thx

[George_Casper]

Is Checkpoint considering sk182749 a temporary work around or permanent fix?   Meaning will a client side fix be coming or not?

[G_W_Albrecht]

Yes in GA version - we still have EA version!

[PhoneBoy]

Assuming this is the true solution to the problem, I would expect us to set route_conflict_resolution_method to modify as the default upon installation of future client versions.
It could also be deployed on the gateway side by including the relevant setting in trac_client_1.ttm (it's currently not specified at all), possibly in a JHF/future version.

[George_Casper]

Would like to understand more about this setting change and any potential side effects before changing it globally for all users. Has this been tested by Checkpoint to be appropriate for other common scenarios including route all traffic through gateway (with Exclusion groups and other variations), MacOS users, etc.?  Don't want to fix one thing and break another.

[PhoneBoy]

What this parameter does is change how routes are created on the client once you connect to the VPN.
With the default setting (delete_create), your conflicting local routes are deleted and recreated with lower priority along with the VPN specific routes.
With the "modify" setting, the existing conflicting routes are modified to a lower priority and the new VPN specific routes are added.

I can't say to what extent this has been tested.
However, on the surface, it appears it should not cause an impact on other user/usage types.

[PhoneBoy]

I assume you change "delete_create" to "modify" 

[Bruno_Ramos]

https://support.checkpoint.com/results/sk/sk75221