VirtualBox Guest DNS Breaks After the Host Joins a VPN

An internal application resolves on the Windows host the moment the VPN connects, and the Ubuntu guest behind VirtualBox NAT still cannot find it. The guest has its own resolver, and the NAT adapter can handle DNS in more than one way. Replacing the guest's resolver with a public server makes ordinary websites work and private names fail, which redirects the problem instead of solving it. Work the four checks in order and stop at the first one that does not hold.

Confirm Which Adapter Mode You Are Debugging

Only an adapter in plain NAT mode behaves the way this article describes. A bridged adapter sits on the physical network with its own identity, a NAT network is a named virtual switch with its own DHCP and DNS settings, and a VPN client inside the guest adds a second resolver entirely. Confirm the mode before reading on, because the repair differs in every one of those cases.

One VM can carry two adapters in different modes, and the affected one is not always the first.

Also confirm that the host resolves the name at all. Open the same application on the host with the tunnel up, using the same fully qualified name the guest will use. If the host fails too, the guest is not the fault and no virtual networking change will repair it.

Follow One Name Through the Guest Resolver

Choose one internal name and one public control name, then test both in both places. A public name that resolves while the private one does not localizes the fault to the private path rather than to name resolution in general. Testing the private name alone leaves you unable to distinguish a broken resolver from a broken route.

Inside the guest, look at what the resolver is actually configured to use. On an Ubuntu guest running systemd-resolved, the per-link status shows the servers that arrived, and the resolv.conf file may contain nothing but a stub address, which is correct rather than suspicious. A hand-edited file or a separate encrypted-DNS client can send lookups somewhere else entirely. Write down what you find before changing it.

resolvectl status
resolvectl query app.internal.example

Separate resolution from reachability here. An address that arrives while the service stays unreachable is a routing or policy question, not a DNS one.

Try Host Resolver Mode on That Adapter

VirtualBox's NAT DNS options describe different mechanisms, and the difference matters once the host's own resolver changes with the tunnel. The DNS proxy forwards guest requests to servers it was handed. Host resolver mode intercepts the requests and calls the host's DNS API, which is the mode that follows a Windows resolver reconfigured by a VPN client.

Enable the wrong mechanism and the command still succeeds while the behaviour does not change, which is a confusing way to lose an afternoon.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Record the VM's current settings, shut it down, and target the adapter you confirmed earlier. The trailing digit in the option is an adapter number rather than a constant, so applying it to a VM whose affected adapter is second is a silent no-op. Start the guest and check the resolver configuration it actually received, because a manual guest setting overrides whatever the NAT layer offers. Remember that host resolver mode also assumes the host's own DNS path is the one you meant to share.

Re-run the Same Tests Across a VPN Reconnect

Repeat both lookups in the guest, then open the real application and let it validate the certificate itself. An address-only test is useful for isolating name resolution and is not equivalent to a working TLS session, so do not stop at a ping. Then, in an approved window, disconnect and reconnect the host tunnel and repeat once more. Behaviour that holds only on the first connection after boot is a lifecycle problem to report, not a DNS mystery to chase with a different resolver.

Public resolution working does not prove that private queries stayed on the path your policy requires.

When host resolver mode changes nothing, put the recorded configuration back and keep the four observations: what the host returned, what the guest returned, the adapter mode and the resolver state. An unreachable internal server, a filter that excludes hypervisor traffic and a guest-side override each need a different correction. Converting the adapter to a bridge changes the network design and is not a DNS reset.