VirtualBox

Opened 14 years ago

Closed 9 years ago

#5890 closed defect (duplicate)

DNS not working in bridged networking on Windows host v3.1.2

Reported by: Gary Owned by:
Component: network/hostif Version: VirtualBox 3.1.2
Keywords: DNS bridged Cc:
Guest type: other Host type: Windows

Description (last modified by Valery Ushakov)

I upgraded to version 3.1.2 and have not been able to get guest DNS resolution to work under bridged networking. I have tried this with OpenSolaris, Fedora, WinXP and Win7 guests. All are consistent. If I select NAT the guests' DNS resolution works fine. However, if I use bridged networking I get no name resolution. DHCP assigns the DNS server correctly and I can ping the name server and I can access Internet sites via ethernet addresses. The only problem seems to be the name resolution.

Here is some NAT info from a successful DNS config. Again, it is NAT.


ifconfig -a
eth0      Link encap:Ethernet  HWaddr 08:00:27:B2:05:49
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feb2:549/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3786 (3.6 KiB)  TX bytes:5997 (5.8 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:22 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1868 (1.8 KiB)  TX bytes:1868 (1.8 KiB)

pan0      Link encap:Ethernet  HWaddr D6:25:56:27:0F:63  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[gary@fedspike ~]$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.1

Here is a bridged session. I can ping the 192.168.1.1 or even the google.com IP address. I just cannot get ANY name resolution at all...


[gary@fedspike ~]$ nslookup google.com
;; connection timed out; no servers could be reached

[gary@fedspike ~]$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 08:00:27:B2:05:49  
          inet addr:192.168.1.148  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feb2:549/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:205 errors:0 dropped:0 overruns:0 frame:0
          TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13542 (13.2 KiB)  TX bytes:13592 (13.2 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1040 (1.0 KiB)  TX bytes:1040 (1.0 KiB)

pan0      Link encap:Ethernet  HWaddr 2A:FF:22:C6:BD:87  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[gary@fedspike ~]$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.1

Is it possible that there is a problem in the VBoxNetflt driver? It seems to have been updated in 3.1.2 for Windows.

Attachments (2)

google dns query.pcap (14.2 KB ) - added by Gary 14 years ago.
DNS failure log from wireshark
host dns querys filter.pcap (46.8 KB ) - added by Gary 14 years ago.
Filtered packets from wireshark trace of host.

Download all attachments as: .zip

Change History (42)

comment:1 by Gary, 14 years ago

This is happening on a windows host, for me. It worked ok when I used 3.0.1 but has been broken since I upgraded to 3.1.2.

comment:2 by vasily Levchenko, 14 years ago

Component: networknetwork/hostif

comment:3 by Gary, 14 years ago

Has anyone been able to reproduce this?

comment:4 by Aleksey, 14 years ago

I have experienced the same problem after I had upgraded from 3.0.10 to 3.1.2

Host OS: Windows XP SP2

Guest OS: Solaris 10 u8

comment:5 by Gary, 14 years ago

Has anybody at Sun looked at this potential problem with bridged networking on Windows hosts?

comment:7 by misha, 14 years ago

Does reverting back to 3.0.x resolves the problem for you?
What third-party networking-related software (like VPN, Antivirus, Firewall or virtualization software) do you have installed on your host?

comment:8 by Frank Mehnert, 14 years ago

Host type: otherWindows

comment:9 by Gary, 14 years ago

No, I reverted back to 3.0.1 and the problem continued. I run only Norton anti-virus and disable the windows firewall. I use a DLink DIR-655 wireless router.

The system config is the same as before upgrading VBox. The DNS resolution worked with bridged guests before upgrading but not after.

in reply to:  9 comment:10 by misha, 14 years ago

Replying to ghutch:

No, I reverted back to 3.0.1 and the problem continued.

Do you mean 3.1.0 or some 3.0.x release? (there is no official 3.0.1 release). If you mean 3.1.0, could you try some 3.0.x release please?

comment:11 by Gary, 14 years ago

Sorry, It was 3.0.12 and 3.0.10 before that. Both of those used to work until I upgraded to 3.1.2. Now even if I revert back to 3.0.12 the problem remains...

comment:12 by Gary, 14 years ago

Any activity on this? I have heard nothing more. Bridged networking still is causing problems with DNS. There are now at least 3 other defects opened.

5924 - http://www.virtualbox.org/ticket/5924
5949 - http://www.virtualbox.org/ticket/5949
6006 - http://www.virtualbox.org/ticket/6006

comment:13 by Klaus Espenlaub, 14 years ago

There can't be activity if there's insufficient information (the other defects actually contain considerably less information than this one) and no way to reproduce. There are an infinite number of things which can block DNS traffic, and it's impossible to guess what's the problem.

Can you use a sniffer to capture a packet trace of DNS traffic from/to the guest and attach the capture file (not the text output e.g. of tcpdump)? A good place for this would be the host, capturing the data on the bridged interface. It doesn't have to be long, and if you're not doing much on the host the amountof uninteresting traffic should be quite low. Please add a description mentioning which IP is what, otherwise it's just guesswork.

comment:14 by Gary, 14 years ago

I will attempt a trace and get back to you. In the mean time, however, if a virtualbox host is setup on a Windows system and any client is created this should be reproducible at your end - no matter the physical network setup.

On the client, make sure "bridged" networking is set (not NAT). Once the client is booted it will not be able to recieve DNS responses. The client CAN ping the DNS server and the DNS server is properly set by DHCP for the resolv.conf (or whichever resolve tool is used). The client just will not be able to nslookup or gethostbyname. Web browsers will not work because the URLs will not be resolved. You can, however, browse to sites using their IP addresses.

If the problem is different due to physical network setup that could also narrow down the location of the problem.

Thank you for your time. Gary

comment:15 by Klaus Espenlaub, 14 years ago

The problem is that life isn't that easy. Just tried 3.1.2 with bridged networking again, both wired and wireless, and everything worked as it should. Windows Vista 32bit host, Windows XP 32bit guest. It gets a dhcp lease, and happily can talk to the DNS server (which is outside the LAN in our case).

If it would be a bug which affects every user on Windows host with bridged networking, we'd have thousands of people complaining. The number of bug reports however is very small. So we completely depend on feedback from the few people which observe this bug.

comment:16 by Gary, 14 years ago

Ok, I am not a winders user. That is kind of why I am using virtual box. I want to run OpenSolaris but the rest of the family needs winders. I, therefore, am not aware of network trace utilities inside of winders.

How would I go about setting up a trace in the winders host to trace the guest DNS activities?

My DNS server is my home router, (192.168.1.1) in this case, that forwards the request to my ISP.

comment:17 by Klaus Espenlaub, 14 years ago

There's wireshark for windows, which is free and I know that wireshark on other platforms can analyze the capture data.

comment:18 by Gary, 14 years ago

I will look for wireshark. It will be this evening as it is my home system with the problem. I am in US/Eastern.

comment:19 by Gary, 14 years ago

I just downloaded and did a fresh install on my work PC. I do NOT see the problem here. Here, however, at work the PC is on a real network.

I am not sure what the d-link router at home does to forward DNS activity between DNS servers and requesting hosts. My host PC at home works fine with the d-link forwarding DNS requests to the ISP. It is just guests in virtualbox that don't work with DNS when the guest is setup with "bridged adapter" set as the network adapter in the home environment.

by Gary, 14 years ago

Attachment: google dns query.pcap added

DNS failure log from wireshark

comment:20 by Gary, 14 years ago

This is a trace from a WIN7(64bit) guest. I don't know if it is enough for you to determine anything. The guest 192.168.1.146 sends a standard query, but I don't see a response. Is ther maybe a firewall setting on the host that could affect this? Is there something going on with the d-link router not forwarding the standard request properly?

comment:21 by Gary, 14 years ago

I tried to upload a 1.85MB trace and got a failure. It is the trace from the host with a DNS filter set.

by Gary, 14 years ago

Attachment: host dns querys filter.pcap added

Filtered packets from wireshark trace of host.

comment:22 by Gary, 14 years ago

There! The second file is a filtered trace of the Win7 host during the time of the guest trace before it.

comment:23 by Klaus Espenlaub, 14 years ago

From host dns query.pcap I can see that VirtualBox thinks your network is wired. It uses the guest's MAC address on the physical network. Since you mentioned you're on wireless, I wonder if that might be the root cause. Can you confirm that your host is using WLAN? Also a VBox.log file might sched some light on this...

Since you captured host dns querys filter.pcap on the network interface on the host (which means that one would even see packets dropped by any firewall software on the host), it looks like the problem is between your host and the router. There is no response sent back, and I can't spot any problem with the guest traffic going through the host's interface.

ARP queries are not in your filtered capture (expecially not if 192.168.1.1 ever asked for the MAC address of 192.168.1.146), however the fact that you can ping 192.168.1.1 from the guest is a hint that ARP queries are working fine. On the other hand, if pings work I fail to see why DNS wouldn't work...

So all still very mysterious.

in reply to:  9 comment:24 by misha, 14 years ago

Replying to ghutch:

No, I reverted back to 3.0.1 and the problem continued. I run only Norton anti-virus and disable the windows firewall.

I suspect Norton anti-virus has some network protection component (i.e. firewall, etc.) that is usually presented as intermediate driver in the network stack.
If this is true, to ensure this is not an vbox-norton interoperation issue, could you try to temporary disable the norton network protection component and see if it solves your problem.
If disabling the via the antivirus settings does not help, try additionally disabling the network protection intermediate driver.
This could be done by unchecking the "Norton.." component in the network connection properties dialog.
NOTE: you should re-enable the networking protection in the reverse order, i.e. you should first enable the "Norton.." component in the network connection properties dialog in case you disabled it.

comment:25 by Gary, 14 years ago

It must have been another posting that stated they were wireless. I am wired (sometimes with coffee). This has always been a wired connection to the d-link. I have tried shutting down the firewall with no changes. But, as I said, I am not a windows user, normally. The "click here and click there" interface is sometimes overwhelming... I think the firewall was shutdown but I can't remember how I did it.

The odd thing about the guest DNS response is that the DNS query is being sent, just not returned? Pings to IP addresses and browsers to IP addresses work fine as do access to network shares from the host and other computers on the network attached to the d-link router.

comment:26 by Gary, 14 years ago

Also, The host has no DNS resolution problems. Also, remember that the guests have no DNS resolution problems if I use NAT instead of Bridged Adapter.

comment:27 by Gary, 14 years ago

Alright, I have turned firewalls off in both the host and guest, I have disabled "host-only" in the virtualbox network preferences, I have checked my router to be sure there are no rogue settings.

I have uninstalled and reinstalled the virtualbox completely. I even went and cleard out as many registry entries as I could find and deleted driver files that were not removed prior to reinstalling. I rebooted after the uninstall and again after the reinstall - just to cover that base. No joy''

I have also hard coded DNS servers into the guest. I hardcoded my ISP's DNS server (which is pingable) as well as an "open" name server on the internet. No difference from the local 192.168.1.1 that works here on everything (4 discreet computers in my house) except the virtualbox, bridged adapter guests.

I am baffled. The guest still will not work with DNS if the bridged adapter is set.

comment:28 by Gary, 14 years ago

Klaus, Could this be a 64-bit host related issue? What was the host you were replicating this on?

The install I did at work was on a 32-bit WinXP host that did not exhibit the problem. The other reports of failures here seem to be 64-bit host related. My host that does not work is a win7 64-bit ultimate.

comment:29 by Klaus Espenlaub, 14 years ago

I've tried it on Vista Ultimate 32bit.

It's quite far fetched that there's a problem with 64bit windows hosts in the bridged networking are, affecting just DNS (but not ping), but one never knows. It would have to be a very very weird bug, as the packet trace you captured on the host shows no problems (checksum is correct, and no other anomalies which could actually cause the DNS queries to be immediately dropped in the router).2

comment:30 by Gary, 14 years ago

Working in the software development industry I have seen strange things! I wouldn't call the possibility that the error (bug) occurs in only the 64-bit environment "far fetched."

I played around more with wireshark last night. I put a filter on port 53 (UDP) and watched the DNS activity on the host. The host and any other non-virtual system on the 192.168.1.x network received responses to DNS queries while the virtual systems did not. I looked at the request packets that were sent by the guests and could not detect any abnormality in the packet when compared to the host request packets. I am looking closer at the router to be sure there is nothing inhibiting port 53 for those address ranges. I have tried multiple IP addresses to be sure it was not a single address that the problem occurs with on the router.

As I look closer at the router, could you test on a 64bit host? I do not have another one to try this on.

in reply to:  30 comment:31 by misha, 14 years ago

Replying to ghutch: Although wireshark sees all dns packets guest submits, there is still a possibility that those packets do not actually reach the host network in case there is some im filter driver (like Norton antivirus one) seeting behind the VBox Bdiging driver and filtering out those packets.
This is why the ideal test would be to have some other host on the same network sniffing the traffic. If this is not possible, please ensure you have all custom (e.g. Norton..) im network filters disabled (unchecked) as I mentioned in comment 24.

You could access the network connection properties via control panel:

  1. type "control" in the command line-> this would launch control panel window
  2. in the "Search control panel" edit box in the right top corner type "network" -> you should then see the "View network connections" entry displayed in the main window under "Network and Sharing center".
  3. Clicking the "View network connections" entry will open the network connection window. In that window right-click the network connection you are using and select "properties" in the popup menu.

The typical entries that should be there are "Client for Microsoft Networks", "QoS Packet Scheduler", "File and Printer Sharing...", "Internet Protocol V4..", "Internet Protocol V6..", and a set of "Link-layer topology.." entries. If there are any Norton internet security - related entries try uncheking them and see if that helps.

Meanwhile I should be able to test it on 64bit windows 7 host later today, although I used bridging on 64bit hosts many times before and it always worked fine for me.

in reply to:  30 comment:32 by misha, 14 years ago

Replying to ghutch:

As I look closer at the router, could you test on a 64bit host? I do not have another one to try this on.

Just tried it on Win7 x64 host, and can not reproduce the problem there.. bridged networking works fine..

comment:33 by Gary, 14 years ago

Misha, I don't remember seeing any norton entries in the adapter properties. Are you talking about on the host or on the guest? I will look again this afternoon when I return home to where the system in question is. I will also see if I can setup wireshark on a separate system on the network.

Thank you for testing on a 64bit host!

in reply to:  33 comment:34 by misha, 14 years ago

Replying to ghutch:

.. Are you talking about on the host or on the guest? ..

I am talking about the host of course, since this is where VBox Bridged Networking driver runs.

comment:35 by Gary, 14 years ago

Looks like mystery solved!

I opened properties. I didn't see any anti-virus items in the list. So, I started shutting things off that I thought would NOT affect normal network operations. The item "Shrew Soft Lightweight Filter" looked like a candidate. Sure enough - once I shut it off DNS started working inside VirtualBox guests.

Shrew Soft is a VPN client. There seems to be some kind of interaction failure with it. If I turn it on DNS goes away, if I turn it off DNS works.

It is still not clear why only Virtual Box DNS packets are affected. I suppose I will contact Shrew Soft and see if they can shed any light on the failure?

Thank you for your help Klaus and Misha. Your hints led me in the right direction to clear up the mystery.

comment:36 by misha, 14 years ago

Resolution: duplicate
Status: newclosed

That's what I thought (remember I asked you in Comment 7 about the third party networking software)..

This is just a duplicate of a #3752, and as mentioned in #3752 this is Shrew driver fault and the same happens with WMWare also..

comment:37 by Aleksey, 14 years ago

Hmm. I have never used Shrew driver.

I turned off Windows firewall and Avira antivir. The problem was still there so I turned on them again.

Then I uninstalled 3.1.2 and re-installed 3.0.12 - voila, the problem has gone!

So I have the problem only when I use 3.1.2.

comment:38 by kiboko, 14 years ago

Resolution: duplicate
Status: closedreopened

I have exactly the same problem using 3.1.2 on a Mac OS X Server (on Xserve) host with a bridged network adapter (with Windows 2003 server as Guest OS)

DNS doesn't resolve although nslookup works. Seems that TCP port 53 is forwarded but UDP port 53 isn't. Others have reported the same problem and it seems that everything worked fine in 3.0.12 on Mac OS X Server hosts too.

To me this is clearly a bug in 3.1.2

comment:39 by kiboko, 14 years ago

I got one step further in finding where exactly it goes wrong. The DNS resolver sometimes works and sometimes doesn't.

if I resolve an address that only has an A record it works fine. Even if this name resolves to a round robin of systems.

For instance ping cnn.com works fine. If however you try to ping to a site that resolves to an alias (like ping www.microsoft.com) it fails. If you resolve www.microsoft.com using nslookup it works and shows that indeed this address is remapped to some aka address.

In my case I try to run Mcafee Epo server in a virtual machine. This demon tries to connect to ftp.nai.com. This fails as again ftp.nai.com resolves to an alias address.

Can anyone reproduce this?

comment:40 by Valery Ushakov, 9 years ago

Description: modified (diff)
Resolution: duplicate
Status: reopenedclosed

It doesn't help to reopen a bug that is just superficially similar. Moving it to re-closed.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use