# VMware Network Adapters Explained: NAT, Host‑Only, and Bridged Modes

## Introduction

I recently ran into a problem while I was working on a home lab that I thought was worth sharing. I wanted to run a virtual machine, but my main PC didn’t have enough free storage space, so I decided to install VMware on a different machine on the same local network and set up a Windows 11 Pro virtual machine there.

My plan was to enable Remote Desktop inside the guest OS so I could RDP into the VM from my main computer instead of using the second machine directly. When I attempted to connect using RDP, the connection kept failing. I checked the usual settings: Remote Desktop was turned on in the guest OS, the firewall allowed RDP traffic, and the VM was running with a valid IP address. Since everything inside the guest OS appeared correct, the issue had to lie in the network path between my main PC and the VM.

That led me to research the issue, and I learned about VMware’s network adapter modes: NAT, Host-Only, and Bridged. The VM was using the default NAT adapter. This meant that the VM could reach the internet, but it lived in a private network, so my main computer couldn’t initiate a connection with it. Switching the adapter to Bridged mode fixed the problem immediately.

The diagrams below show how each network mode works, along with explanations as to why the network mode choice matters more than it first appears.

## How VMware connects a VM to a network

A VM's network adapter is a software device, but VMware presents it to the guest OS like a physical NIC. That virtual adapter still needs to connect to a network on the host, and VMware does this with virtual switches.

In a typical VMware Workstation install, three virtual networks are created automatically:

![](https://cdn.hashnode.com/uploads/covers/6767e8fe0ddd601305c860a0/e26c55f9-2af9-4fb9-8218-252b6cb56477.png align="center")

*   **VMnet0** - used for Bridged mode
    
*   **VMnet1** - used for Host-Only mode
    
*   **VMnet8** - used for NAT mode
    

Your VM connects to one of these virtual switches (or a custom network you create). The network mode choice decides which systems the VM can talk to and whether the VM behaves like another device on your LAN or stays isolated behind the host.

## NAT: internet access through the host

![](https://cdn.hashnode.com/uploads/covers/6767e8fe0ddd601305c860a0/ee8ae6aa-ff14-4c48-873d-e08447723ccf.png align="center")

NAT is the default for new VMs. It's a good fit when the guest needs outbound internet access but doesn't need to be directly reachable from other devices on your physical network.

In NAT mode, VMware connects the VM to a private virtual switch, usually **VMnet8**. In my setup, the physical home network is `192.168.1.0/24` and the host has `192.168.1.10`. VMware creates a separate subnet for the NAT network, `192.168.150.0/24`, and hands out addresses in that range via a virtual DHCP server. A virtual NAT device sits between the VM network and the host's physical connection.

When the VM sends traffic to the internet, the NAT device rewrites the source address so the traffic looks like it's coming from the host. It's the same idea as a home router letting multiple devices share one public IP. This allows the guest OS to have internet access with almost no configuration.

The catch is that devices on your physical LAN can't normally initiate connections to the VM. The VM's `192.168.150.x` address lives on VMware's private network and isn't routed across your LAN. So another computer on `192.168.1.0/24` can't just RDP to that address. That's exactly why my Remote Desktop attempt from the main PC failed.

## Host-Only: private communication with the host

![](https://cdn.hashnode.com/uploads/covers/6767e8fe0ddd601305c860a0/1e4c2684-a25a-41a1-9699-351c85e48247.png align="center")

Host-Only mode also uses a private virtual network, but without a NAT path to the physical network or the internet. VMware creates a virtual switch, typically **VMnet1**, with its own subnet. In the diagram this is `192.168.100.0/24`. The host gets a virtual adapter on the same network, `192.168.100.1`, so the host and its VMs can talk directly.

This network mode is useful when VMs need to communicate with the host, or with other VMs on the same Host-Only network, while staying isolated from the physical LAN. It can be used for test environments, security labs, or any scenario where you want to block internet access on purpose.

Host-Only wouldn't have solved my RDP problem. It would have let the VM talk to the machine running VMware, but not to my separate main computer. Since my main PC was another device on the physical LAN, it still wouldn't have had a route into the Host-Only subnet.

A VM with only a Host-Only adapter can't reach the internet, because that network has no route to your physical router or beyond. If you also need internet access, you can add a second virtual network adapter in NAT mode.

![](https://cdn.hashnode.com/uploads/covers/6767e8fe0ddd601305c860a0/f41aacec-f338-4608-93b2-7742a5c602a4.png align="center")

The Host-Only adapter handles isolated host‑to‑VM traffic, while the NAT adapter provides outbound internet through the host's physical connection. VMware supports multiple virtual NICs per VM, so this is a common setup for labs and testing.

## Bridged: direct access to the local network

![](https://cdn.hashnode.com/uploads/covers/6767e8fe0ddd601305c860a0/718f887c-4ad2-4696-9193-3f77dcc78fd3.png align="center")

Bridged mode was the right choice for my situation. Instead of creating a separate private subnet, VMware uses **VMnet0** to bridge the VM's virtual adapter to the host's physical network adapter. The VM then talks directly to the same router the host uses.

In the example shown, the VM asks the router's DHCP server for an IP address and gets one on the `192.168.1.0/24` network. It now sits on the LAN alongside the host and other devices. The VM has its own MAC address and IP address, and other machines treat it like any other physical device.

That’s why Remote Desktop worked once I switched to Bridged mode. My main computer could open an RDP session straight to the VM's LAN address, just as it would connect to any other machine on the same network.

## Comparison of the three network modes

| Feature | NAT (VMnet8) | Host-Only (VMnet1) | Bridged (VMnet0) |
| --- | --- | --- | --- |
| VM can access the internet | Yes | No, unless a second NAT adapter is added | Yes |
| VMware host can reach the VM | Yes | Yes | Yes |
| Other LAN devices can reach the VM directly | No, not by default | No | Yes |
| VM receives an address from the physical router's DHCP service | No | No | Yes |
| VM is directly visible on the physical network | No | No | Yes |

## Resolving the RDP issue

Once the network modes made sense, fixing the issue was straightforward. I opened the VM's network settings and switched the adapter from NAT to Bridged. The VM picked up a new IP address from the router's DHCP pool and became visible to the rest of the local network. After entering that new IP address into Remote Desktop on my main PC, the connection was successful.

Nothing was broken in VMware or Remote Desktop. NAT was doing exactly what it's supposed to do: provide outbound connectivity while keeping the guest OS on a separate private network. The issue was my use case. I needed another device on the LAN to initiate a connection to the VM, and Bridged mode was the right choice because it made the VM directly reachable as a device on the same physical network.

## Conclusion

It is important to choose the right network mode for your use case. Here is a brief description of when to use which network mode:

*   **Use NAT** when the VM mainly needs internet access (updates, browsing, downloads) and no other device needs to connect to it directly.
    
*   **Use Host-Only** when you want an isolated environment where communication is limited to the VMware host and other VMs on the same private network. Add a second NAT adapter if the VM also needs internet access.
    
*   **Use Bridged** when other devices on the physical LAN need to access the VM directly. Think Remote Desktop, hosting a service, or testing a machine that should behave like an independent device on the network.