The VM boots fine but the browser goes nowhere and there is no network at all. In VMware this is rarely a guest fault. It is usually a disconnected virtual adapter, the wrong network mode for what you expected, or one of VMware's own host services standing still. Here is the order that finds it.
A VMware network has three places to break: the virtual adapter's own settings, the mode it runs in, and VMware's services on the host. Most people reinstall guest drivers first - the least likely culprit. Start at the adapter checkbox, understand what NAT, Bridged and Host-only actually promise, then test from inside the guest in an order that tells you exactly where the chain snaps.
Open VM Settings, then Network Adapter. If there is no adapter listed, add one - a VM built from a minimal template can genuinely have none. If one exists, confirm Connected and Connect at power on are both ticked. An unticked Connected box is exactly like a pulled cable, and it survives reboots and guest reinstalls, which is why people chase it for hours inside the guest.
Each mode makes a different promise. NAT hides the VM behind the host - the VM gets a private address from VMware and shares the host's connection, which is why NAT works almost everywhere. Bridged puts the VM directly on your real network as its own device with its own IP from your router - needed when other machines must reach the VM, but exposed to office network rules. Host-only connects the VM to the host and nothing else: no internet, by design, forever.
Inside the guest, run the tests in this sequence - the first failure names the broken layer:
ipconfig - does the adapter have a real address, or a 169.254.x.x address, which means DHCP never answeredping 8.8.8.8 - tests raw internet reachability without DNSA VM with a 169.254 address on NAT points straight at the host's VMware DHCP service, covered next.
NAT mode depends on two Windows services on the host: the VMware NAT Service and the VMware DHCP Service. Open services.msc on the host and make sure both are running and set to start automatically. If both are healthy and NAT still fails, the heavier reset is Virtual Network Editor, then Restore Defaults - be aware it rebuilds all virtual networks, so note any custom subnets first.
Bridged mode on a laptop with Wi-Fi, Ethernet and a VPN adapter often guesses wrong about which physical adapter to bridge to. In the Virtual Network Editor, set the bridged network to the specific adapter you actually use instead of Automatic. And an honest office note: some managed networks block extra MAC addresses per port - a bridged VM can be refused by policy while NAT sails through. That is the network protecting itself, not your VM misbehaving.
The video configures a new VM the right way from the start - adapter, mode and all - so these network surprises never happen.
Watch Full VideoIt means the guest asked for an address by DHCP and got no answer, so Windows invented a fallback address that routes nowhere. On NAT, check the host's VMware DHCP Service. On Bridged, the VM may be bridged to a dead adapter or blocked by the network.
On Bridged, yes - the VM is a full citizen of the LAN with its own IP, reachable like any PC. On NAT, no - other machines cannot initiate connections to it, which is one reason NAT is the safer default for a personal VM.
Almost certainly Host-only, which connects the VM to the host alone by design. Switch the adapter to NAT for shared internet through the host, or Bridged if the VM needs its own address on the real network.