VirtualBox

Ticket #12750 (closed defect: fixed)

Opened 9 years ago

Last modified 9 years ago

Internal network traffic leaks out of host => Fixed in SVN

Reported by: Richard Boyce Owned by:
Component: network Version: VirtualBox 4.3.8
Keywords: Cc:
Guest type: Windows Host type: Mac OS X

Description

When data is being transferred between the host and guest (in either direction) over a bridged network link, the data is being copied to the host's physical Ethernet port and exported.

Tested only with XP Pro 32 and 7 Pro 64 guests running on an OS X host. The problem appeared after upgrading the host from Snow Leopard to Mavericks. Bridged networking on a single NIC, both paravirtualised and other types. Promiscuous mode set to Deny.

Attachments

VBox.log Download (92.6 KB) - added by Richard Boyce 9 years ago.

Change History

comment:1 Changed 9 years ago by aleksey

Could you provide a bit of clarification? How did you check for leaked traffic exactly? Were you sniffing traffic on external host? Please also provide the log file.

Changed 9 years ago by Richard Boyce

comment:2 Changed 9 years ago by Richard Boyce

I've long monitored network activity (amongst other things) using a tool called MenuMeters. After upgrading to Mavericks, MenuMeters showed outgoing activity at the same rate and time as the internal activity. My Mac is connected to a network switch and that confirmed the activity on its connection to the Mac. No other ports on the switch were active at the time, so the data flow stopped at the switch. MenuMeters reported no data being echoed back from the switch. I made no attempt to sniff the content of the traffic.

Last edited 9 years ago by Richard Boyce (previous) (diff)

comment:3 Changed 9 years ago by aleksey

Thanks a lot for the explanation. We have been able to reproduce the problem locally and are working on it.

comment:4 Changed 9 years ago by Legorol

This sounds to me like it's working as intended.

When you are using bridged networking, then both the host and the guest are considered to be directly connected to the external physical network, as if they were two separate computers. Any traffic between them is supposed to appear on the physical network, just as it would if two separate, physical computers were communicating with each other. This would allow a third computer to sniff the traffic (which is how it should be).

Example: Let's say you have two physical computers, A and B connected to your physical network. In this case, a third computer C in promiscuous mode running a network sniffer will be able to watch the traffic between A and B. This behaviour should be replicated if A and B are not physical computers, but for example two VMs using bridged mode networking.

If you want to avoid traffic between the host and guest from going out on the physical network, then use host-only networking (that's what it's there for).

Version 0, edited 9 years ago by Legorol (next)

comment:5 Changed 9 years ago by aleksey

That is actually incorrect. VirtualBox goes extra mile to ensure that unicast traffic between VMs and the host never reaches wire. The only exception is made for promiscuous mode. When the adapter VirtualBox "bridges" to is in promiscuous mode all traffic is sent to the wire no matter where the traffic is destined to. This is done because OS X supports Berkeley Packet Filter which is implemented as hooks in Ethernet drivers. Please note that I am talking about host's adapter, not about adapters in virtual machines.

comment:6 Changed 9 years ago by aleksey

The test build containing the fix is available here.

comment:7 Changed 9 years ago by Richard Boyce

Initial testing suggests the problem is fixed. Thank you.

comment:8 Changed 9 years ago by frank

  • Summary changed from Internal network traffic leaks out of host to Internal network traffic leaks out of host => Fixed in SVN

Thanks for testing!

comment:9 Changed 9 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fix is part of VBox 4.3.10.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use