I have been getting a lot of questions about Hyper-V and wireless networking lately. Specifically, these questions have been from people saying “why does it work sometimes, and not work other times”. To give some background – wireless networking is quite tricky for virtualization. To explain what we actually do here – let me steal from a great post on the Building Windows 8 blog:
The problem
The virtual switch in Hyper-V is a “layer-2 switch, ” which means that it switches (i.e. determines the route a certain Ethernet packet takes) using the MAC addresses that uniquely identify each (physical and virtual) network adapter card. The MAC address of the source and destination machines are sent in each Ethernet packet and a layer-2 switch uses this to determine where it should send the incoming packet. An external virtual switch is connected to the external world through the physical NIC. Ethernet packets from a VM destined for a machine in the external world are sent out through this physical NIC. This means that the physical NIC must be able to carry the traffic from all the VMs connected to this virtual switch, thus implying that the packets flowing through the physical NIC will contain multiple MAC addresses (one for each VM’s virtual NIC). This is supported on wired physical NICs (by putting the NIC in promiscuous mode), but not supported on wireless NICs since the wireless channel established by the WiFi NIC and its access point only allows Ethernet packets with the WiFi NIC’s MAC address and nothing else. In other words, Hyper-V couldn’t use WiFi NICs for an external switch if we continued to use the current virtual switch architecture.
Figure 1: Networking between VM and external machine using wired connection
The solution
To work around this limitation, we used the Microsoft Bridging solution, which implements ARP proxying (for IPv4) and Neighbor Discovery proxying (for IPv6) to replace the virtual NICs’ MAC address with the WiFi adapter’s MAC address for outgoing packets. The bridge maintains an internal mapping between the virtual NIC’s IP address and its MAC address to ensure that the packets coming from the external world are sent to the appropriate virtual NIC.
Hyper-V integrates the bridge as part of creating the virtual switch such that when you create an external virtual switch using a WiFi adapter, Hyper-V will:
- Create a single adapter bridge connected to the WiFi adapter
- Create the external virtual switch
- Bind the external virtual switch to use the bridge, instead of the WiFi adapter directly
In this model, Ethernet switching still happens in the virtual switch, and MAC translation occurs in the bridge. For the end user who is creating an external network, the workflow is the same whether you select a wired or a wireless NIC.
Figure 2: Networking between VM and external machine using WiFi connection
Unfortunately, this approach does not always work. There are a number of reasons why we see this failing – but the two leading ones are:
- Wireless adapter does not work with our bridge. You can check this by updating drivers, trying different adapters.
- DHCP server does handle requests that have gone through the bridge. Some DHCP servers get confused by DHCP requests coming from guests once they have gone through the wireless bridge.
