VirtualBox NAT vs Bridged Adapter Explained

VirtualBox gives every VM a network adapter, and the mode you pick for that adapter decides whether the VM can reach the internet, whether other machines can reach the VM, and whether your VMs can talk to each other. Pick the wrong one and you get the classic symptoms: a VM with no internet, or a server VM nothing else can connect to.

There are four modes that matter — NAT, NAT Network, Bridged, and Host-only — and they’re not interchangeable. NAT is the default and works almost anywhere, but it hides the VM. Bridged puts the VM on your real network with its own IP. The other two cover labs and multi-VM setups. Once you know what each one actually does, choosing is quick, and most “no internet” problems explain themselves.

The four modes, in one pass#

Here’s the short version before the detail:

That table answers most decisions on its own. The rest of this guide explains why each mode behaves that way and when to reach for it.

NAT: the default that just works#

With NAT, VirtualBox sits between the VM and the network. The VM is tucked behind the host’s IP address and shares the host’s connection, much like the way devices behind a home router share one public IP. The VM can reach out — browse the web, run updates, pull packages — but from the outside it’s invisible. Nothing on your LAN, not even the host’s other software by default, can open a connection to the VM.

That isolation is exactly why NAT is the default and why it’s the right pick most of the time:

• It works on any network without configuration — wired, Wi-Fi, hotel, corporate, captive portals. The VM borrows the host’s connectivity, so if the host is online, the VM is too.
• Each NAT VM lives in its own private network, which means two NAT VMs can’t talk to each other. That’s a feature for isolation, a limitation if you need VMs to communicate.
• The guest gets an address from VirtualBox’s built-in DHCP, typically in the 10.0.2.x range, with 10.0.2.2 as the gateway (the host).

For a single VM that only needs to reach the internet — a desktop you’re testing, a Windows 11 install in VirtualBox, a build environment — NAT is the path of least resistance.

Port forwarding: reaching into a NAT VM#

The downside of NAT is the flip side of its strength: because the VM is hidden, you can’t connect to a service running inside it from the host or anywhere else. Port forwarding is how you poke a single hole through. You map a port on the host to a port on the guest, and connections to that host port get forwarded inside.

In the GUI: Settings → Network → Adapter → Advanced → Port Forwarding, then add a rule. To reach SSH inside a Linux guest, for example:

With that rule, ssh -p 2222 user@localhost on the host reaches port 22 inside the VM. The same thing from the command line:

# Add a port-forward rule to a running or stopped VM's NAT adapter
VBoxManage modifyvm "MyVM" --natpf1 "ssh,tcp,,2222,,22"

# Remove it later by name
VBoxManage modifyvm "MyVM" --natpf1 delete "ssh"

NAT Network: when several VMs need to talk#

Plain NAT isolates each VM, which becomes a problem the moment you want two VMs to communicate — say an app server and its database, both running on your machine. NAT Network solves that. It’s a NAT-backed network you create once at the VirtualBox level, and every VM you attach to it shares the same subnet. Those VMs can reach each other and still get internet through the host.

You create the network first, then point VMs at it:

# Create a NAT Network with a chosen subnet and DHCP
VBoxManage natnetwork add --netname "LabNet" --network "10.10.0.0/24" --enable --dhcp on

# Attach a VM's first adapter to it
VBoxManage modifyvm "MyVM" --nic1 natnetwork --nat-network1 "LabNet"

So the rule of thumb: one VM that needs internet, use NAT. Several VMs that need internet and need to see each other, use NAT Network. Neither exposes the VMs to your physical LAN — for that you need Bridged.

Bridged: the VM joins your real network#

Bridged networking connects the VM straight to your physical network through the host’s adapter. The VM behaves like a separate physical machine plugged into the same switch: it gets its own IP from the same DHCP server as everything else on the LAN — your router, usually — and other devices can see and reach it directly.

This is why a bridged VM “gets a LAN IP” and a NAT VM doesn’t. In bridged mode the VM’s traffic goes out with the VM’s own MAC address onto the real network, so your router hands it a normal lease in the same range as your other devices (something like 192.168.1.x). There’s no host acting as a translator in front of it.

Reach for bridged when something else needs to connect to the VM:

• A server VM — a web server, a database, a file share — that other machines on the network use.
• A VM you want to SSH or RDP into from another device without setting up port forwards.
• Any case where the VM should behave like a real host on the LAN.

Host-only: an isolated lab network#

Host-only creates a private network shared by the host and the VMs attached to it, with no route to the internet. VMs on the same host-only network can talk to each other and to the host, and nothing leaves that bubble. It’s the right choice for an isolated test lab — a domain controller and a client, a cluster you’re experimenting with — where you specifically don’t want the VMs touching the real network or the internet.

If those lab VMs also need internet (to grab updates, for instance), the common pattern is to give each VM two adapters: a host-only adapter for VM-to-VM traffic and a NAT adapter for outbound internet. VirtualBox supports up to four adapters per VM, so mixing modes like this is normal and well supported.

Fixing a VM with no internet#

When a VirtualBox VM can’t reach the internet, the mode is the first thing to check, because each mode fails differently:

• NAT VM, no internet: Confirm the adapter is actually attached and Cable Connected is ticked (Settings → Network → Advanced). If the host itself is online but the VM isn’t, try toggling the cable or resetting the adapter. NAT relies entirely on the host’s connection — if the host is offline, so is the VM.
• Bridged VM, no IP: Check that the bridge is bound to the correct physical adapter — the one that’s actually connected. Picking a disconnected NIC, or a virtual adapter left behind by another hypervisor, leaves the VM with no DHCP. On Wi-Fi, see the warning above; bridging is often blocked.
• Host-only VM, no internet: That’s expected — host-only has no internet path. Add a NAT adapter if the VM needs to reach out.
• Has an IP but can’t browse: That’s DNS, not the adapter. The VM has a route but can’t resolve names. Set a working DNS server inside the guest and flush the resolver cache.

# Quick split inside a Linux guest: routing vs DNS
ping -c 3 8.8.8.8       # works? routing is fine
ping -c 3 example.com   # fails after the above works = DNS problem

Which one should you use?#

The decision is usually a single question — what needs to reach the VM?

For most people running a desktop VM or following along with a Windows 11 install in VirtualBox, NAT is the easy and correct default. You only need Bridged when the VM has to act like a real machine on the network, and you only need Host-only when you want VMs sealed off together.

Wrapping up#

VirtualBox networking looks like a long dropdown, but it’s really two questions: does the VM need to reach out, and does anything need to reach in? NAT covers outbound-only and works anywhere. NAT Network adds VM-to-VM traffic. Bridged puts the VM on your LAN with its own IP so others can connect to it. Host-only seals a group of VMs off for lab work.

When a VM has no internet, check the mode first, confirm the cable is connected and the right physical adapter is bridged, remember that Wi-Fi often blocks bridging, and treat “has an IP but can’t browse” as DNS. For more hands-on VirtualBox and hypervisor topics, see the virtualization guides.