VirtualBox NAT guest DNS breaks after the host joins a VPN

On a Windows host the internal application name resolves once the VPN connects, and inside an Ubuntu guest it does not. The guest keeps its own resolver settings, and the NAT adapter in front of it can answer DNS queries in two different ways. Pointing the guest at a public resolver makes websites load again while private names stay broken. That is why the resolver path gets traced before anything is edited.

Trace one lookup through the NAT adapter

Pick one internal fully qualified name and one public name to use as a control. With the tunnel up, confirm on the host that the internal name resolves and the application behind it opens. Then run the same two lookups inside the guest and compare the answers rather than the tools.

Confirm the adapter really is plain NAT before going further. A bridged adapter, a named NAT Network and a second VPN client inside the guest each have their own configuration and their own explanation. Guessing at this point wastes the rest of the investigation.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

The first command shows the adapter mode and any NAT network attached to it. Inside an Ubuntu guest the second lists per-link DNS settings, and the third often reveals only a local stub address, which means the real upstream sits somewhere else.

Keep resolution and reachability apart. A guest that receives the correct address but cannot open a connection has a routing, filtering or service-permission problem, and further DNS changes will never touch it. Test the address separately and write down which of the two failed.

Proxy mode and host resolver mode are different mechanisms

In proxy mode the NAT engine forwards guest queries to DNS servers it already knows about. In host resolver mode it intercepts the query and asks the host operating system to resolve the name with whatever the host is using right now. Only the second follows a VPN client that rewrites host resolution when the tunnel comes up. That is why the two settings produce different answers on the same machine.

That distinction is the whole problem in one sentence. Handing the guest a list of server addresses is not the same as asking Windows to resolve a name through its configured resolver, and on a split-DNS VPN the two answers differ. The adapter option is about mechanism, not about permission.

Neither mode grants access to anything. Authorization lives in the VPN policy and in the service, and a working lookup only means a name turned into an address.

Switch the adapter, then verify what the guest receives

Record the VM network and DNS settings first, then shut the machine down so the persistent configuration is what you edit. For a VM named work-ubuntu whose first adapter carries NAT, the per-adapter option is set from the host while the VM is off. Start it again afterwards and inspect the result rather than trusting the exit status.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

The trailing digit selects the adapter number, so it is not a universal value; an adapter 2 setting would carry a 2 in that position. Use the VBoxManage binary that belongs to the installed VirtualBox version, because an older one on the path can write settings the running version ignores.

Enabling the proxy option instead selects a different mechanism and does not give you host resolver behaviour. After the guest starts, check the DNS configuration it actually holds, since a pinned resolver or an encrypted-DNS setting inside the guest keeps applications on another path regardless of what the adapter offers.

Test across the VPN lifecycle, not just once

Repeat both lookups in the guest, then open the real application and let it validate the TLS hostname. An IP-only connection test isolates DNS nicely, but it is not a certificate check and should not be reported as one. Record the name, the address and the application result together.

During an approved window, disconnect and reconnect the host VPN and repeat the test. The outcome should match the access policy, and public resolution working again says nothing about whether private queries stayed on the intended path.

When host resolver mode changes nothing, put the recorded value back and keep the observations. A VPN client that excludes hypervisor traffic, an unreachable internal resolver and a pinned guest setting each need a different correction, and bridging the adapter changes the network design rather than resetting DNS.