Hyper-V Virtual Switch Extended Port ACL’s In Action

Hello Folks,

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

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 have three elements only with the following structure: Local or Remote Address | Direction | Action. This allows to control traffic between VMs or between VMs and the physical world.

In Hyper-V 2012 R2 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 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 machine (Between VM and the External World) using the new SuperPing cmdlet…

#From Account Users:

PortACL01

PortACL02

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:

PortACL03

PortACL04

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:

PortACL05

#From RDS-RemoteAppSRV:

PortACL06

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 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 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 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:

PortACL07

No Rules….

If you are a networking or Cisco guy, this might look familiar to you, like 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 172.16.20.9 –Weight 20

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

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

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

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

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

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

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

Let’s explain 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 denies all inbound traffic for both VMs. The third to 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 (a weight of 100 takes precedence over a weight of 40, 30, 20 and 1).

The last two rules, is 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 Outbound direction, we need to use RemotePort instead of LocalPort.

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

#From Account Users:

PortACL08

PortACL10

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:

PortACL09

PortACL11

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:

PortACL12

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

#From RDS-RemoteAppSRV:

PortACL13

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 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 of time, the Hyper-V Extensible switch cannot do 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!

Cheers,

Charbel

About Charbel Nemnom 310 Articles
Charbel Nemnom is a Microsoft Cloud Consultant and Technical Evangelist, totally fan of the latest's IT platform solutions, accomplished hands-on technical professional with over 15 years of broad IT Infrastructure experience serving on and guiding technical teams to optimize performance of mission-critical enterprise systems. Excellent communicator adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative IT project development. Well respected by peers through demonstrating passion for technology and performance improvement. Extensive practical knowledge of complex systems builds, network design and virtualization.

Be the first to comment

Leave a Reply