21

I have Ubuntu guest OS in VirtualBox using default NAT for eth0.

Works fine at the office and at home EXCEPT when on office VPN from home.

When the host OS (Windows 7) is connected to the VPN, DNS lookups don't work within the Virtualbox guest. DNS lookups are fine on the host. Within Virtualbox, I can ping IPs directly both within the VPN and the outside, so it's not a connectivity problem.

It looks like the Ubuntu guest is using localhost as the DNS entry point, according to /etc/resolv.conf and nslookup. So it looks like something locally is then dispatching to other underlying DNS.

How do I troubleshoot this?

2
  • What are you using for VPN? Do you have access to the VPN settings on the device these machines are connecting to? Typically the machines connecting to the VPN draw their settings from the VPN device.
    – jmreicha
    Mar 25, 2013 at 15:24
  • To clarify the DNS lookups on the host are working fine - it's only the Virtualbox guest that is affected. Mar 25, 2013 at 18:18

3 Answers 3

22

This worked for some reason

C:\...\VirtualBox\VBoxManage modifyvm "VM name" --natdnshostresolver1 on

I suspect it's because when the VPN is active, the host is doing something special for DNS lookups besides just forwarding requests to the specified DNS servers that VirtualBox picked up from the Windows config.

2
2

TL;DR :

  • reboot the VM making sure the VPN status (either connected or disconnected) of the host doesn't change in the meantime;
  • let VirtualBox NAT engine intercept the DNS requests and forward them to the host's resolver, that is to use the host's DNS API to query the information and return it to the guest. You set this by:

VBoxManage modifyvm "VM name" --natdnshostresolver1 on


Running a VM in a host connected to a VPN can lead to DNS problems everytime the VPN status changes. There are two scenarios:

  1. the VM is spawn in a VPN-connected host and at a certain point the VPN disconnects;
  2. the VM is spawn in a non-VPN-connected host and at a certain point the VPN connects

1) VPN-connected --> VPN-disconnected

In this case the VM will probably have received a DNS address that is part of the VPN provider network. This will usually be an internal private IP address. Check the content of cat /etc/resolv.conf. In my case I get the following:

nameserver 10.8.8.1 <--- This is internal to the VPN Provider network

nameserver 192.168.178.1 <--- This is my home-gateway(router)

Now disconnect the host from the VPN connection:

  • the DNS configuration in the VMs doesn't change --> VM will still be sending DNS requests to destination IP 10.8.8.1 which cannot be reached as the host is no more connected to the VPN

In more details:

  • the packet will be sent to the def GW defined by the VirtualBox NAT network, source NATTed (with the host IP address), and finally handled by the host's routing table that will forward it to your home-gateway.
  • Here the packet will be dropped as your home gateway has no entry for 10.8.8.1 in the LAN side (private addresses) and cannot forward it on the WAN side (public addresses) as it a private address.

2) VPN-disconnected --> VPN-connected

In this case the VM won't receive the DNS address that is part of the VPN network provider as the host wasn't connected to the VPN when the VM started. Check the content of cat /etc/resolv.conf. In my case I get the following:

nameserver 192.168.178.1 <--- This is my home-gateway(router)

Now connect the host to the VPN connection:

  • the DNS configuration in the VMs doesn't change --> VM will still be sending DNS requests to destination IP 192.168.178.1 which cannot be reached (ping to it still works though) as now the DNS request from the VM is being handled by the VPN Tap interface that will forward the packets to the VPN network where 192.168.178.1 (your internal home-gateway IP address) cannot be reached.

In more details:

  • the packet will be sent to the def GW defined by the VirtualBox NAT network, sent to the VPN Tap interface that will modify the IP header replacing the VM IP source address with an IP address assigned to the host by the VPN Network, while the destination address remains the DNS address 192.168.178.1.
  • this packet is then going to be encapsulated in an outer IP Header that will have the host IP address as source (that btw will be later replaced by source NAT on the home-gateway) and the VPN Server as destination address.
  • when the packet reaches the VPN network, it is decapsulated. The destination IP address is now again the DNS address 192.168.178.1 that the VPN Provider Network has no way to reach (unless in the extraordinary conicidence where this is exactly the same IP address used by your VPN network provider for its DNS server).
1

I had a very similar situation with Lubuntu 16.04 (should be identical in other Ubuntus) but this fix did not improve the situation. At least with 16.04, the problem appears to be that NetworkManager uses a local DNS proxy (dnsmasq), and this doesn't play nice with VPN connections, at least in the default configuration.

Commenting/deleting dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile,ofono
# dns=dnsmasq

There is probably a way to configure dnsmasq but this gives (me) equivalent access to the host (dns, etc.), so I haven't investigated. YMMV.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .