The official llllloooooo blog

Sunday, January 12, 2020

VirtualBox not passing 802.1q VLAN tags to or from guests with Broadcom NetXtreme 57xx Gigabit Ethernet on Windows 10 Host

I have a Dell Latitude E5500 laptop running Windows 10 Home Edition (Version 1909) which has a Broadcom NetXtreme 57xx Gigabit Controller Integrated Ethernet port (Driver version 214.0.0.0 by Microsoft)

I tried to setup a Linux Guest Virtual Machine (OpenWRT but I think this applies to all guests) using Oracle VirtualBox (Version 6.1) . I wanted my guest to access the real world network so I used the "Bridged Adapter" setting in the Network Properties of the guest and bridged the guest to my Broadcom Gigabit Ethernet Interface. Note that I changed the "Promiscuous Mode" setting from the default of "Deny" to "Allow All" in order to let my guest see a wider range of frames.

Guest Network Settings in VirtualBox

This worked fine for normal non tagged networking but when I wanted my guest to use 802.1q VLAN tagging, the tagged frames didn't seem to get to or from the guest's tagged interfaces.

Note that I did not have any kind of 802.1q VLAN tagging enabled on the host Windows device. I suppose another approach to this problem would have been to create separate VLAN tagged interfaces on the host and bridge them individually to the guest, but I honestly couldn't figure out how to do that. I think Windows 10 Home has some kind of in built impediment to using VLANs and 802.1q tagging.

To get 802.1q VLAN tags to pass to the guest I had to follow the instructions as seen in a few other sites that tackle a similar problem where the WireShark sniffer software running on Windows doesn't display VLAN tags when sniffing on this kind of network interface. For example

Wireshark VLAN Capture Setup
https://wiki.wireshark.org/CaptureSetup/VLAN

LiveAction - Don't Lose the Tags
https://mypeek.liveaction.com/tip.php?id=21

The instructions basically boil down to adding a special Windows Registry Key value as follows.

* Run the Windows Registry Editor regedit on the Windows 10 host. (Windows Key + R , then open regedit)

* In the Registry Editor search under the folder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class for a value called TxCoalescingTicks . This will take you to the registry folder corresponding to your Broadcom GigE adapter where you need to perform the next steps. Note that we only want to find the folder that is under CurrentControlSet. Ignore folders that are NOT under CurrentControlSet. Also note that in some circumstances there might be more than one folder under the CurrentControlSet to have that TxCoalescingTicks value (multiple adapters installed?). Try to determine which one of them corresponds to your network card.

* The folder you've discovered should have a name along the lines of

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\00xx

where xx just means some hexadecimal number unique to your system.

*  Add a new String Value to the folder you'd discovered with name PreserveVlanInfoInRxPacket and set the value to 1. After adding this value to the folder it should look something like this

Newly created PreserveVlanInfoInRxPacket Value added to folder
After disabling and then re-enabling the host's Broadcom GigE network interface in Control Panel (which you could just do by rebooting the host) and stopping and restarting the guest in VirtualBox, I found that my guest was then able to receive and transmit tagged 802.1q frames as expected.

From what I can tell these instructions might also work with other types of Broadcom brand GigabitEthernet controllers being used on Windows 10 hosts. 

I guess based on the name of the PreserveVlanInfoInRxPacket value being added, the problem was that the Windows driver was removing 802.1q VLAN tags on frames to and from the guest. This meant that the guest was receiving everything on its native untagged VLAN, and when it transmitted a tagged frame it was being output as untagged on the host's physical GigE interface.

I also want to note that for my guest I had to change the default VirtualBox Guest Networking setting of Promiscuous Mode to All to get things working. This means that the guest is able to tell its virtual networking adapter to listen to all frames rather than just the ones directed to it. I don't know if that's required in all cases though.