Post 17.0.2 to 17.5 upgrade results in no networking (NAT) for VMs

[jfrostjr]

I upgraded from 17.0.2 to 17.5 on my Windows 11 Pro 22H2  based device today.   After completing the upgrade I can no longer get my VMs to connect to the default NAT.  Multiple reboots of the host do not make a difference or upgrading VMWare Tools on the VMs (Windows 10 Enterprise 22H2))

[mlzxdzl]

I have the same problem.  Do you solve this problem?

[Sajesh Rao]

Hi  

Please provide below details as the issue did not repro from our end. 

1. Are you facing issue only in NAT mode? Bridge mode is working fine? If so please try out a clean installation of WS 17.5 
2. If the issue exists in NAT mode only, are they able to get IP in VMs? ping works between host and VM ?
3. Please provide VM support bundle. (Select VM >> Help >> Collect Support data ..)
4. Please provide the ISO used for Win10-Enterprise 22h2 version
     - I have downloaded from official website(https://www.microsoft.com/en-in/software-download/windows10) and no repro from our end. I used Windows 10 Pro edition
     - Host - Win11 22h2, GuestVM - Win10 22h2

Clean Install Workstation Pro/Player:
-----------------------------------------------
1) Uninstall WS Pro/Player.
2) Go to this location - C:\ProgramData\VMware and delete the folders for VMware Workstation and VMware Player.
3) Go to this location - C:\Users\dtomar\AppData\Roaming\VMware and delete all the files inside
4) Go to this location - C:\Program Files (x86)\VMware and delete the folders for VMware Workstation and VMware Player.
5) Install WS Pro/Player

Thanks,

[jfrostjr]

This worked in my situation:

Clean Install Workstation Pro/Player:
-----------------------------------------------
1) Uninstall WS Pro/Player.
2) Go to this location - C:\ProgramData\VMware and delete the folders for VMware Workstation and VMware Player.
3) Go to this location - C:\Users\dtomar\AppData\Roaming\VMware and delete all the files inside
4) Go to this location - C:\Program Files (x86)\VMware and delete the folders for VMware Workstation and VMware Player.
5) Install WS Pro/Player

[Flawinne_F]

Unable to do internal debugging in the "VMware NAT Service", I did this action to resolve my problem.
It is clear that there is a conflict on the my 2 DELL laptops that I own with the new executable "vmnat.exe".

Even by doing a complete clean of files and registry in system mode, nothing fixed my problem except the workaround that I applied on my laptops.
I hope a future version will fix my problem.

workaround:
Copy the "C:\Windows\SysWOW64\vmnat.exe" to the "%userprofile%\Desktop".
launch the update to version 17.5 execute the update.
Stop the “VMware NAT Service” service
rename the file "C:\Windows\SysWOW64\vmnat.exe"
copy the "%userprofile%\Desktop\vmnat.exe" to "C:\Windows\SysWOW64"
Start the VMware NAT Service

My problem is fixed, no more malfunction of the "VMware NAT Service" service, communication from the VM to its default gateway is restored.

[chytons]

This workaround solved my issue.
Thanks to 

[ERFulton]

This resolved the NAT issue(s) for my install too. No more high CPU on my ThinkPad x280 as well.
Thank you

[erobrich]

I tried:

- Uninstall VMware Workstation, clean folders, reinstall

- Replace vmnat.exe with the 17.0.2 version

I'm still without network in my 17.5 VMs set as NAT.

Guess I'm stuck using bridged networking for a good while.

[erobrich]

Because I randomly lose DHCP or DNS or both so frequently on NAT'd VMs, I now have a script:

net stop "VMware NAT Service"
net stop "VMnetDHCP"
net start "VMware NAT Service"
net start "VMnetDHCP"

I run this as a scheduled task multiple times a day, and on-demand if my fans kick on or I lose DNS or DHCP.

I really hope I can get rid of it soon.

[VMware Community Member]

I have the same problem with 17.5 on my VMs. Restarting "VMWare NAT Service" every hour.

