Having a hypervisor built right into the client operating system is a great thing, especially if it is as fast and stable as Client Hyper-V found in Windows 8. The functionality is very good, too, but a single feature is sorely missing: the ability to share the host’s (internet) network connection.
Hyper-V networking is OK as it is, but it lacks VMware Workstation’s NAT feature. To recap, Hyper-V virtual switches come in the following three flavors:
- External: VMs have physical network connectivity only
- Internal: VMs are not connected to the physical network but can talk to each other and the host
- Private: VMs are not connected to the physical network. They can talk to each other but not to the host
In a typical lab scenario you want the VMs to be able to talk to each other. You also want to access them from your host. Therefore you need a virtual NIC in each VM that is connected to a virtual switch of type internal. However, with this setup your VMs have no internet access. This can significantly slow down installations and it obviously makes updating and many other tasks unnecessarily difficult.
Internet Access for Your VMs
There are a variety of options for connecting your VMs to the internet.
Second Network Card
The most obvious solution is to add a second NIC to each VM and connect that NIC to a virtual switch of type external.
I do not like this approach very much, though. It adds complexity and makes name resolution much more difficult. But perhaps the most serious caveat is that you need to specify which physical NIC the virtual switch is connected to. If you are using Client Hyper-V on a laptop then you probably sometimes connect via Wi-Fi and sometimes via Ethernet (cable). Your external switch would only cover one of those two use cases. And you certainly would not consider adding two external-facing virtual switches, one bound to the Wi-Fi adapter and the other bound to the Ethernet card, would you?
Internet Connection Sharing (ICS)
A solution that is commonly recommended is to use Internet Connection Sharing (ICS), a kind of NAT service that has been part of Windows for a long time.
I have tried to use this for some time but found it to be very unstable and seriously impacting network throughput.
Update: I used this for a while until I switched to the RRAS solution suggested by several commenters (details below). Although FreeProxy generally works well enough it did cause problems using VPNs through it: the VPN connection itself would typically be established, but accessing resources over the VPN would sometimes be very slow and at other times not work at all. For your reference I am leaving the original description of how to configure the proxy solution as it was, but I recommend the RRAS setup described below.
I have equipped a single VM (which is running all the time anyway) with a second NIC connected to an external virtual switch. The VM is running the free proxy server appropriately named FreeProxy.
FreeProxy runs as a service and although it is rather old I had no problems getting it to work on Server 2012 R2. It is simple to configure, just make sure you run the configuration utility FreeProxy Control Centre with admin privileges.
My configuration is as follows. Main UI:
Of course you still need to configure your other VMs to use the proxy. An easy way to do that for Internet Explorer (and Windows Update) is via Group Policy Preferences if you have that available in your lab.
Windows Server Routing with NAT
I was not aware of the fact that Windows Server comes with a NAT component (thanks Thorsten, Dan and Jay for pointing it out in the comments section below). If you have at least one VM with a server version of Windows this is the solution to implement.
As with the proxy solution described above you need one VM with a second NIC connected to an external virtual switch. In order to be able to easily distinguish between the two NICs rename one to “Internal” and the other to “External”.
Setting up NAT is surprisingly simple if you know where to find it. This is how it works on Server 2012 R2:
- Bring up the Add Roles and Features Wizard in Server Manager
- Select the Remote Access role
- Select the Routing role service. A dialog comes up listing a handful of features that must also be installed for routing to work.
- Once the installation is finished click Open the Getting Started Wizard:
- Click Deploy VPN only. The Routing and Remote Access management console opens.
- Right-click your server and select Configure and Enable Routing and Remote Access:
- Select Network Address Translation (NAT):
- Select the external (internet-facing) NIC:
- You are done! Of course you need to point the default gateway on your other VMs to the IP address of the internal NIC of the NAT machine.
I am aware that this solution still requires one external virtual switch per network type (Wi-Fi and Ethernet). At least the external NICs are only needed for the VM that is running the proxy. I am currently using this with a single external switch connected to Ethernet.