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

Location of Firewall Rules

Hyper-V Host Inbound Rules
Port Target Source Purpose
All dynamic ports (49152-65535) Management IP; CNO Management servers and stations; RDS broker Server Manager and other tools that use Remote Procedure Call
80 Management IP Other Hyper-V hosts that can replicate to this host Hyper-V Replica (only if using insecure traffic)
135 Management IP Management servers and stations; RDS broker RPC Endpoint Mapper (sometimes for WMI as well)
443 Management IP Other Hyper-V hosts that can replicate to this host; VMM servers Hyper-V Replica (only if using secure traffic) and System Center VMM
445 Management IP and Cluster IPs; Live Migration IPs if using SMB mode Management servers and stations that would copy files to this host; members of the same cluster; Live Migration sources if using SMB mode; RDS broker Inbound file copy; cluster communications; Cluster Shared Volumes redirected access; Live Migration if using SMB mode
2179 Management IP; CNO Management servers and stations; RDS broker Communication to Virtual Machine Management Service
TCP & UDP 3389 Management IP Management stations Console access
5985 Management IP Management servers and stations; RDS broker WSMan and WMI; notably used by PowerShell Remoting
5986 Management IP Management servers and stations; SCVMM Secure WSMan and WMI
6600 Live Migration IPs Other Hyper-V hosts that can Live Migrate to this host Live Migration when using standard TCP or compressed TCP modes

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

Hyper-V-Related Outbound Firewall Rules

Hyper-V Host Outbound Rules
Port Target Source Purpose
All dynamic ports (49152-65535) Management IP of other Hyper-V hosts; RDS broker Management IP Server Manager and other tools that use Remote Procedure Call if you will manage one host from another; RDS broker if using RDS
80 Other Hyper-V hosts that this host will replicate to Management IP Hyper-V Replica (only if using insecure traffic)
135 Management IP Management servers and stations; RDS broker RPC Endpoint Mapper (sometimes for WMI as well)
443 Other Hyper-V hosts that this host will replicate to; SCVMM Management IP Hyper-V Replica (only if using secure traffic) and System Center VMM
445 SMB 3 systems that present VM storage to this host; SMB 2+ targets with files this host needs to access, such as ISO; SCVMM library hosts; Live Migration target hosts if using SMB; other members of the same cluster; RDS broker Management IPs; cluster network IPs; RDS User Profile Disk share File copy; SMB access; Live Migrations in SMB mode; cluster communications; Cluster Shared Volume communications; RDS UPD host
3260 iSCSI Portals and Targets iSCSI discovery and initiator IPs iSCSI
6600 Other hosts this machine can Live Migrate to Live Migration IPs Live Migration when using standard TCP or compressed TCP modes

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.

Other Hyper-V Firewall Rules
Port Target Source Purpose
All dynamic ports (49152-65535) All RDS hosts besides RDS broker RDS broker Server Manager and other tools that use Remote Procedure Call — the RDS broker is a central management hub
TCP/UDP 53 DNS servers Everyone DNS lookups
80 RDS Clients RDS web VDI’s web access is a standard IIS site
389 Domain Controllers Domain members Standard AD authentication
443 RDS Clients RDS web VDI’s web access is a standard IIS site
443 RDS Gateway RDS Clients Client-to-gateway connections handled via 443
443 RDS virtual machines RDS Clients If gateway is not used, clients authenticate directly to their own VMs on 443
686 Domain Controllers Domain members AD authentication using LDAPS; secure authentication is now also available on the 389 port
3389 RDS virtual machines in unmanaged pools RDS Broker Client-to-VM connectivity
3389 RDS Broker RDS Gateway Gateway facilitating of client-to-VM connectivity
3389 RDS virtual machines RDS Clients If an RDS gateway is not used, everyone is connected directly to his or her VDI virtual machine
UDP 3391 Same rules as 3389 Same rules as 3389 When this transport is enabled, higher-performing UDP is used for the connection. Duplicate all of the port 3389 rules to UDP 3391.
5504 RDS Broker RDS Web Hand-off from web authenticator to the RDS broker
5985 RDS Gateway RDS Broker RDS Broker control of RDS Gateway
8100 SCVMM Management stations Connect VMM console to VMM server service
8530 (default) Windows Server Update Services hosts All Windows/Windows Server/Hyper-v Server Windows Updates; may be configured to use another port

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.

 

Is Your Office 365 Data Secure?

Did you know Microsoft does not back up Office 365 data? Most people assume their emails, contacts and calendar events are saved somewhere but they're not. Secure your Office 365 data today using Altaro Office 365 Backup - the reliable and cost-effective mailbox backup, recovery and backup storage solution for companies and MSPs

Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

8 thoughts on "Network Ports Related to Hyper-V"

  • Bruno says:

    Hello,

    This is a very nice explanation. It would be great if you can post another step-by-step article concerning on how to configure a new Hyper-V host joined to an existing workgroup and of course how to connect and remotely manage this because this is very hard to find…

    Thanks in advance

    • Eric Siron says:

      Sorry, Bruno, but I am no longer providing support for Hyper-V hosts in workgroup configuration. It goes beyond firewall ports because you must reduce the security on your hosts below the already poor level of workgroup mode. I have seen a number of posts by authors that describe how to cripple your systems enough for remote management, so I know the how-tos are out there.

  • Bruno says:

    Hello,

    This is a very nice explanation. It would be great if you can post another step-by-step article concerning on how to configure a new Hyper-V host joined to an existing workgroup and of course how to connect and remotely manage this because this is very hard to find…

    Thanks in advance

  • Bruno says:

    Hi Eric,

    I know but more and more clients just want one physical machine and you need to manage it before you can setup a vm with domain controller. Some company’s also dont need a domain anymore. Thats why it should be handy.

    Bruno

    • Eric Siron says:

      I’m struggling to envision the existence of a company small enough that they do not need a domain controller but large enough to need to have a management workstation. Anyone small enough that peer-to-peer networking is sufficient should also have no serious barriers to managing their environment via RDP. I cannot condone the security changes necessary to facilitate remote Hyper-V management. But, as I said, there are lots of other authors with no such compunctions and they are easy to find. I do not believe that I am robbing the world of anything by leaving such matters to the less scrupulous.

  • Bruno says:

    Hi Eric,

    I know but more and more clients just want one physical machine and you need to manage it before you can setup a vm with domain controller. Some company’s also dont need a domain anymore. Thats why it should be handy.

    Bruno

  • […] [Network Ports Related to Hyper-V]http://www.altaro.com/hyper-v/network-ports-related-hyper-v/ […]

  • […] [Network Ports Related to Hyper-V]https://www.altaro.com/hyper-v/network-ports-related-hyper-v/ […]

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published. Required fields are marked *

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.

Related posts