Network Ports Related to Hyper-V

I firmly believe that Hyper-V is best implemented using Hyper-V Server and remote management techniques. Set it up once and never connect to its console again. With a bit of creativity, you can even deploy vendor-supplied firmware updates without accessing a local session. My approach does not enjoy community consensus; in fact, I’m unaware of any general agreement on the matter at all. One thing I do know for certain is that humans follow the path of least resistance. If option A is more difficult than option B, almost everyone will follow option B. Even people that take the hard road a few times at first will eventually fall back to the easy route, especially in times of distress.

With all of that said, I also firmly believe that digital security needs to be taken seriously. You may be in a low-security environment that doesn’t handle any sensitive information, but there is still a basic level of expected due diligence. Attackers are sometimes out to steal storage space and network bandwidth, not information. You have a responsibility to at least attempt to prevent that from happening. Even if you don’t feel like you owe to your current employer for whatever reason, you might want to work somewhere else someday. No prospective employer will be impressed if you have developed poor security habits.  Good security practice involves firewalls. Yes, they’re annoying when they inhibit legitimate traffic, but they are a simple and effective way to stop the most common assaults.

This article has two purposes. The first is to succinctly lay out the TCP/IP network ports information for Hyper-V management and activities. This allows you to configure firewalls as necessary. The second is to help you through some configuration dos and don’ts. This article might have information that helps you connect to workgroup-joined Hyper-V host, but it was not written with that usage in mind. I have not heard any compelling reason for that configuration to exist, therefore, I will not waste any further energy enabling it.

Inbound Hyper-V-Related TCP/IP Ports

The rules table below is used on 2012 R2 and should also apply to 2012. Every firewall configuration is a bit different. The following diagram gives a generalized idea of where you’ll be working:

Location of Firewall Rules

The above table should be mostly self-explanatory. There are a handful of notes:

• You probably don’t need to open all dynamic ports. I’ve only seen the first five or six ever actually being used. The problem is, if Microsoft has documented the true range of used ports anywhere, I have never found it. I only stumbled on the necessity to open the ports at all via netstat and Wireshark traces from failing connections. PSS didn’t even know about them.
• For the best outcomes, do not use any firewalls at all on cluster-only networks. The above will work, but (unscientifically), the Wireshark traces I’ve seen on cluster networks suggest that it uses other undocumented methods for communications that are likely more efficient. This would not apply to cluster-and-client networks such as the management network. Keep all of your cluster-only networks in the same layer-2 network with no routers, preferably in a VLAN or otherwise isolated network.
• “CNO” is cluster name object. Server Manager in particular wants to be able to talk to it. In reality, it maps directly to the management IP of the host that currently maintains the cluster core resources and as long as Server Manager can reach that, everything will be fine even if Server Manager is displeased. If you can ignore Server Manager’s complaints, so can I.
• “RDS” is “Remote Desktop Services”. I hope the clarification isn’t necessary, but this is for virtual machine RDS and not session-based RDS.
• Very few things have any need to use 5986 because WSMan traffic is always encrypted. Your host will only be listening on 5986 if you enable secure WSMan with a specially configured WinRM listener.

Outbound Hyper-V-Related TCP/IP Ports

Most institutions won’t block traffic outbound. However, you might need to use it to configure the inbound firewalls on other hosts. It’s also helpful if you have interim hardware firewalls. The rules are presented from the perspective of the following diagram:

Hyper-V-Related Outbound Firewall Rules

There isn’t much else to say with this table.

Other Hyper-V Related Traffic

Since I included port information for RDS, I might as well round it out with port information for RDS that doesn’t involve the hosts themselves. I’ll also include additional port information for System Center Virtual Machine Manager. While I’m at it, I’ll throw in some common ports just for the sake of completeness. I think the source/destination fields should be enough to help you figure out where to place these rules.

A few notes here:

• I didn’t include all of the VMM rules. A more comprehensive list is available on the TechNet wiki. My real complaint with that list is that it does not include source/destination information and not all of the rules are obvious. For instance, you do need the Hyper-V hosts to be able to talk to the SCVMM server on port 443.
• There is a similar TechNet wiki article for Remote Desktop Services, but the parts that aren’t difficult to sort out are just wrong and its overall state is such that, in good conscience, I cannot link it. Through some indirect channels, I have been left with the impression that the RDS team’s opinion on ever making that page useful or correct is “that’s not our job”. I have created the entries on these lists through Wireshark traces and observed trial and error. I can say that they have all worked just fine for me, but you might need to do some sleuthing of your own if you are doing some sort of configuration that I am not. PSS only has access to the same broken list so they will not be able to help you further, unless you don’t know how to use network traces or netstat to locate blocked ports.