You dont have javascript enabled! Please enable it!

Hyper-V Virtual Switch Extended Port ACLs In Action

4 Min. Read

Hello Folks,

In today’s post, we will deep dive into Extended Port Access Lists in Hyper-V 2012 R2 and later versions.

For those who are new to this feature, Port ACL is a rule that you can apply to a Hyper-V virtual switch (Per VM or Per Virtual Network Adapter).
The rule specifies whether a packet is allowed or denied on the way into or out of the VM. ACLs in Hyper-V 2012 has three elements only with the following structure: Local or Remote Address | Direction | Action. This allows controlling traffic between VMs or between VMs and the physical world.

Starting in Hyper-V 2012 R2 and later versions, the Hyper-V team extended that feature and now you can configure port ACLs for a VM based on five attributes in a packet – Source IP, Destination IP, Protocol, Source Port, and Destination Port.

For example, you can configure port ACLs for a VM to allow all incoming and outgoing HTTP traffic on port 80 while blocking the network traffic of all other protocols on all ports.

Let’s see this networking feature in Action…

Here is our scenario environment for this demo:

HV Extended ACL

Note: To configure port ACL, we need to use PowerShell folks, NO GUI :)

So Let’s get started…

First, we need to check the connectivity from all users’ machines (Between VM and the External World) using the new SuperPing cmdlet…

#From Account Users:



Connection is succeeded to both Virtual Machines as expected, the Account Server is a Web Server listening on port 80 and the RemoteApp Server is an RDS Session Host listening on port 3389…

#From Front Desk Users:



The connection is good as well as from the Front Desk users subnet, sure enough, the RDS-RemoteAppSRV VM is failing to connect on port 80 since it’s not a Web Server.

Second, we need to check the connectivity between Virtual Machines on the same physical host…

#From Account-AppSRV:


#From RDS-RemoteAppSRV:


As you can see the connectivity is True between the two VMs as well.

Based on our scenario described above, here are our security policies that we need to enforce:

Rule #1:

  • The Account Users must be able to access the Account WebServer using HTTP only
  • The Account Users must not able to access the RemoteApp Server at all

Rule #2:

  • The Front Desk Users must be able to access the RemoteApp Server using RDP only
  • The Front Desk Users must not able to access the Account WebServer at all

Rule #3:

  • The Account Server must not able to access the RemoteApp Server using RDP Protocol and vice versa
  • The RemoteApp Server must not be able to access the Account WebServer using HTTP

So let’s start applying those security policies and see the results…

Here we are on our Hyper-V box:

First, we need to check if we have any pre-existing Access Rule applied:


No Rules….

If you are a networking or Cisco guy, this might look familiar to you, like a kind of PowerShell version of an ACL command line :)

1- Add-VMNetworkAdapterExtendedAcl –VMName "ACCOUNT-APPSRV" –Action "Deny" –Direction "Inbound" –Weight 1

2-  Add-VMNetworkAdapterExtendedAcl –VMName "RDS-RemoteAppSRV" –Action "Deny" –Direction "Inbound" –Weight 1

3- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress –Weight 20

4- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress –Weight 30

5- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress –Weight 40

6- Add-VMNetworkAdapterExtendedAcl –VMName “RDS-RemoteAppSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress –Weight 20

7-  Add-VMNetworkAdapterExtendedAcl –VMName “RDS-RemoteAppSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress –Weight 30

8- Add-VMNetworkAdapterExtendedAcl –VMName “RDS-RemoteAppSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress –Weight 40

9- Add-VMNetworkAdapterExtendedAcl –VMName “ACCOUNT-APPSRV” –Action “Allow” –Direction "Inbound" –RemoteIPAddress –LocalPort 80 –Protocol "TCP" –Weight 100 -Stateful $True

10- Add-VMNetworkAdapterExtendedAcl –VMName "RDS-RemoteAppSRV" –Action "Allow" –Direction "Inbound" –RemoteIPAddress –LocalPort 3389 –Protocol "TCP" –Weight 100 -Stateful $True

Let’s explain the above commands in a nutshell.

The Add-VMNetworkAdapterExtendedAcl cmdlet creates an extended access control list (ACL) for a VM virtual network adapter. The ACL allows or denies access to a virtual machine network adapter for network packets based on source IP address, destination IP address, protocol, source port, and destination port.

The first two commands deny all inbound traffic for both VMs. The third to the eighth rule allows traffic between the Virtual Machines and our DNS Server/Gateway in order to communicate with our Active Directory and to route between different subnets as well.

Notice that all commands have a weight number and the last command has a weight of 100. Commands with higher weight take precedence (weight of 100 takes precedence over a weight of 40, 30, 20, and 1).

The last two rules are to allow the Account Users subnet to connect to the Account-AppSRV VM using HTTP protocol and to allow the Front Desk Users to connect to the RDS-RemoteAppSRV VM using RDP protocol.

Note: If we are applying the rule in the Outbound direction, we need to use RemotePort instead of LocalPort.

Let’s check now the connectivity after applying the above rules:

#From Account Users:



As you can see, the Account Users are able to access the Account Web Server using HTTP, but nothing else and they cannot reach the RDS RemoteApp server too.

#From Front Desk Users:



Here the Front Desk users are not able to reach the Account Web Server, but they can connect to the RDS RemoteApp server only.

#From Account-AppSRV:


No connectivity between the Account-AppSRV and the RDS-RemoteAppSRV as expected :)

#From RDS-RemoteAppSRV:


No connectivity as well from the RDS-RemoteAppSRV and the Account-AppSRV… Bingo!

The other piece that we have with Extended ACL is Stateful support, like a stateful firewall.

We can say, when we see an inbound connection coming on port 80, it will watch that inbound connection and automatically open the source port on the other side just for a period of time that’s needed to communicate through that inbound session.

We can associate timeouts with that Stateful session as well, so after a certain period of time, we can close that Stateful connection using the -Timeout flag value defined in seconds.

Here you can read more on Microsoft TechNet about Extended Port Access Control Lists in Hyper-V 2012 R2

Until this point in time, the Hyper-V Extensible switch cannot do a traffic inspection of the payload, but that’s why the big role of the Extensible Virtual Switch comes into play with Cisco NEXUS 1000V, NEC, or Five9 partners…

Until next time… Enjoy your Weekend!



Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect, Swiss Certified ICT Security Expert, Certified Cloud Security Professional (CCSP), Certified Information Security Manager (CISM), Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT). He has over 20 years of broad IT experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems with extensive practical knowledge of complex systems build, network design, business continuity, and cloud security.

Related Posts


Virtual Machine Migration Failed at Migration Source… Could not get VHD GUID!

Monitor Hyper-V Server with Perfmon View


Let me know what you think, or ask a question...

error: Alert: The content of this website is copyrighted from being plagiarized! You can copy from the \'Code Blocks\' in \'Black\' by selecting the Code. Thank You!