DEV Community

Cover image for How I Fixed the VMware Ubuntu Network Configuration Nightmare (with Automated Scripts)
Hiiiirth
Hiiiirth

Posted on

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

#ubuntu #linux #devops #vmvare

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
Enter fullscreen mode Exit fullscreen mode

And then, after I "fixed" that:

$ ping -c 2 baidu.com
ping: baidu.com: Name or service not known
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
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=...))
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

Three rules make this work:

  1. Bottom-up, always. Skipping to layer 6 is how you spend an hour debugging Nginx when your DNS is broken.
  2. Every layer must be testable in isolation. Layer 3 uses a raw IP precisely so DNS cannot contaminate the result.
  3. 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.

Top comments (3)

Collapse
 
shieldxbot profile image
shieldx •

Việc cấu hình network trên VMware với Ubuntu thực sự là một cơn ác mộng, nhất là khi Netplan tự động ghi đè các thiết lập thủ công hoặc khi file cấu hình bị lỗi cú pháp mà không báo trước rõ ràng. Mình từng mất cả buổi chiều chỉ để debug lỗi không nhận được IP từ DHCP dù card mạng vẫn hiện trạng thái connected. Sử dụng script để tự động hóa việc fix lỗi này là hướng đi đúng đắn vì nó giúp loại bỏ sai sót do con người khi phải gõ lại các file YAML phức tạp. Một mẹo nhỏ là bạn nên luôn backup file netplan cũ trước khi chạy script để có thể rollback ngay lập tức nếu cấu hình mới làm mất kết nối SSH.

Collapse
 
hiiiirth profile image
Hiiiirth •

hah Thanks for sharing ur experience, u nailed what the pain that Netplan's silent YAML errors and the risk of losing SSH access ,these are the real nightmares. So yeah the rollback tip u mentioned is absolutely critical. before applying any new netplan configs, keep a working backup or better yet that use sudo netplan try which auto-reverts after 120s if u lose SSH. Actually, the first time I used NAT to set up a network, there were no errors at all that i even thought i was a superhero LMAO

Collapse
 
hiiiirth profile image
Hiiiirth •

If anyone reading this is currently stuck in that loop right now, feel free to drop a comment or DM me. iam happy to share some troubleshooting steps!