Workstation Player 17.6.3 (Win host) update of WMware Tools in Win 10 & 11 guests breaks OVPN software.

[Hakan Sjorling]

I just updated my VMware Workstation Player from 17.6.2 to 17.6.3, running on my Win 10 Pro host.

After also updating the VMware Tools ("complete" setup) in my Win 11 Pro guest, the VPN software in the guest stopped working.

The VPN I use is called OVPN https://www.ovpn.com/ which is not to be confused with OpenVPN.
This client can connect using either WireGuard or OpenVPN.
I have used it for a couple of years now, and it has worked perfectly all that time.

I have tested this several times now, unpacking my archived base line, clean VM versions of Windows 10 and Windows 11.
Unpacking from a zip archive, I start the previously prepared VM in Workstation Player 17.6.3.

The Player ask me to update VMware Tools in the guest, but I ignore that at the moment.

I install the OVPN software in the guest, which at this point works fine.

Then I go ahead with the VMware Tools update (I select the "complete" setup) that came with Player 17.6.3.

After that, which requires a reboot of the guest, the OVPN client no longer can start.
Its system tray icon shows up for 3-5 seconds and then disappears.

I've tried this multiple times now, with both Win 10 and 11 guests.
I have also tried updating the Tools before installing OVPN, with the same result: it just shows in the system tray for a couple of seconds.

I am also in contact with the OVPN support, but wanted to bring this up here as well, in parallel.
I don't know if the Player is to blame since that is the one that has changed?
Or if the OVPN software is at fault for not adhering to some standard or something?

Any clues, someone..?

[RaSystemlord]

I don't know, but there might be a simple explanation to this.

Usually, if not always previously, your address ranges, like in NAT, are changing when Upgrading (or reinstalling). Maybe your VPN solution does not like that?

Just install the VPN again - or perhaps you can change the address space back and then it works? (With Virtual Network Editor).

[Hakan Sjorling]

Thank you for the suggestions, @RaSystemlord.  (For some reason, there is no reply-button on your post..?)

However, when I start off with a clean guest, do the VMware Tools update, and after that install OVPN for the first time,
the OVPN software does not run for more than a few seconds, and likely does not even try to log on to the VPN service provider since I never got close to the point where I'm supposed to enter my account login. 
Hence, neither the OVPN client (as it is installed for the first time on that guest) nor the service provider are aware of any change in address space...

I got a reply from the OVPN support today, informing me that they have escalated this issue within their team. We'll see...

[Hakan Sjorling]

The OVPN support team found this article:
https://knowledge.broadcom.com/external/article/383994/applications-using-vmware-tools-125-is-c.html

Later, I found this related article, with the same workaround/solution:
https://knowledge.broadcom.com/external/article/331541/opengl-dll-is-not-unloaded-on-applicatio.html

Searching for the environment variable mentioned in the articles, I found several other programs/systems also affected by this bug in the VMware Tools OpenGL driver.

There are two ways to apply the workaround:

Workaround on Host:
Add to the VMs VMX config file:
guestinfo.svga.disableLLVMPipe=TRUE

Workaround in Guest:
Click on start --> Search and Open --> Edit the system Environment variables --> Environment Variables --> System Variable --> New --> Create below variable and restart

Variable name : SVGA_ALLOW_LLVMPIPE
Variable Value : 0