I worked with 12.5 for nearly ten years perfectly fine and Upgraded to 17.5.
But i con not adress this problem to vmware, because i am not connected with the main account, and dont know how to fix this.

[Bascisco]

I am still having this that after a while all my VM's network connectivity over the host system fails.

VM-ware: 17.5

Host: Windows 11H2 enterprise host machine.

Guests: Windows 10 Pro 22H2, Ubuntu 22.04

This work-around resolved it temporary without reinstall of VM workstation Pro 17.5 or restarting even the VM's.

net stop "VMware NAT Service"
net stop "VMnetDHCP"
net start "VMware NAT Service"
net start "VMnetDHCP"

 

 

 

 

 

 

[erobrich]

Why is this possible?

- VMware NAT service is 24% CPU

- VMware Workstation VMX is 5.1% CPU

More of my machine is doing the NAT than doing the work!

As I was grabbing this screenshot, the NAT service jumped up to 30% while the VMX was at 0.9%. Wish I had grabbed that screen shot in time.

[Bascisco]

Hello,

I applied to workaround to use the vmnat.exe version 17.0.2 on my 17.5.1 VM Workstation Pro installation. This cured for now the exact symptoms as described.

Of course VM needs to check what is the difference in code between 17.0.2 and 17.5.1 vmnat.exe.

[ERFulton]

I've been using vmnat.exe 17.0.0 build-20800274 without issue on Workstation Pro 17.5.1 

[chytons]

These suggestions did not work in my case. I had to uninstall 17.5 and reinstalled 17.0.2 before I could have internet in the VMs.

Below are my issues:
After upgrading from 17.0.2 to 17.5, I noticed that the VMs could not access the internet.
The VMs did receive IP addresses from NAT.
I could ping the VMs from the host.
I could ping the host from the VMs.
I couldn't ping the NAT gateway from the VMs.
The bridge network was working.

[jfrostjr]

Did you attempt the clean install (all steps, not just uninstall from control panel) as others and myself have reported as working?

 

[visentet]

Hi jfrostjr, yes, I did a clean install, but vmnat has a high use of cpu. I did what says in https://communities.vmware.com/t5/VMware-Workstation-Pro/High-CPU-usage-by-vmnat-exe-after-upgrade-to-VMware-Workstation/m-p/2992677#M183318

[Dillman1d]

This is really discouraging. I am facing the same issue. NAT is no longer working. Cannot ping the NAT gateway. If I go bridged it partially works. My VMs are can access the internet but I can only ping the gateway using IPV6. This really stinks.

[chytons]

Try the workaround @Flawinne_F suggested

I have not had any other NAT related issues after trying that.

[Dillman1d]

This seems a bit extreme. This is kind of a shotgun fix. Based upon testing several hosts (all windows), all you need to do is replace the VMNAT.EXE file with the one from 7.02. You will have to stop the service to replace the file. 

 

Works for me on 3 Hosts. Windows 10, Windows 11 and Server 2012.

David

[erremm]

Same problem here:

• Host: Windows 10 Enterprise 22H2
• Guest: Windows 10 Pro 22H2

Bridged configurations work. Virtual machines with NAT do not. Downgrading (reinstalling) 17.0.1 brings back NAT functionality.

• ping ip4/ip6/hostname address from host to guest works
• ping ip4/ip6 address from guest to host not working
• general (internet) network access on guest not working
• ping hostname from guest to host working (on IPv6 interface)

Thanks for a solution (except for bridging) the vms network connection.

[compuaid]

Same problem here as well except my bridged networking does not work either.

Host: Windows 10 Pro 22H2

Guest: Windows 10 Pro 22H2

 

[THENICKCHEESE]

Same problem as erremm:

Host: Windows 10 Pro 22H2

Guests: Kali Linux 2023.3, Windows 10 Pro 22H2, Windows Server 2019, Windows 7, Ubuntu 22.04

• ping ip4/ip6/hostname address from host to guest works (for all guests)
• ping ip4/ip6 address from guest to host not working (for all guests)
• general (internet) network access on guest not working (for all guests)

 

Version 17.0 works perfectly fine

 

[Flawinne_F]

