re-initiate NAT on Network switch -> fixed in svn

[Kristofer Spinka]

This is a new issue that seems to have appeared in 2.2.0. On my MBP (MacBook Pro), if I switch from WiFi to the Gigabit Ethernet port (regardless of whether I put the laptop to sleep or not), the guest is unable to communicate with the network. It requires shutting down the VM and starting it again to recognize that a useable interface is actually available on the host. The guest is set to use NAT.

[Kristofer Spinka]

Update: it seems that the issue is that the virtual NAT interface and integrated DHCP server isn't notifying the guest about host interface transitions. So, the only *actual* problem is that the name servers are not being updated to use the new settings when transitioning from one DHCP realm to another.

Problem still exists in 2.2.2.

[vasily Levchenko]

Does guest somehow react on manual renewing the dhcp leasing ... e.g.

# ipconfig /release
# ipconfig /renew

[Kristofer Spinka]

The guest returns stale DNS information when attempting to manually refresh the lease.

[raccoonone]

I'm experiencing the same problem, and it happens when switching between different wireless networks as well as switching from wireless to wired.

[Johannes Kastl]

The same problem appears when "plugging in" a virtual network cable, if the VM is booted with the cable not "attached". The VM does not notice the cable now being plugged in.

[eythort]

I've got the same problem, win xp host, debian 4 guest. I'm not sure if it's related, but ever since 2.2.* I also need to manually edit the /etc/resolv.conf nameservers in the guest when at home. When the lease is refreshed (manually or not) when at home the nameservers always revert to the nameservers used at work, i.e. the DNS information is stale for some reason.

[vasily Levchenko]

Replying to eythort:

I've got the same problem, win xp host, debian 4 guest. I'm not sure if it's related, but ever since 2.2.* I also need to manually edit the /etc/resolv.conf nameservers in the guest when at home. When the lease is refreshed (manually or not) when at home the nameservers always revert to the nameservers used at work, i.e. the DNS information is stale for some reason.

Thank you eythort for additional information about revert order of DNS servers, probably it would be better to open separate ticket for this.

[headcase]

A temporary workaround to this bug, is to set your DNS manually to OpenDNS servers within your guest OS, which I do on my Macs anyhow, as OpenDNS is very responsive. ​http://www.opendns.com/

I also found that this bug is not limited to switching between Ethernet and WiFi -- the same bug appears when switching between wireless networks on the Mac Airport interface.

[Gabriele Vivinetto]

I confirm this Bug with VirtualBox 3.0.4 Host: Ubuntu 9.04 Guest: Windows XP Sp3

After suspending on one network, and resuming on another, the DNS parameter is not updated, neither doing

ipconfig /renew

neither

disconnencting the Lan device

I must reboot the virtual machine.

[Gabriele Vivinetto]

Same bug is present in 3.0.6, Linux Host, Windows Guest.

The Virtual Machine has to be shutted down to obtain the right DNS.

I've tried to enable DNS proxy too, but the behaviour is the same.

When I leave the VM running and I suspend my Host the Vbox Nat Service memorize the DNS. When I resume the Host, the guest is running fine, but it does not change the DNS taken by the Vbox Internal DHCP Server to the correct one. Please help me to debug this error.

Thanks, Gabriele

[LarsV33]

I have the same problems with 3.0.8!

I just confirmed that the DHCP-Server of VirtualBox sends the client the wrong DNS-Server after the network of the host (Mac OS X 1.6) changes. So basically the DHCP needs to update the DNS-Server when ever the host changes the network and make the client update the settings (network down, up?). A simple solution would be having a local VirtualBox DNS-Proxy. Is this possible?

Btw, it does not help to reboot the Windows Guest, since the DHCP does still not announce the correct DNS-Server afterwards. Only completely restarting Virtual Box does help!

[Frank Mehnert]

Actually a local DNS proxy is already available, see user manual section 9.12.5.

[LarsV33]

Hi!

Have tried the NAT DNS-Proxy Setting... but it does not help:

VBoxManage setextradata "Windows" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/DNSProxy" 1

