Enabling Hyper-V Management through DirectAccess

  • Article

Lots of folks have bemoaned the fact that Hyper-V manglement through DirectAccess (DA) is (at best) inconsistent.

To understand why this is so, we have to understand a bit about how Hyper-V and DA work from a network perspective.

In order to support the bi-directional connectivity required by Hyper-V WMI usage, Installation of the Hyper-V manglement role adds three inbound firewall rules (yes; even on your Win7 laptop):

  1. Hyper-V Management Clients – WMI (Async-In)
  2. Hyper-V Management Clients – WMI (DCOM-In)
  3. Hyper-V Management Clients – WMI (TCP-In)

These rules allow inbound RPC and DCOM traffic necessary for remote manglement of Hyper-V services and usage of related guests.

The problem with these rules and DA is that:

  1. These rules block traffic that indicates NAT traversal
  2. Encapsulation of IPv6 messages within an IPv4 tunnel requires extra consideration from a client-side firewall perspective, and also from a certain perspective can be thought of as NAT technology. This should not be confused with the NAT64/DNS64 solution included with UAG DirectAccess, since NAT64/DNS64 doesn’t apply in this scenario. However, between the two ultimate endpoints, “network addresses” are most often being translated; thus, we have “Network Address Translation” in effect.

The way to fix them so that you can manage your Hyper-V through DA is to behave like unto thusly on your remote manglement (DA) host:

1. Start | Administrative Tools | Windows Firewall with Advanced Security

clip_image004

2. Select Inbound Rules, and scroll down until you see the three Hyper-V rules:

clip_image006

3. Right-click Hyper-V Management Clients – WMI (Async-In) and select Properties

clip_image008

4. Click the Advanced tab (note that Edge Traversal is “blocked”)

clip_image010

5. Click the drop-down that indicates Block edge traversal, select Allow Edge traversal, then click OK

clip_image012

6. Repeat steps 3 through 5 for the remaining two Hyper-V rules.

Bear in mind that your remote Hyper-V parent still has to resolve your DA computer name to the IPv6 IP address that you’re using. This may require that you RDP to the Hyper-V host and edit the hosts file, but this doesn’t happen too often for me.  If you can ping your DA client from the Hyper-V host, name resolution isn’t the connectivity problem. You can check your DNS server on the intranet and confirm that the IPv6 address of the remote DirectAccess client is registered. If not, perform an ipconfig /registerdns on the remote DirectAccess client to register the IPv6 address.

Also, note that I described how to do this using the Windows Firewall with Advanced Security console on the DA client. If you want to enable remote management for multiple DA clients in your organization, you can use the Windows Firewall with Advanced Security snap-in in Group Policy and assign these Firewall Rules within Group Policy. This is a more scalable solution should you wish to enable Hyper-V

Let me know if this doesn’t work for you, but it’s working jes’ fine, jes’ fine for me.

AUTHOR:
Jim Harrison, Program Manager, Forefront TMG

REVIEWER:
Tom Shinder, Knowledge Engineer, ISD iX
UAG DirectAccess – Anywhere Access Group (AAG)

Comments

  • Anonymous
    April 29, 2012
    Awesome! Thanks... great article and helped me..

  • Anonymous
    September 09, 2015
    "Behave like unto thusly" - that's going to get used at work tomorrow...