I have the same problem, noticed that it is the nat service which is failing, but I have not found a solution, even after starting the service it crashes again after a few seconds.

event viewer error:

Faulting application name: vmnat.exe, version: 17.5.0.49595, time stamp: 0x652515c0
Faulting module name: vmnat.exe, version: 17.5.0.49595, time stamp: 0x652515c0
Exception code: 0xc0000005
Fault offset: 0x00012c41
Faulting process id: 0x0x6AA8
Faulting application start time: 0x0x1DA05D476CC2063
Faulting application path: C:\WINDOWS\SysWOW64\vmnat.exe
Faulting module path: C:\WINDOWS\SysWOW64\vmnat.exe
Report Id: eb919a7b-acd5-4f5c-9130-226f6cdd9fbf
Faulting package full name:
Faulting package-relative application ID:

event viewer information:

Fault bucket 1711524447639117690, type 1
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: vmnat.exe
P2: 17.5.0.49595
P3: 652515c0
P4: vmnat.exe
P5: 17.5.0.49595
P6: 652515c0
P7: c0000005
P8: 00012c41
P9:
P10:

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.f66f1948-29dc-4bf4-b6a0-23ed030b9909.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.f1c94acf-b910-4c6d-984b-1d7126af41bc.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.6a6342f0-6e60-4afa-8ddc-deb1db16b4e4.tmp.csv

[Flawinne_F]

PC is Dell Precision 7520 - Xeon E3-1575M - 64GB - Windows 11 pro 22H2 build 22621.2428

I have the same problem, it is the VMware Nat service which falls and even after restarting the service, it falls when starting the virtual machine (Windows server 2022, windows 11, windows 10) ping dns google not ok

Linux not impact ping dns google is ok.

error event viewer:

Faulting application name: vmnat.exe, version: 17.5.0.49595, time stamp: 0x652515c0
Faulting module name: vmnat.exe, version: 17.5.0.49595, time stamp: 0x652515c0
Exception code: 0xc0000005
Fault offset: 0x00012c3e
Faulting process id: 0x0x6540
Faulting application start time: 0x0x1DA05D7DAF5F2D6
Faulting application path: C:\WINDOWS\SysWOW64\vmnat.exe
Faulting module path: C:\WINDOWS\SysWOW64\vmnat.exe
Report Id: 4bd52010-5fda-47d5-9b56-7ecd3b75eef7
Faulting package full name:
Faulting package-relative application ID:

Source
VMware NAT Service

Summary
Stopped working

Date
‎23/‎10/‎2023 21:50

Status
Report sent

Description
Faulting Application Path: C:\Windows\SysWOW64\vmnat.exe

Problem signature
Problem Event Name: APPCRASH
Application Name: vmnat.exe
Application Version: 17.5.0.49595
Application Timestamp: 652515c0
Fault Module Name: vmnat.exe
Fault Module Version: 17.5.0.49595
Fault Module Timestamp: 652515c0
Exception Code: c0000005
Exception Offset: 000104f3
OS Version: 10.0.22621.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 2beb
Additional Information 2: 2beba6fb4680d73a8c78ca7c24ccdb46
Additional Information 3: 5172
Additional Information 4: 5172835497b9e2456a90f14d3db060af

Extra information about the problem
Bucket ID: 07c138315b1918d9d29a8202860ef5b0 (1340526786446816688)

[LBrin]

Same Issue here - Upgraded from VMWare Workstation Pro 17.2 to 17.5 - Internet would no longer connect via NAT.

Had to do the clean install route for VMWare Workstation Pro 17.5

Clean Install Workstation Pro/Player:
-----------------------------------------------
1) Uninstall WS Pro/Player.
2) Go to this location - C:\ProgramData\VMware and delete the folders for VMware Workstation and VMware Player.
3) Go to this location - C:\Users\dtomar\AppData\Roaming\VMware and delete all the files inside
4) Go to this location - C:\Program Files (x86)\VMware and delete the folders for VMware Workstation and VMware Player.
5) Install WS Pro/Player

[visentet]

Hi!!

