NAT Service Failure with one specific VM

[Massimo Sozzi]

I'm experiencing a weird problem with NAT service on Wiindows (Host is ver.10.0.19045.5487, Guest 10.0.19045.5487)

I have other VMs configured with NAT and they all work fine. Whenever I start this specific VM, the NAT service will stop working for ALL running VMs, and for any other VM I may start. 

Symptoms:

• VM can ping and TCP connect to Host (192.168.xxx.1), but NOT to default gateway (192.168.xxx.2)
• VM can be pinged from host machine and other VMs
• VM cannot access internet

I tried:

• Restarting NAT service
• Restore NAT service defaults.
• Restarting DHCP service
• Restarting VMWare Workstation

The only fix is rebooting the host machine.

The problem started appearing with VMWare Workstation Pro 15 (I can't say what triggered it), then I upgraded to 17.6.2 build-24409262 but same behaviour.

Any hints?

[Morc001]

I suspect a network address collision, like a MAC address or IP. I guess if you disable the problem VM's network adapter the problem goes away? Although it does not make sense that the problem also resolves itself after a reboot, unless maybe a ARP table flush is the solution in that case. Check the problem VM whether the network adapter has a fixed IP or a MAC address that either matches the host's MAC address or one of the VM's.

[RaSystemlord]

I would perhaps help to know what the other Guests are - I mean, you say they are affected. Although ...

You probably have something horribly wrong in your networking configuration. The previous answer was explaining the matter. I will add to that a few things:

- why NAT stops working, well, don't know about when it really does it, that's why I used the word "horribly". But you didn't explictly say that NAT Service is shut down.
- Guests are often copies. IP changes when you boot it up in DHCP, but the identity doesn't if you didn't say "I copied it". The NAT is confused with that. Then the others do not work. If they are ALL copies, there you go, only one works (if even that).

-  why a reboot cures the problem, it may simply be that you have different computers active after "a reboot"
- you CAN have the same identity with different Guests, but they cannot be active at the same time
- if you have fixed addresses, that may cause another possibilities for same IP's for different computers
- if you have fixed adresses, but the IP-range is wrong, gateway is not found and thus internet does not work
- does something like file sharing work? Ping is NOT the same thing. If file sharing (or something like that) does work, only the gateway is wrong.

In the above, there is at least one possibility why it *looks* like NAT is not working for "any computer" and why reboot "cures" the problem - or so that it seems, but the reality behind it is not really that.

I assume that your Guests are not all in the same directory ... if they are, then all kinds of things are possible. Basically, one VM computer = one folder, everything else is just wrong (in the normal case when you don't have shared virtual disks among VMs). However, this does not really explain your case, it's more like a conspiracy theory.

[Massimo Sozzi]

NAT is going down (but service is still running) as soon as I start the VM, so I can't reach the internet with that machine, or any other using NAT, until I reboot.

Using DHCP in every VM. Just tried to generate a new MAC address but nope. I always choose "Copied it" anyway.

I created a new machine with the applications I need and it's working.

I just noticed that on the problem VM I had installed Fortinet Client and another VPN client...maybe they messed up something with the VM networking.

Is there a specific log file for the NAT service? The generic log file in the VM folder does not say much.

[SrDev]

I had an issue with similar symptoms recently.  In my case the network address for the VMWare NAT network was configured to use the same network as my host.  As soon as one of guests connected (configured for DCHP) it caused the VMWare NAT Service to crash and stop on the host until the service was manually started again.  I was able to workaround the issue by reconfiguring the NAT network to use a different subnet to the host.