Archive for January, 2010

This latest cool solution comes from a colleague of mine, Andrew Abbate and looks at providing access to isolated VM guests.

In my lab environment, I had a major constraint around IP address space.  As such, I was given 4 IP addresses that covered my 4 Hyper-V hosts.  Thus I needed a way to address and reach my 40+ VMs that are configured in isolated networks.

The solution?  VLAN tagging and NAT.

The first step was to utilize the HP NIC utilities to create a tagged VLAN port (virtual interface). This can be done with any NIC that supports VLAN tagging including Broadcom and Intel Pro.

This gave me a 2nd interface to which I could bind an additional subnet without needing any additional network ports to activate additional networks in the Hyper-V servers.

In Hyper-V, the virtual switch is bound to the tagged VLAN interface

Similarly, the individual VMs are bound to the same VLAN tag.

Within the VM, the guest is configured to use an IP from the subnet which is on the tagged VLAN and it uses the Hyper-V host as its default gateway.

The Hyper-V host then receiveds the Network Access and Policy Services role.  This gives us Routing and more importantly, Network Address Translation.

The “public” interface on the Hyper-V host is listed as the “internet” interface, and the tagged interface is used as the “shared” interface.  This allows the IP range on the VMs to use the Hyper-V host as a NAT gateway. Useful to note is that if you forget to check “Enable virtual LAN identification” on the virtual switch interface (as shown above) the VMs will be able to talk to each other from host to host, but not talk to the host itself.  This can be annoying for getting non-ISOs from the host to the guest and will prevent NAT from working.

At this point, NAT allows the VMs to talk to networks on the other side of the Hyper-V host – including the Internet!

Now at this point, my needs became slightly more esoteric.  I needed to test USB devices against the VM.  Since Hyper-V doesn’t have the ability to pass a USB device from the host to the guest, I needed another way.  I needed to be able to RDP directly into a VM that was on a network that wasn’t routable.  This is where the NAT configuration provides a solution.

By going into the properties of the public interface in the RRAS interface:

And then into the Services and Ports tab:

I’m able to add a service for a NAT/PAT rule allowing RDP on a custom port:

In this case, I’m saying “if someone hits the public interface on Hyper-V on port 3390, pass that to a specific VM on port 3389.”  This allows me to publish all my VMs RDP services via a single IP address.  I simply have to alter the port in the RDP client:

Net result, I can reach my 40 VMs running on an isolated network from a production network without having to burn 40 IP addresses.  This can be very useful in a lab environment where you need to be able to bypass the processes of the network folks to get something working. Also a fun exercise in VLAN tagging and NAT rules.

Second option specific to RDP access is to deploy a TS gateway on the host to listen on the Untagged VLAN and provide connections to systems on the Tagged VLAN.

To accomplish this, I added RPC over HTTPS Proxy as a feature and Remote Desktop Services (R2) along with IIS as roles.  Defined the access rules and for now, just created the self signed cert.

Installed the self signed cert into the Trusted Root container in my workstation and I’m able to reference the Hyper-V host as my TS Gateway and list the “not really reachable” IP as my target and RDP works fine.

So while both options can be used to provide RDP access to isolated guests, the incoming NAT translation can be used for many other purposes since its protocol independent, for example, with it I’m able to run Windows Updates on my isolated Lab systems!