VirtualBox

Opened 15 years ago

Closed 13 years ago

Last modified 13 years ago

#3847 closed defect (fixed)

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

Reported by: Kristofer Spinka Owned by:
Component: network/NAT Version: VirtualBox 3.0.8
Keywords: switch interface nat laptop lan Cc:
Guest type: Windows Host type: Mac OS X

Description

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.

Change History (40)

comment:1 by Kristofer Spinka, 15 years ago

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.

comment:2 by vasily Levchenko, 15 years ago

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

# ipconfig /release
# ipconfig /renew

comment:3 by vasily Levchenko, 15 years ago

Component: networknetwork/NAT

comment:4 by Kristofer Spinka, 15 years ago

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

comment:5 by raccoonone, 15 years ago

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

comment:6 by Johannes Kastl, 15 years ago

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.

comment:7 by eythort, 15 years ago

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.

in reply to:  7 comment:8 by vasily Levchenko, 15 years ago

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.

comment:9 by vasily Levchenko, 15 years ago

Summary: When switching host interfaces (i.e. transition from WiFi to hardwire) guest requires stop and startre-initiate NAT on Network switch

comment:10 by headcase, 15 years ago

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.

comment:11 by Gabriele Vivinetto, 15 years ago

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.

comment:12 by Gabriele Vivinetto, 15 years ago

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

comment:13 by LarsV33, 14 years ago

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!

comment:14 by Frank Mehnert, 14 years ago

Keywords: wifi wireless gigabit hardwire removed
priority: criticalmajor
Version: VirtualBox 2.2.0VirtualBox 3.0.8

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

comment:15 by LarsV33, 14 years ago

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. :(

in reply to:  15 comment:16 by vasily Levchenko, 14 years ago

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.

comment:17 by vasily Levchenko, 14 years ago

please check with 3.1

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

in reply to:  17 ; comment:18 by Gabriele Vivinetto, 14 years ago

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.

in reply to:  18 comment:19 by vasily Levchenko, 14 years ago

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.

comment:20 by vasily Levchenko, 14 years ago

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

comment:21 by vasily Levchenko, 14 years ago

Resolution: fixed
Status: newclosed

comment:22 by Tom Davidson, 14 years ago

Resolution: fixed
Status: closedreopened

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)

comment:23 by Tom Davidson, 14 years ago

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.

in reply to:  23 comment:24 by vasily Levchenko, 14 years ago

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.

comment:25 by Tom Davidson, 14 years ago

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?

in reply to:  25 comment:26 by vasily Levchenko, 14 years ago

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.

comment:27 by Tom Davidson, 14 years ago

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

in reply to:  27 comment:28 by vasily Levchenko, 14 years ago

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.

comment:29 by Tom Davidson, 14 years ago

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.

in reply to:  29 comment:30 by vasily Levchenko, 14 years ago

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.

in reply to:  29 ; comment:31 by vasily Levchenko, 14 years ago

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

in reply to:  31 ; comment:32 by Tom Davidson, 14 years ago

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

in reply to:  32 comment:33 by vasily Levchenko, 14 years ago

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.

comment:34 by Frank Mehnert, 14 years ago

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

comment:35 by vasily Levchenko, 14 years ago

Summary: re-initiate NAT on Network switchre-initiate NAT on Network switch -> fixed in svn

comment:36 by Frank Mehnert, 14 years ago

Resolution: fixed
Status: reopenedclosed

comment:37 by Bharath Kumar, 13 years ago

Resolution: fixed
Status: closedreopened

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

in reply to:  37 comment:38 by vasily Levchenko, 13 years ago

Resolution: fixed
Status: reopenedclosed

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.

comment:39 by Bharath Kumar, 13 years ago

Hi,

adding clarification:

  1. I have installed VirtualBox on XP host downloaded from : http://www.virtualbox.org/wiki/Downloads
  1. I have configured the network settings:

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

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

The issue same as the one originally reported.

Thanks, Bharath

in reply to:  39 comment:40 by vasily Levchenko, 13 years ago

Replying to bkumarm:

Hi,

adding clarification:

  1. I have installed VirtualBox on XP host downloaded from : http://www.virtualbox.org/wiki/Downloads
  1. I have configured the network settings:

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

  1. created a new virtual machine, with redhat os.
  2. after os is installed, started the vm and logged in.
  3. 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.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use