Same here in a Windows 7 64. Also, VMware NAT Service uses between 20 and 30% of cpu.

I'm reconsidering downgrade, it's insufferable.

[DavidChief]

A possible solution to 17.5 NAT issues is posted here

https://communities.vmware.com/t5/VMware-Workstation-Pro/High-CPU-usage-by-vmnat-exe-after-upgrade-to-VMware-Workstation/m-p/2992063/thread-id/183199

[erobrich]

The possible solutions fall into 2 categories: downgrade to 17.0 (either all or parts) or restart the service frequently. Neither is a true solution.

Notable mention to uninstalling, scrubbing directories, and reinstalling, which equal number of people say doesn't solve the issue. And notable mention to upgrading from VMware to Hyper-V.

Sadly, because some report "solved", I fear VMware and their parent company (who owns them today?) decided this is sufficiently resolved to not investigate and fix.

[ErlandSommarsko]

> The possible solutions fall into 2 categories: downgrade to 17.0 or restart the service frequently. Neither is a true solution.

Hm, there is a third: Replace the vmnat.exe with the one from 17.0, see the link in the post just above yours. (And the answer is the first or second reply in that long thread.)

What I have found since I installed 17.5.1 is that I have to restart the service every now and then, but with my usage profile it is not unbearable. Before 17.5.1 came out, I used the vmnat.exe from 17.1 as suggested by someone. (At least I seem to recall that it was 17.1 and not 17.0.) I found that it was erratic. The network connection came and went.

Of course, the only true solution is that VMware fixes the problem.

 

[erobrich]

Your "the third" falls into the "downgrade" scenario. Some downgrade the entire product, some only downgrade vmnat and/or vmdns.

I don't share your symptoms. I'm on 17.5.1, and I constantly see vmnat.exe at 20% or more -- even moments after restarting it.

[ErlandSommarsko]

Yeah, but it's quite a difference between only downgrading the service and downgrading the entire product.

I seem to be saved from the problem with the service pegging the CPU.

And I may guess that this is part of the equation why VMWare has not fixed this. To fix this, they need a repro, and it may be more difficult to repro than we would think. (There my be loads of people who are using NAT with 17.5 without hitches. But they would of course never see these threads to tell us.)

[erobrich]

I'm struggling with this as well.  Win 11 22H2 for both host and guests, all fully patched.  All guests use NAT networking.  Upgraded from VMware Workstation 17 to 17.5, and after some time, all the guests lost DNS.  I see the VMware NAT service is using 17-25% of host's CPU ... and my laptop fans confirm this.  I went into the VMware virtual network adapter, added my host's DNS as a manual DNS entry, refreshed guest's network connection and flushed DNS, and network connectivity was restored.  This will work great until my laptop moves to another network.  I then went back in and cleared the manual DNS, flushed guest's DNS and refreshed IP, and it still had DNS resolution from the guests.  Yes, I could down-grade the NAT service to 17.0.2, but I'm really trying not to.  Maybe we'll quickly get a 17.5.1 patch release that solves this?

[gsmithx2]

The aforementioned workaround did indeed resolve my NAT issue, but only temporarily. This morning, it was back. I saw the other workaround mentioned was to save the prior version, but it's already gone on my machine. However, restarting the VMware NAT Service has given me (at least temporary) relief. Not sure how long it will last, but my guests have network back for now and I can probably make due until 17.5.1 comes out, which I hope is soon!

[Xaiamas]

Sams issue Windows 11H2, with many guests. Solution did not solve. NAT still fails with ~20% CPU usage.

[chytons]

Did you try the workaround  suggested?

[Steve_J_D]

A reinststall is not a workaround.  I've had to reinstall 4 times now.  This needs addressed.

[Bascisco]

[Dillman1d]

I agree. ALL 16 of my VMs are offline unless I go bridged. Even bridged, IPV4 is not working only IPV6. 

[ErlandSommarsko]

Adding my voice to the sound of the crowd...