It seems that the DNS-Proxy does not figure out that I change from wired to wireless. Therefore, it tries to contact the wrong DNS-Server. So, while the NAT-Proxy is able to hide possible changes, it is not able to detect them and/or react on them. :(

[vasily Levchenko]

Therefore, it tries to contact the wrong DNS-Server. So, while the NAT-Proxy is able to hide possible changes, it is not able to detect them and/or react on them. :(

Right DNS proxy was introduced only for compatibility with >2.2, where DNS server was 10.0.2.3 and was mapped to the first entry of resolve.conf and DNS proxy just maps 10.0.2.3 to all servers in the list. In 3.1 we'll have proxy working with not DNS server list but with host's resolver API, that will solve the issue.

[vasily Levchenko]

please check with 3.1

VBoxManage setextradata "Windows" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/UseHostResolver" 1

[Gabriele Vivinetto]

Replying to Hachiman:

please check with 3.1

VBoxManage setextradata "Windows" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/UseHostResolver" 1

I confirm that with Ubuntu 9.10 and vbox 3.1, setting this property, the resolver is working correctly after switching subnet and network media.

[vasily Levchenko]

Replying to GabrieleV:

I confirm that with Ubuntu 9.10 and vbox 3.1, setting this property, the resolver is working correctly after switching subnet and network media.

Thanks for feedback.

[vasily Levchenko]

Will close it for now. Please fill free to open if host resolver proxy doesn't work in the way it should.

[Tom Davidson]

In 3.1.8, if you are using a default NAT network configuration, Vbox still serves up stale DNS data, as originally reported by kspinka. Renewing the DHCP lease doesn't help, and neither does 'unplugging' and 'replugging' the virtual network cable.

The 'UseHostResolver' option does seem to solve this (requires a restart of Vbox for the option to get picked up), but this is a workaround, not a fix for what seems like a valid bug.

(Ubuntu 9.10 host running VBox 3.1.8, WinXP Guest)

[Tom Davidson]

This bug breaks networking for the default guest setup in a very common situation (moving the host machine from one network to another).

Issues 2701, 4274, 4484, 4533, 4544, and 4680 were all marked duplicates of this bug. In addition, issues 2654, 5085, 6081, and 6670 all also appear to be duplicates (these last 3 are still open).

The first reports (2654 and 2701) came with version 2.0.6 in November 2008, and have continued up to the current release (3.1.8). Bug 6081 has some useful discussion about possible solutions to this problem.

Vbox's DHCP server should be fixed so that it no longer serves up stale DNS info to guests (i.e. Vbox should refresh its DNS listings before responding to a DHCPRENEW, as suggested in issue 6081). Also, perhaps the UseHostResolver option should be on by default? This way, the user wouldn't even have to issue a DHCP renew.

[vasily Levchenko]

Replying to tjd2002:

Vbox's DHCP server should be fixed so that it no longer serves up stale DNS info to guests (i.e. Vbox should refresh its DNS listings before responding to a DHCPRENEW, as suggested in issue 6081).

The problem here is existence of several dhcp clients which renew of configuration in own way. before 3.1 we've fully re-implemented built-in DHCP server, making it compatible with the latest rfc2131/2132. We are also investigating possibility to automatic testing DHCP and other supported built-in services and protocols.

Also, perhaps the UseHostResolver option should be on by default?

Indeed UseHostResolver is good candidate to be default option, but this option has some side effects, e.g. gethostbyname(3) does not provide full information to compose valid DNS response that why alias_dns fills required fields with values computed in terms of common sense :) , speed of it's respons is less than just send/receive UDP request. But it ofc solution for mobile users and DNS less environment.

This way, the user wouldn't even have to issue a DHCP renew.

[Tom Davidson]

The problem here is existence of several dhcp clients which renew of configuration in own way.

I am not familiar with the code, so I don't understand why this is a problem. Vbox's DHCP server must know when it is being asked for a new lease. When it gets such a request, can't it just check the host's resolv.conf at that time (or whatever platform-specific mechanism it uses to get DNS info initially), instead of serving up stale cached DNS data?

[vasily Levchenko]

Replying to tjd2002:

The problem here is existence of several dhcp clients which renew of configuration in own way.

I am not familiar with the code, so I don't understand why this is a problem.

The problem is not to break the behavior of current guests and serve several dhcp clients which do renewal in own way. There're several ways dhcp client can renew configuration which could be combined (by client) that might lead to several reading of DNS (on Unix) or available adapters' information (on Windows) in rather short period of time.

Vbox's DHCP server must know when it is being asked for a new lease. When it gets such a request, can't it just check the host's resolv.conf at that time (or whatever platform-specific mechanism it uses to get DNS info initially), instead of serving up stale cached DNS data?

BTW re-connecting adapter via VBox GUI or VBoxManage leads to re-init NAT engine.

[Tom Davidson]

The problem is not to break the behavior of current guests and serve several dhcp clients which do renewal in own way.

Can you specify what guest behaviors would break if VBox looked up correct DNS values on each DHCP renew? How it is advantageous to serve cached (possibly wrong) DNS data?

There're several ways dhcp client can renew configuration which could be combined (by client) that might lead to several reading of DNS (on Unix) or available adapters' information (on Windows) in rather short period of time.

So is the concern that there is a performance hit for checking the host DNS settings everytime a renew request comes in? If so, then perhaps host's DNS data could be cached less aggressively by Vbox (like for a few seconds instead of permanently).

BTW re-connecting adapter via VBox GUI or VBoxManage leads to re-init NAT engine.

Nice, this works for me and is an even more user-friendly workaround. After switching the adapter from 'NAT' to 'Not Attached', and then back to 'NAT', then DHCP renewals on the guest do pick up the new DNS entries. As you note this can also be done from the command line with:

VBoxManage controlvm "GUESTNAME" nic1 null
VBoxManage controlvm "GUESTNAME" nic1 nat

[vasily Levchenko]

Replying to tjd2002:

The problem is not to break the behavior of current guests and serve several dhcp clients which do renewal in own way.

Can you specify what guest behaviors would break if VBox looked up correct DNS values on each DHCP renew?

Again rfc2131 doesn't specify DHCPRENEW operation, instead it specify several commands and arguments sets which may lead to update of client information, e.g. dhclient and dhcpcd have got rather different behavior. Doing dynamical updating internal DNS cache means that some of the sequences (commands + attributes) might be lost or doing it straight-forward might prolong dhcp commands processing what could lead to other side effects. please note that some dhcp clients do not strictly follow the rfc1531 or rfc2131. That mean that we need use some flexible/extensible test suite for DHCP-server, while main targets of NAT engine is TCP/IP, UDP/IP and NAT itself where we need even more strict testsuites (because most changes/improvements are done in these areas) which are not existing or not very functional/usable. Of course I'm looking at opportunities to make built-in dhcp server more dynamic and trying to feel the gaps in the testing by developing test suites, but again the main focus is TCP/IP and NAT where also test suites are required.

How it is advantageous to serve cached (possibly wrong) DNS data?

Initialization DNS cache on startup prevents any dhcp clients abnormals or particularities, and keeps the most clients usable.

Nice, this works for me and is an even more user-friendly workaround.

This happens because NAT engine is fully re-init.

[Tom Davidson]

OK, I see how things get complicated very quickly for VirtualBox; thanks for explaining this. Perhaps it would be helpful to look at how other 'real' DHCP servers handle changes in upstream DNS information, since this must happen occasionally.

Nice, this works for me and is an even more user-friendly workaround.

This happens because NAT engine is fully re-init.

Until the DNS updating bug gets fixed, perhaps the NAT engine could be re-initialized more often. For instance, in most bug reports (including mine), users report trying to disconnect and reconnect their (guest) network adapter, either using the guest OS's utilities, or using the virtual 'network cable'. If the NAT engine were reset when this happens, then I think that would go a long way to reducing user frustration.

[vasily Levchenko]

Replying to tjd2002:

OK, I see how things get complicated very quickly for VirtualBox; thanks for explaining this. Perhaps it would be helpful to look at how other 'real' DHCP servers handle changes in upstream DNS information, since this must happen occasionally.

'real' DHCP servers are programmed to inform clients with DNS information stored in config, they're not surprised with occasional change of DNS server list :). If talk about other virtualizators they have Slirp solution (like vbox before 2.0). But your question give me additional hint for this problem.

[vasily Levchenko]

Replying to tjd2002: As I said you give me a hint how to solve the issue, but as I said we don't have good test-coverage for DHCP server. So I need volontiers to test the fix. Here are prerelease 3.2 bits to test:
​VirtualBox-2010-05-17-05-48-33-mac2-rel-3.2.0-r61642.dmg
​VirtualBox-2010-05-17-05-32-21-lin32-rel-3.2.0_BETA3-r61642.run
​VirtualBox-2010-05-17-05-39-48-lin64-rel-3.2.0_BETA3-r61642.run
​VirtualBox-2010-05-17-05-37-45-win-rel-3.2.0_BETA3-r61642-MultiArch.exe

[Tom Davidson]

Replying to Hachiman:

Replying to tjd2002: As I said you give me a hint how to solve the issue, but as I said we don't have good test-coverage for DHCP server. So I need volontiers to test the fix.

Hachiman, this works great here! (testing the lin32 version on Ubuntu 9.10). My test is logging into a work VPN on the host that provides name servers that are not accessible from outside the VPN. When I log off the VPN, then those name servers are no longer visible. Before your fix, then I would lose name resolution in the guest, as reported above, and wouldn't be able to get the new list of servers from the host with a DHCP renew.

With UseHostResolver turned off, then the guest gets the host's current list of name servers via DHCP upon initial startup. When I log out of the VPN on the host (thus changing the list of name servers in /etc/resolv.conf), then as expected name resolution breaks in the guest, since the old name servers are no longer reachable. However, I can now pull down the new list of name servers by renewing the DHCP lease (either by running "ipconfig /renew" at the Windows guest command line, or by unplugging/replugging the virtual network cable in the VBox network connection dialog).

I also tested with UseHostResolver turned on, to make sure this solution still worked. As expected, my WinXP guest is assigned a 10.0.2.X address, and a 10.0.2.3 DNS server entry. When the host DNS info changes, the guest can still resolve names. For me, this solution works best, and I will stick with it.

Thanks so much for the quick turnaround on a fix for this! Let me know if there is any more testing I can do that would be useful

[vasily Levchenko]

Replying to tjd2002:

... Thanks so much for the quick turnaround on a fix for this! Let me know if there is any more testing I can do that would be useful

Thanks for feedback.

[Frank Mehnert]

Note that this change will not be included in the upcoming 3.2.0 release. The target is VBox 3.2.2.

[Bharath Kumar]

Hi,

I have installed VBox4.1.0 on XPdesktop as host machine.

I have enabled DHCP server by: enable DHCP in the File > Preferences -> Network > "Virtual Host-Only Ethernet Adapter" > Edit > DHCP Server > Check "Enable Server".

created a REDHAT vm and started the vm. The vm network settings is in NAT mode.

I am NOT able to connect /ping from/to the host os(XP) from the guest os (redhat). please let me know what is the network settings I should use?

I am reopening the case, just to be sure.

Thanks Bharath

[vasily Levchenko]

Replying to bkumarm:

Hi,

I have installed VBox4.1.0 on XPdesktop as host machine.

I have enabled DHCP server by: enable DHCP in the File > Preferences -> Network > "Virtual Host-Only Ethernet Adapter" > Edit > DHCP Server > Check "Enable Server".

created a REDHAT vm and started the vm. The vm network settings is in NAT mode.

I am NOT able to connect /ping from/to the host os(XP) from the guest os (redhat). please let me know what is the network settings I should use?

I am reopening the case, just to be sure.

Thanks Bharath

I'm sorry but I don't see any clue between your question (preferable use forum) and description of the bug. So I have to close it.

[Bharath Kumar]

Hi,

adding clarification:

1. I have installed VirtualBox on XP host downloaded from : ​http://www.virtualbox.org/wiki/Downloads

2. I have configured the network settings:

File > Preferences -> Network > "Virtual Host-Only Ethernet Adapter" > Edit > DHCP Server > Check "Enable Server".

3. created a new virtual machine, with redhat os.
4. after os is installed, started the vm and logged in.
5. I tried to ping from host os to guest os , but it is failing.

The issue same as the one originally reported.

Thanks, Bharath

[vasily Levchenko]

Replying to bkumarm:

Hi,

adding clarification:

1. I have installed VirtualBox on XP host downloaded from : ​http://www.virtualbox.org/wiki/Downloads

2. I have configured the network settings:

File > Preferences -> Network > "Virtual Host-Only Ethernet Adapter" > Edit > DHCP Server > Check "Enable Server".

3. created a new virtual machine, with redhat os.
4. after os is installed, started the vm and logged in.
5. I tried to ping from host os to guest os , but it is failing.

The issue same as the one originally reported.

Thanks, Bharath

Initial report was about impossibility of restoring networking after switching network (e.g. wifi -> ethernet or corporate to home one) without rebooting the guest.