VMware Workstation 17 Pro NAT network fails every 2 minutes (approximately)

[Nurkanat Baysenkul]

I am using version WS 17 Pro (17.6.1 build-24319023) and have the issue when NAT fails every minute or so. Restarting the NAT Service fixes the issue for not more than 2 minutes. 

[RaSystemlord]

You don't say what the Host is and what kind of install the Host is. Corporate Windows computers, with 3rd party software, can do all kinds of things to prevent you using your software. Also, if personal, your own firewall/virus -software can do things.

[Kelvin Schmidt]

I believe this a is very frequent issue that is reported many times, but not handled. 

VmWare 17.6 NAT network connection drops on Windows 11 23H2 host machine | VMware Workstation

No Internet Access for VM's | VMware Workstation

Constantly Losing Internet Access | VMware Workstation

We have met this problem also in 17.5.2 on Hosts with Win10, Win11 and Win2022. Guests have been Win10 and W2022.  On many different hardware types. So the problem seems to me, to be internal in the VMware NAT service on the host machine.

I hope the Broadcom VMware developers will react on this problem?

[RaSystemlord]

So, the hosts have always been Windows. Nobody creates a service that interrupts itself on regular intervals - it is kind of against the philosophy of having a service. The thing that it occurs on many Windows platforms doesn't mean that the solution is in the software itself. Based on these descriptions, it feels that the interrupt comes from an external source - like some firewalling or anti-virus or whatever - this can easily be the case because people use the same software on different platforms.

This doesn't mean that VMware software is not done incorrectly. But this would mean that solution would be to do something about the external software not allowing a networking service to run constantly - rather than waiting for development to come up with a fix to this, which could take a long time.

If the NAT service would be faulty on default Microsoft Windows environment - in all of them starting from Win10, Win11 until WinS 2022 and on top of that on different hardware with different VMware networking implementations - VMware wouldn't work anywhere. The reason must be a conflict of some other, external software. Not knowing what the Hosts really were (which version, there are 10+ of Win10 alone, which locality) it's not really possible to deduct more.

But you are right, presenting a reproducible case to development would help - development never goes for a wild goose chase. Wouldn't that need to happen through a Support Case, or how does this company work?

[SrDev]

I can recreate a similar issue, which seems to have been introduced in v17.

 

Steps

Using VMWare Workstation 17 Pro (17.6.2 build-24409262) (tested on Windows 10 and 11)

 

• Setup a guest VM to use NAT in Virtual Machine Settings, and DCHP in the guest OS. 
• Suspend the VM
• Connect the host to a network (my host uses DHCP) and note the assigned IP / network address (192.168.1.165 in my case)
• In the VMWare Virtual Network Editor, select the NAT configuration entry
• Set the Subnet IP to the same network address as the host (192.168.1.0 in my case)
• Resume the VM and wait for it to connect to the NAT network

 

Results

 

The VMWare NAT Service crashes on the host with the following error in the Windows Application Event log:

 

Faulting application name: vmnat.exe, version: 17.6.2.61654, time stamp: 0x67484d7d

Faulting module name: vmnat.exe, version: 17.6.2.61654, time stamp: 0x67484d7d

Exception code: 0xc0000005

Fault offset: 0x00012b4c

Faulting process ID: 0x2dfc

Faulting application start time: 0x01db8a29d3c17d90

Faulting application path: C:\WINDOWS\SysWOW64\vmnat.exe

Faulting module path: C:\WINDOWS\SysWOW64\vmnat.exe

 

Workaround

 

Reconfigure the NAT network to use a different subnet that does not conflict with the network of the host 

[RaSystemlord]

Yes, this constitues the thing I wrote in the beginning of that thread: "something horribly wrong in network configuration". VMware does not do this - this is done manually.

Also, you shouldn't do any of that in Suspended State. Obviously, you need to shutdown the Guest before doing changes like that. It is not even sure the Host understands this change, if done wrong or properly, if you don't do Shutdown on the Host. In Windows things like these "seem to work" without Shutdown, but they do not always "really" work in all respects. 

So, there are multiple errors in this workflow and this becomes to explain how NAT is "crashing" - well, I would say "confused" rather since the process does not crash (not in the other thread anyway).

Thanks for your explanation, though.