VirtualBox NAT or Bridged: Where the VM's VPN Ends

Two different questions arrive together whenever a virtual machine runs a VPN client, and they have different answers. The first is whether a tunnel inside the guest protects the host, and the second is whether a tunnel on the host covers the guest. Adapter mode decides both, more than the VPN software does. A NAT adapter makes the host the visible endpoint, while a bridged adapter puts the guest on the wire with its own address.

Who actually terminates the encrypted session

An encrypted session belongs to the machine that terminates it, which is the guest when the client runs inside the VM. Only traffic entering the guest's virtual adapter passes through that tunnel, and the hypervisor never routes another machine through the guest on its own. That is why the guest can hold a working tunnel while the host browses in the clear. The reverse is not symmetric, and the asymmetry is the part most guides get wrong.

Whose address the outside network sees is the question the adapter mode answers. Once that is settled, coverage stops being a policy question and becomes a mechanical one. Everything below follows from those two facts.

NAT rewrites the guest until it looks like the host

With NAT, the hypervisor rewrites every guest packet to the host's address before it reaches the first switch. That traffic is then handed to the host's own network stack, where it follows the host's routing table, including a default route owned by a tunnel on the host. A NAT guest is therefore covered by a host tunnel without any configuration at all, which is the opposite of what the guest-to-host case suggests.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

A guest that runs its own client terminates that tunnel inside the guest, and the encrypted traffic then leaves through the same rewrite, so host applications keep their own path and their own exit address. VirtualBox also owns name resolution in this mode, relaying guest queries through its own engine unless --natdnshostresolver1 is enabled. Enabling it hands the guest's lookups to the host's resolver, which fixes resolution whenever the host's own view is right and equally hands over a resolver that may exist only inside a tunnel. The VM has to be powered off before the setting changes, and the setting belongs to the adapter rather than to the guest's software.

Bridging gives the guest its own lease and its own exposure

Bridging passes the guest's frames onto the physical segment, so DHCP hands it a lease and the network treats it as a separate host. Each bridged guest can hold an independent tunnel with its own default route, and the host's table never changes. The trade is exposure: the guest answers broadcasts, appears in neighbour tables, and becomes subject to switch port security and wireless client isolation. A host tunnel does not cover this arrangement either, because guest frames never pass through the host stack.

That difference from the NAT case is worth stating plainly rather than leaving as an implication. A bridged guest needs its own client and its own credentials whenever its traffic has to use a tunnel. Where the guest must stay invisible to the local network, NAT or an internal-only network with controlled routing is the better design.

Why the guest cannot be the host's gateway

Lending a guest's tunnel to the host has no supported switch in either major hypervisor. The host has no route into the guest's tunnel and no translation rule pointing at it, so guest and host traffic remain separate flows with separate owners. That direction fails regardless of adapter mode.

The workable substitutes are forwards and proxies. An SSH local forward lets the host connect to its own loopback while the guest carries the stream into the tunnel, which covers TCP services without installing a second client. Making the host's own IP traffic use the guest's tunnel instead needs a router inside the guest plus an explicit host route and translation on the host. That is a small network design rather than a checkbox, and it needs a plan for the return path. When the guest exists purely to run the client, put the client on the host and delete the extra hop.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Resolvers and routes do not cross the boundary

DNS follows the adapter that received the option, so a guest does not inherit the host's tunnel resolver and a host never learns the guest's pushed server. Pushed dhcp-option DNS values apply to the interface that accepted them, which is why a bridged guest with no client cannot resolve internal names. A NAT guest normally uses the hypervisor's DNS handling instead, and the difference shows up in one command per environment.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Read the resolver and the route inside the guest before assuming either one follows the host. Add the tunnel resolver to the guest's own adapter when internal names have to resolve there, then verify with a name that exists only behind the tunnel. Record the adapter mode, the tunnel owner and the resolver source for each VM, because those three facts answer nearly every later question. Other hypervisors rename the modes and leave the principle intact.