Hyper-V and Wireless networking

 

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.

Diagram showing a root partition a virtual machine hosted on machine 1, both connected to machine 2 via (in this order): virtual NIC on the root partition (MAC: A), connected to a virtual external switch, connected to a physical wired NIC (MAC: Ph1), connected to a physical NIC on machine 2 (MAC: Ph2). Also, virtual NIC on the virtual machine (MAC: B), connected to a virtual external switch, connected to a physical wired NIC (MAC: Ph1), connected to a physical NIC on machine 2 (MAC: Ph2).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:

  1. Create a single adapter bridge connected to the WiFi adapter
  2. Create the external virtual switch
  3. 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.

Diagram showing a root partition and a virtual machine hosted on machine 1, both connected to machine 2 via (in this order): virtual NIC on the root partition (MAC: A), connected to a virtual external switch, connected to a Microsoft Bridge (MAC translation), connected to a WiFi NIC (MAC: Ph1), connected to a physical NIC (MAC: Ph2) on machine 2. Also, virtual NIC on the virtual machine (MAC: B), connected to a virtual external switch, connected to a Microsoft Bridge (MAC translation), connected to a WiFi NIC (MAC: Ph1), connected to a physical NIC (MAC: Ph2) on machine 2.
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:

  1. Wireless adapter does not work with our bridge.  You can check this by updating drivers, trying different adapters.
  2. 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.

If wireless networking is not working for you – you can also utilize the Windows support for NAT to get network connectivity.  I document how to do this here: http://blogs.msdn.com/b/virtual_pc_guy/archive/2008/01/09/using-hyper-v-with-a-wireless-network-adapter.aspx

Cheers,
Ben

Update 5/2/2016: If you are running Windows 10 check out this blog post https://blogs.msdn.microsoft.com/virtual_pc_guy/2016/05/02/windows-10-hyper-v-and-wireless-a-new-way-to-make-this-all-work/