My symptoms are similar but not exactly the same as others have reported in the thread. I upgraded to 17.5 and had no issues for a month. Then all of a sudden, I found that my VMs did not have network connectivity. Looking closer I found that I could ping a random address on the internet, and the culprit was that the DNS was not working. I tried using the Virtual Network Editor to set the DNS, but that only helped for a short while.

I shut down my host computer and was out of town for more than a week, but the issue was still there when I came back.

I don't see the issue with vmnat.exe taking a lot of CPU.

I saw the suggestion to restore vmnat.exe from 17.0.2, but that did not really help.

Interesting enough, what I have found is that "not working at all" is not a correct description. Rather it is quite erratic, but occasionally some VMs have DNS for a while. Sometimes I get the impression that VMNAT gets overwhelmed - I have quite a few VMs running. Then again, I have had this for a long time without hitches, so the whole thing remains a mystery.

I should add that this applies to NAT. Bridged seems to work, and I've set some VMs that I want to be connected to Bridged. But if NAT was working before, it should work now, I think.

[CitizenVM]

I had the same (more or less) problems as everyone here.

I fixed this by simply modifying the VM configuration to change the vNic's in the VM to Bridged...and then set them back to NAT.

I didn't investigate this thoroughly but my guess is that there is some mis-configuration happening in the VM's .vmx file after upgrading to 17.5.

By changing the vNic's from NAT to Bridged and then back to NAT...I'm guessing something gets re-written in the .vmx file that fixes the problem. 

Worked for me anyways...

Good luck Folks.

[ErlandSommarsko]

Alas, I tried that without success. More precisely, I had changed some VMs to bridged. When it seemed that reverting to the older vmnat.exe fixed the issue, I changed them back to NAT, but I soon noticed that the problem was back.

[0WayneH0]

I just found this thread since I was running into issues with a Windows 11 Host (10.0.22631.3296) and Workstation 17.5.1 where none of my VMs would connect to the internet using NAT (and I also could not get it to work with bridged).

As it turns out, I am using a new laptop, so it was a fresh 17.5.1 (install the latest and "greatest" right?) and as a consequence I didn't even consider uninstalling/reinstalling.

I can confirm, however, that using the vmnat.exe from 17.0.2 seems to fix the problem for me also. That's 1/2 day I can't get back, but at least I'm on track now.

Thanks for putting some light on this issue.

[TanquenETG]

So they broke this 6 months ago and there is still no fix?

[Technogeezer]

Let's see if we can get VMware's attention - they don't monitor these forums on a regular basis:

 - can we get a comment from VMware on this issue? Are you folks aware of this?  It seems to be a chronic problem with Workstation's NAT networking since 17.5. 

[Pierre Schellner]

VMware Workstation 17.5.2 Pro Release Notes

17.5.2 is out and should fix it. Someone can confirm?

[James Sprinkle]

I've been using 17.5.2 the last couple of days. I did not observe the high CPU utilization. However, I still frequently lost network connectivity on VMs, and had to restart the VMware NAT Service to restore connectivity. This was so disruptive to me that I've reverted vmnat.exe to the 17.0.2 version again.

[Pierre Schellner]

test

[Pierre Schellner]

It looks like 17.5.2 is official out and solves the problem. Maybe someone can confirm.

Resolved Issues

• VMware NAT Service uses high CPU even with no virtual machine running

  On Workstation Pro 17.5.0 and 17.5.1, vmnat.exe might have high CPU utilization even when no virtual machine is running.

  This issue is resolved.

  VMware Workstation 17.5.2 Pro Release Notes

[Pierre Schellner]

It looks like they found a fix. Did not test it.
Release 17.5.2 official today:

VMware Workstation 17.5.2 Pro Release Notes

Resolved Issues

• VMware NAT Service uses high CPU even with no virtual machine running

  On Workstation Pro 17.5.0 and 17.5.1, vmnat.exe might have high CPU utilization even when no virtual machine is running.

  This issue is resolved.
  
  
  

  Maybe someone will test it :)

[EColwell]

NAT service is still broke for me in 17.5.2, I reverted back to the 17.0.2 NAT exe and all is well again.  They may have fixed the "high CPU" in 17.5.2, but the service still randomly stops and does not run reliably.