How I Fixed the VMware Ubuntu Network Configuration Nightmare (with Automated Scripts)

Hiiiirth — Tue, 06 Oct 2026 16:03:13 +0000

TL;DR — VMware + Ubuntu networking breaks in ways that look like four different problems but are actually one. Here's the 6-layer checklist I now run, the three mistakes that cost me most of the evening, and the script I wrote so I never do it by hand again.

"Three hours, five reboots, and one blinking cursor"

I set up an Ubuntu 26.04 LTS VM on VMware Workstation Pro 17 to learn Linux properly. The installation took twenty minutes. The networking took three hours.
My terminal sat on this for most of it:

$ ping -c 2 192.168.182.2
Destination Host Unreachable

And then, after I "fixed" that:

$ ping -c 2 baidu.com
ping: baidu.com: Name or service not known

The VM could reach its gateway but could not resolve a single hostname. So I did what everyone does: rebooted five times, toggled settings I did not understand, and pasted forum commands into a root shell — which is exactly how a twenty-minute problem becomes a reinstall.

Since then I have read a lot of "VMware Ubuntu can't connect" threads, and the same three root causes show up again and again.

Mistake #1: Picking a network mode without knowing how to verify it

VMware offers three modes:

Mode	Your VM sits	Outbound internet	LAN can reach your VM
NAT	Behind your host (host acts as a router)	Yes	No (unless you add port forwarding)
Bridged	As a peer on your physical LAN	Yes	Yes
Host-only	On a private link to the host only	No	No

Choosing between them is easy. Knowing which one you are actually on — and what it implies — is the hard part.

Here is the one command that answers it:

ip route

default via 192.168.182.2 dev ens33 proto static
192.168.182.0/24 dev ens33 proto kernel scope link src 192.168.182.128

Read it bottom-up:

The second line says: this subnet (.0/24) is directly attached to ens33; I do not need a gateway for it.
The first line says: for anything else, hand the packet to 192.168.182.2. That .2 address is the tell. Under NAT, the gateway is VMware's virtual router — which means your host can reach the VM, but your colleague's laptop on the same Wi-Fi cannot. Under Bridged, the gateway is your real router, and the VM is visible to the whole LAN.

That single difference decides whether your "it works for me" demo works at all.

Mistake #2: A service listening on 127.0.0.1 while you test from the host

Symptom: the service is definitely running. curl inside the VM returns a page instantly. The browser on your host times out.

sudo ss -tlnp

LISTEN 0 128   127.0.0.1:8080   0.0.0.0:*   users:(("python3",pid=...))
LISTEN 0 128     0.0.0.0:22     0.0.0.0:*   users:(("sshd",pid=...))

The first line only accepts connections from inside the VM. The second accepts them on any interface the firewall allows. This is not a VMware problem, a Netplan problem, or a firewall problem — it is an address-binding problem, and it is where a huge share of "works locally, not remotely" tickets are born.

Fix the bind address, then re-test. Do not touch the firewall until you have confirmed which address the service is on.

Mistake #3: The slow-VM trap — and the clipboard you did not know was broken

This one is not about ports at all, and it is the one nobody warns you about.

3a. Your host may be holding the CPU virtualization extensions.

On modern Windows, Memory Integrity (VBS/HVCI) reserves VT-x, so VMware cannot drive it directly and instead coexists via the Windows Hypervisor Platform (WHP). You can check which mode you are actually in, in vmware.log:

Monitor Mode: ULM      # coexisting through WHP
Monitor Mode: CPL0     # VMware owns VT-x 
directly

If you are on ULM and wondering why nested virtualization refuses to work, that is why. (And do not tick "Virtualize Intel VT-x/EPT" in the VM's processor settings in this mode — the VM simply will not boot.)

3b. If open-vm-tools is missing, your clipboard is silently dead.
You copy a command on the host, press paste in the VM terminal, and nothing happens. Debugging network configuration without copy-paste is a different, much slower game — and it burns time you will never attribute to the right cause.

dpkg -l | grep open-vm-tools        # want "ii" = installed
sudo apt install -y open-vm-tools open-vm-tools-desktop
# then log out and back in (or reboot) — the user-space parts only load on a fresh session

The 6-layer checklist I run instead of guessing

This is the part worth stealing. A request has to pass six gates. Test them bottom-up, and stop at the first one that fails:

ip addr show | grep inet      # 1. Do I have an address at all?
ping -c 2 <your-gateway>      # 2. Can I reach my gateway?
ping -c 2 223.5.5.5           # 3. Can I leave the subnet? (raw IP — no DNS involved)
dig example.com +short        # 4. Does DNS resolve?
nc -zv example.com 80         # 5. Is the remote port open?
curl -sI http://example.com   # 6. Does the application answer?

Three rules make this work:

Bottom-up, always. Skipping to layer 6 is how you spend an hour debugging Nginx when your DNS is broken.
Every layer must be testable in isolation. Layer 3 uses a raw IP precisely so DNS cannot contaminate the result.
After fixing a layer, re-test from the top. DNS being fixed does not mean the site loads.

I have never needed a seventh check.

What I deliberately left out of this post

The checklist above is 80% of the value, and it is free — please use it.

But the part that actually ate my evening was not the checklist. It was the tedious, easy-to-get-wrong detail around it:

Netplan YAML edge cases. One wrong indent and you are locked out of your own VM. netplan try exists and auto-rolls-back after 120 seconds — I did not know that, and I learned it the hard way.
An APT source list that half-applied. A sed replacement matched part of a hostname and left a prefix dangling, so package updates were silently coming from two different mirrors at once.
A phantom source file. A single typo in one cp command created ubumt.sources. APT loads anything ending in .sources, so a mirror I believed I had removed was still live — and the "wrong" file I was inspecting was never the one doing the damage.
Verifying DNS without trusting /etc/resolv.conf. On Ubuntu it points at 127.0.0.53, the local stub — not your actual upstream. Reading that file tells you almost nothing.
Knowing which of these changes are safe to roll back, and how.

Diagnosing and fixing all of this took me hours. To save you the time, I packaged the full troubleshooting document, the automated configuration shell scripts, and the rollback plan into a "Doc + Scripts" bundle. If you're interested in getting a copy, feel free to DM me here, and I'll share the details with you!

Every check in it is one I broke my own VM to learn. If you would rather keep debugging by hand — genuinely, more power to you: the checklist above plus man pages will get you there.

Hit a specific error message while setting this up? Drop it in the comments and I will take a look — I read every one.

DEV Community: Hiiiirth