This article focuses on the common CentOS 9 failure mode in VMware NAT networking where the VM has an IP address but still cannot access the internet. It provides a closed-loop workflow for diagnosis, repair, and verification, covering DHCP, default routes, DNS, and firewall blocking. Keywords: CentOS 9, VMware NAT, NetworkManager.
Technical specifications provide a quick snapshot.
| Parameter | Description |
|---|---|
| Operating system | CentOS 9 |
| Virtualization platform | VMware Workstation |
| Network mode | NAT (typically VMnet8) |
| Core protocols | DHCP, ICMP, DNS, IPv4 |
| Core components | NetworkManager, nmcli, firewalld |
| Typical NIC name | ens160 |
| Original article popularity | About 662 views, 20 likes, 14 bookmarks |
This guide applies to CentOS 9 connectivity failures in VMware NAT environments.
There are three common symptom patterns: the virtual machine has already obtained a 192.168.x.x address, but ping to the gateway fails; public IP connectivity does not work; or domain lookups return “Name or service not known,” or resolve successfully but remain unreachable. In most cases, the root cause falls into one of four layers: routing, DNS, NAT services, or firewall behavior.
The prerequisites are straightforward: the Windows host must already have working internet access, the VMware virtual NIC must be connected and configured for NAT, and CentOS 9 must detect ens160. If the host itself has no network connectivity, troubleshooting inside the guest is meaningless.
A three-step diagnosis can quickly isolate the problem layer.
First check the IP address, then test the gateway, and finally test a public IP and a domain name. This sequence quickly separates four issue classes: no address assigned, routing not applied, DNS failure, or blocked ICMP.
# Check NIC address and status # Key point: confirm whether ens160 has an IPv4 address
ip addr show ens160
# Check the routing table # Key point: confirm whether a default route exists
ip route show
# Test the gateway and external connectivity # Key point: separate routing issues from DNS issues
ping 192.168.139.2 -c 4
ping 223.5.5.5 -c 4
ping www.baidu.com -c 4This command set provides a minimal diagnostic loop by testing the address, route, external network, and domain resolution one by one.
Diagnostic results should map to specific remediation actions.
If there is no IPv4 address, DHCP or the connection profile is likely broken. If the gateway is unreachable, suspect NIC configuration or the VMware NAT network first. If a public IP is reachable but domain names fail, DNS is usually missing. If a domain resolves to an IP but ping still fails, firewalld is a common reason because it may block ICMP.
| Symptom | Likely root cause | Priority action |
|---|---|---|
| No IPv4 address | DHCP or connection profile failure | Fix the NIC configuration |
| Gateway unreachable | Default route or NAT network failure | Repair the configuration and reset VMnet8 |
| Public IP works but domain names fail | DNS not applied | Add or fix DNS |
Domain resolves but ping fails |
Firewall blocks ICMP | Check or disable firewalld |
The NIC connection profile is the most common repair point for NAT mode failures.
CentOS 9 uses NetworkManager to manage connections by default. In many cases, the NIC itself is fine, but the .nmconnection file uses a problematic name, DNS is missing, or routes are being ignored. In particular, GUI-created profiles such as “Wired connection 1” with Chinese filenames are more likely to cause compatibility issues in migrated or automated environments.
# Enter the connection profile directory # Key point: locate NetworkManager connection files
cd /etc/NetworkManager/system-connections/
# Back up the original configuration # Key point: avoid losing rollback capability after a bad edit
cp "有线连接 1.nmconnection" ens160-backup.nmconnection
# Rename it to an English filename that matches the NIC # Key point: reduce compatibility issues
mv "有线连接 1.nmconnection" ens160.nmconnectionThe value of this step is that it aligns the connection name with the interface name and reduces the chance of NetworkManager misidentifying the profile.
The ipv4 section determines whether DHCP, DNS, and the default route all take effect.
Only modify the fields you actually need, and do not change the uuid. method=auto tells the system to obtain an address through DHCP, dns= restores name resolution, and ignore-auto-routes=false ensures the default gateway provided by DHCP is not ignored.
[connection]
id=ens160
uuid=keep-the-original-value # Key point: do not modify the uuid casually
interface-name=ens160 # Key point: this must match the actual NIC name
[ipv4]
method=auto # Key point: use DHCP to obtain IPv4 automatically
dns=223.5.5.5;8.8.8.8;114.114.114.114; # Key point: explicitly add DNS servers
ignore-auto-dns=false # Key point: allow automatic DNS and manual DNS to coexist
ignore-auto-routes=false # Key point: do not ignore DHCP-delivered routesThe goal of this configuration is to fix three issue classes at once: address acquisition, domain resolution, and missing default routes.
Note: The original content contains formatting noise in the configuration snippet. In actual editing, make sure the section name is
[ipv4]and nota[ipv4].
# Fix file permissions # Key point: NetworkManager refuses to load the profile if permissions are incorrect
chmod 600 /etc/NetworkManager/system-connections/ens160.nmconnection
chown root:root /etc/NetworkManager/system-connections/ens160.nmconnection
# Restart and reconnect the NIC # Key point: apply the new configuration immediately
systemctl restart NetworkManager
nmcli device disconnect ens160
nmcli device connect ens160This step makes the configuration actually take effect. In many cases, “I changed the file but nothing happened” comes down to incorrect permissions or a service that was never reloaded.
When the gateway is still unreachable, shift your investigation to the VMware NAT network itself.
If the CentOS-side configuration is already correct but ping 192.168.x.2 still fails, VMnet8 NAT or DHCP services are usually in an abnormal state. At that point, continuing to edit guest configuration has limited value, so you should inspect the host-side virtual network directly.
On the host, the key steps are: power off the VM, open VMware’s Virtual Network Editor, select VMnet8, and click “Restore Defaults.” Then restart VMware NAT Service, VMware DHCP Service, and VMware Workstation Server from Windows Services.
# Shut down the virtual machine # Key point: power off the guest before resetting VMware NAT
poweroffThis command only performs a safe shutdown. The actual NAT reset happens on the host side.
firewalld can create the illusion that DNS works while ping still fails.
In lab or test environments, you can temporarily disable the firewall to verify whether the path is open. In production, it is better to allow ICMP or specific services as needed rather than permanently disabling the firewall.
# Temporarily stop the firewall # Key point: immediately verify whether ICMP blocking is the cause
systemctl stop firewalld
# Disable it at boot # Key point: prevent the issue from reappearing after reboot
systemctl disable firewalld
# Check status # Key point: confirm the service is inactive
systemctl status firewalldThis command set helps determine whether the network issue is caused by system-side security policy.
Verification must cover routing, gateway, host reachability, public IP access, and DNS.
After the repair, testing only ping baidu.com is not enough. A complete acceptance check should confirm that the default route exists, the gateway is reachable, the host-side VMnet8 adapter is reachable, a public IP is reachable, and domain resolution works. Only when all five checks pass can SSH, yum, and VS Code Remote SSH remain stable.
# Check the default route # Key point: you should see a default via gateway dev ens160 entry
ip route show
# Verify gateway, host, public IP, and domain step by step # Key point: build a full end-to-end validation chain
ping 192.168.139.2 -c 4
ping 192.168.139.1 -c 4
ping 223.5.5.5 -c 4
ping www.baidu.com -c 4This command set is intended for final acceptance testing and is worth keeping as a reusable daily troubleshooting template.
Common residual issues can be handled by adding DNS or reactivating the device.
If the VM still has no IP after the repair, use nmcli again to disconnect and reconnect ens160. If a public IP works but domain names still fail, temporarily write to /etc/resolv.conf to verify whether DNS is the only remaining blocker. If mutual ping between the host and guest fails, check Windows Firewall inbound ICMP rules for VMnet8.
# Reactivate the NIC # Key point: trigger DHCP to request an address again
nmcli device disconnect ens160
nmcli device connect ens160
# Temporarily write DNS servers # Key point: quickly verify whether this is only a name resolution problem
echo "nameserver 223.5.5.5" > /etc/resolv.conf
echo "nameserver 8.8.8.8" >> /etc/resolv.confThese actions are better suited for corrective verification than for long-term configuration.
FAQ
Q1: Why can’t CentOS 9 access the internet even though it already has an IP address?
A: Getting an IP address only suggests that DHCP may be working. It does not guarantee that the default route, NAT forwarding, and DNS are all functioning correctly. Continue by checking ip route show, ping to the gateway, ping 223.5.5.5, and ping to a domain name.
Q2: Why fix the .nmconnection file first instead of editing /etc/resolv.conf directly?
A: /etc/resolv.conf is often overwritten by NetworkManager, so it is best used only for temporary verification. A stable fix should update the connection profile itself, especially ipv4.method, dns, and ignore-auto-routes.
Q3: Is disabling firewalld required?
A: No. You only need it as a verification step when a domain resolves but ping still fails, or when you suspect ICMP is being blocked. In production, keeping the firewall enabled and opening rules precisely is the better approach.
Core summary: This article restructures the standard troubleshooting workflow for common CentOS 9 network failures in VMware NAT mode. It focuses on four issue categories—IP acquisition, gateway reachability, DNS resolution, and firewall blocking—and provides reproducible diagnosis, repair, and verification steps for quickly restoring connectivity in virtual machine development environments.