The "Network Unreachable" error in VMware Workstation when running the Mercury VulnHub VM typically stems from NAT network configuration mismatches or host firewall interference. The most effective fix involves verifying that the virtual machine’s network adapter is set to NAT mode and ensuring the VMware NAT service is actively running on the host system.
Verifying Network Adapter Configuration
The first step in troubleshooting this connectivity issue is to inspect the virtual hardware settings within VMware Workstation. The Mercury VM, like many security-focused virtual machines, relies heavily on specific network protocols for its internal services. If the network adapter is incorrectly configured, the guest operating system cannot route traffic to the host or external networks.
Open the virtual machine settings by right-clicking the Mercury VM in the library and selecting Settings. Navigate to the Network Adapter section. Ensure that the option Connected and Start Connected are both checked. These checkboxes are critical because if the adapter is disconnected at startup, the VM will not attempt to initialize a network interface upon booting.
Next, examine the Network Connection dropdown menu. For most home lab environments, NAT: Used to share the host's IP address is the recommended setting. This mode allows the VM to share the host computer’s IP address, making it appear as another device on the local network. Avoid using Host-only unless you have specifically configured a static IP range for your host-only adapter, as default configurations often lack the necessary routing rules for general internet access or broader network discovery.
If you recently changed your host network (for example, switching from Wi-Fi to Ethernet), VMware may not have automatically updated the NAT configuration. In such cases, switching to Bridged mode temporarily can help isolate whether the issue is with the NAT engine or the physical network interface. However, Bridged mode requires that your router assigns an IP address to the VM via DHCP, which might not always be desirable for privacy reasons in penetration testing scenarios.
Checking VMware Services
VMware Workstation relies on background services to manage network translation and routing. If these services are stopped or corrupted, the VM will report network errors even if the virtual hardware is correctly configured. The primary service responsible for NAT functionality is the VMware NAT Service.
To verify this on Windows, press Win + R, type services.msc, and hit Enter. Locate VMware NAT Service in the list. Right-click it and select Properties. Check the Service Status; it should say Running. If it is stopped, click Start. Additionally, ensure the Startup Type is set to Automatic so that the service launches every time you start VMware Workstation.
On Linux hosts, you would use the terminal to check the status of the daemon. You can restart the VMware networking stack by running sudo systemctl restart vmware-networks.service. This command forces the host to reinitialize all virtual network interfaces, including the NAT gateway.
If the services are running but the problem persists, consider restarting them manually. Sometimes, a stale connection state can cause the NAT engine to hang. Stopping and then starting the service clears this state. Be aware that stopping these services will temporarily disconnect all running VMs, so save any work before proceeding.
Firewall and Host Interference
Your host operating system’s firewall may be blocking the virtual network adapters created by VMware. When VMware sets up a NAT network, it creates virtual adapters (such as VMnet8 on Windows) that must be allowed through the firewall. If a third-party antivirus or strict firewall policy blocks these adapters, the VM will lose connectivity.
Check your Windows Firewall or Linux iptables/nftables rules to ensure that inbound and outbound traffic is permitted for the VMware virtual adapters. You do not need to disable your entire firewall, but you should create an exception for the VMware application and its associated network components. Look for entries related to VMware Workstation or VMnet in your firewall logs if the connection fails unexpectedly.
Additionally, some corporate or university networks employ strict packet inspection that may interfere with the virtualized network traffic. If you are connecting to a public Wi-Fi, try switching to a wired connection or a different network segment to rule out external network restrictions.
Resetting Virtual Network Editor
If standard troubleshooting steps fail, resetting the virtual network configuration is a powerful diagnostic tool. Open VMware Workstation and go to Edit > Virtual Network Editor. You may need administrator privileges to make changes here. Click on Change Settings to gain write access.
Look for the Restore Defaults button at the bottom of the window. Clicking this will remove all custom virtual network configurations and recreate the default NAT and Host-only adapters. This process effectively wipes out any conflicting subnet masks or gateway settings that may have been introduced by previous experiments or software installations. After the reset, power on the Mercury VM and check if the network icon indicates a successful connection.
Note that restoring defaults will require you to reconfigure any custom port forwarding rules you may have set up previously. Also, ensure that the NAT checkbox is selected for VMnet8 after the reset, as this is the adapter used by the majority of VMs in NAT mode.
Related Resources
If you are experiencing broader issues with virtualization software beyond just network connectivity, you might find our guide on Error running virtual machine in VirtualBox helpful, as many underlying principles apply across different hypervisors.
Frequently Asked Questions
Why does my VM show no internet access even though the host has it?
This usually indicates that the NAT gateway is not functioning correctly on the host side. Check if the VMware NAT service is running and ensure that the VM’s network adapter is set to NAT mode rather than Host-only or Bridged.
Can I use Bridged mode instead of NAT for the Mercury VM?
Yes, Bridged mode allows the VM to appear as a separate device on your physical network. However, this exposes the VM directly to your LAN, which may pose security risks during penetration testing if not properly isolated.
What should I do if the Network Editor is grayed out?
You likely lack administrator privileges. Run VMware Workstation as an administrator or log in with an account that has administrative rights to modify system-level network configurations.
Does disabling IPv6 help with network unreachable errors?
In some cases, yes. If your host network prefers IPv6 but the VM only supports IPv4, or vice versa, conflicts can arise. Try disabling IPv6 on the host’s physical adapter or within the VM’s network settings to force IPv4 communication.
How do I know if the Mercury VM is successfully connected to the network?
Inside the VM, open a terminal and run ping 8.8.8.8. If you receive replies, the network stack is working. If you get "Destination Host Unreachable," the issue is likely with the local routing table or the virtual adapter configuration.