Vagrant up fails with "failed to locate NAT vmnet device" with VMWare provider

After running Vagrant with the Vagrant VMWare Utility on VMWare Workstation Pro successfully for about 6 months, vagrant up is now failing with the following output:

$ vagrant up --provider=vmware_desktop
Bringing machine 'default' up with 'vmware_desktop' provider...
==> default: Verifying vmnet devices are healthy...
Vagrant encountered an error while attempting to prune unused
port forward entries:


  failed to locate NAT vmnet device

The behavior started after I tried to install Docker, including the Windows Subsystem for Linux (WSL) and Hypervisor, and had to uninstall it. I’ve tried with and without various combinations of Hyper-V, WSL, and Windows Hypervisor platform turned on and off as Windows Features (in “Settings” > “Turn Windows Features On and Off”).

Following this Vagrant post describing a similar issue, I’ve also tried “vagrant cap provider scrub_forwarded ports” and removing the nat.json file in C:\ProgramData\hashicorp\vagrant-vmware-desktop\settings

Is there a troubleshooting doc that I’ve missed that might help? Any suggestions are much appreciated!

Vagrant 2.2.19
Vagrant VMWare Utility 1.0.21
VMware® Workstation 16 Pro 16.2.3 build-19376536 (box Ubuntu 18.04)
Windows 10 Enterprise 20H2 OS Build 19042.1586

I killed a few processes under task manager anything to do with VMWare/VMware workstation and it worked. So try killing whatever virtualization platform that may be running in the background and try vagrant up again switching between platforms etc.

Next, I ran vagrant cap provider scrub_forwarded_ports and got an error:

failure encountered: The virtual network type of vmnet8 is not NAT

So I modified vmware virtualbox’s network setting to set the vmnet8 network to NAT

then re-ran vagrant up --provider=vmware_workstation and was able to proceed.

Yeah, as @fergatronanator suspects, this sounds like a misconfiguration issue with VMware Workstation’s network settings, as vmnet8 is expected to be NAT.

Otherwise, the VMware logs might give some hints.