Hello folks,
Your feedback is very important to the VMM team. Microsoft is listening to you. The requested features on the user’s voice for Virtual Machine Manager (VMM) are now available, deploying extended Hyper-V Port ACLs and support for Storage Spaces Tiering.
For the complete list of features that are included in Update Rollup 8, please check here. As you already know that deploying extended Port ACLs and Storage Spaces tiering in VMM was not possible.
The good news is, the Virtual Machine Manager (VMM) team has announced support to deploy extended Hyper-V Port ACLs and Storage Spaces Tiering in VMM 2012 R2 Update Rollup 8.
In today’s blog post, we will show you how to deploy and validate Hyper-V extended Port ACLs, and in the next post, we will walk you through how to deploy Storage Spaces Tiering in SCVMM.
For more information about Extended Port ACLs and how to deploy them natively in Hyper-V, please make sure to check my earlier post: Hyper-V Virtual Switch Extended Port ACLs in action.
After you install and verify Update Rollup 8 for Virtual Machine Manager, you can move to the below section:
Table of Contents
Hyper-V Extended Port ACLs in SCVMM
With the introduction of the VMM 2012 R2 UR8 update, administrators can now centrally create and manage port ACLs for their Tenant’s VMs.
What you can do with this Feature:
- Define ACLs & their ACL Rules.
- Attach the ACLs created to VM Networks, Subnets, or Virtual Network Adapters.
- Attach the ACL to a Global ACL for all Virtual Network Adapters.
- Verify ACL and ACL Rules.
- View & Update ACL Rules configured on the vNIC.
- Delete ACL Rules.
Each of these actions is covered in more detail below. Please note that this functionality is only exposed through PowerShell at the moment and will not reflect in the VMM Console UI. Please vote on the user’s voice if you want to manage Port ACLs in the VMM Console as well.
Defining new ACL & their Rules
You can now create ACLs & their ACL rules directly from within VMM using PowerShell. The PowerShell module for Virtual Machine Manager has been expanded with 8 new cmdlets.
The PowerShell cmdlet to create a New ACL is the following:
New-SCPortACL –Name <string> [–Description <string>] followed by name and description for the ACL. To define the ACL rules, you need to use New-SCPortACLRule
New-SCPortACLRule -PortACL <PortACL> -Name <string> -Action <Allow | Deny> -Type <Inbound | Outbound> -Priority <uint16> -Protocol <Tcp | Udp | Any> [-SourceAddressPrefix <string: IPAddress | IPSubnet>] [-SourcePortRange <string:X|X-Y|Any>] [-DestinationAddressPrefix <string: IPAddress | IPSubnet>] [-DestinationPortRange <string:X|X-Y|Any>] [-Description <string>]In this article, I will create a new ACL rule to allow HTTP traffic from all subnets, then limit RDP traffic only to a specific IP Subnet, and deny all other traffic.
New-SCPortACL –VMMServer SCVMM01 –Name DEMO-ACL01 –Description "Allow HTTP All, Limit RDP Access"
As you can see after you create a new ACL, the PortACLRules {} value is empty.
Next, we need to define ACL rules using New-SCPortACLRule –PortACL where <PortACL> is the new ACL created in the previous step.
$SCPortACL = Get-SCPortACL -VMMServer SCVMM01
New-SCPortACLRule -VMMServer SCVMM01 -Name "HTTPRule" -PortACL $SCPortACL -Description "Allow HTTP Rule" -Action Allow -Type Inbound -Priority 100 -Protocol Tcp -SourcePortRange 80 –Verbose
One important point to mention about Priority in VMM versus Weight in Hyper-V Port ACLs, If you checked my previous post about Hyper-V Virtual Switch Extended Port ACLs in action, you will notice that the higher Weight value will take precedence, however in VMM the lower Priority value will take precedence.
Next, we need to allow RDP access from a specific MGMT subnet.
New-SCPortACLRule -VMMServer SCVMM01 -Name "RDPRule" -PortACL $SCPortACL -Description "Allow RDP Rule From MGMT Subnet" -Action Allow -Type Inbound -Priority 110 -Protocol Tcp -SourcePortRange 3389 -DestinationAddressPrefix 172.16.20.0/24 –Verbose
Next, we need to allow DNS/AD access for all subnets.
New-SCPortACLRule -VMMServer SCVMM01 -Name "ADDNS-Rule" -PortACL $SCPortACL -Description "Allow AD/DNS Rule" -Action Allow -Type Inbound -Priority 115 -Protocol Any -DestinationAddressPrefix 172.16.20.9 -Verbose
Last but not least, we will deny all remaining traffic.
New-SCPortACLRule -VMMServer SCVMM01 -Name "DenyALL" -PortACL $SCPortACL -Description "Deny All Rule" -Action Deny -Type Inbound -Priority 120 -Protocol Any -SourcePortRange Any –Verbose
If you run, Get-SCPortACL you will see four ACL rules that have been added to the ACL.
Attaching Port ACLs
After defining the new ACL and their rules, we need to attach them, Port ACLs can be attached to a VM Network (for No-Isolation type only) or to a VM Subnet (Hyper-V Network Virtualization HNV, VLAN, and External isolation type) and/or to (Virtual Network Adapters). ACL to VM Network/Subnet is a 1:1 relationship. However, one ACL can be attached to multiple Virtual Network Adapters. You can attach the new ACL using the below Powershell cmdlets for each type:
VM Network (only No Isolation type VM Network):
New-SCVMNetwork –PortACL <NetworkAccessControlList> [Rest-of-the-parameters]
Set-SCVMNetwork –PortACL <NetworkAccessControlList> –RemoveNetworkAccessControlList [Rest-of-the-parameters]These rules will be applied to all VM virtual network adapters connected to this network.
VM Subnet (only VM Subnets – Hyper-V Network Virtualization HNV, VLAN, and External):
New-SCVMSubnet –PortACL <NetworkAccessControlList> [Rest-of-the-parameters]
Set-SCVMSubnet –PortACL <NetworkAccessControlList> –RemoveNetworkAccessControlList [Rest-of-the-parameters]These rules will be applied to all VM virtual network adapters connected to this Subnet.
Virtual Network Adapter (includes Host vNIC and vmNICs in both cmdlets):
New-SCVirtualNetworkAdapter –PortACL <NetworkAccessControlList> [Rest-of-the-parameters]
Set-SCVirtualNetworkAdapter –PortACL <NetworkAccessControlList> –RemoveNetworkAccessControlList [Rest-of-the-parameters]These rules can be attached to multiple Virtual Network Adapters including Host vNIC if you are using Converged Network Fabric in VMM
In this demo, I will attach the new ACL to VM Network (No Isolation), so the ACL rule will be applied to all Virtual Machines vmNICs connected to this network.
I will attach the newly created ACL using Set-SCVMNetwork because the VM Network exists in my environment, then followed by the parameter <PortACL> which is the new ACL created in the previous step.
$SCPortACL = Get-SCPortACL -VMMServer SCVMM01
$SCVMNetwork = Get-SCVMNetwork | where {$_.Name –eq "Corp VM Network"}
Set-SCVMNetwork -VMMServer SCVMM01 -PortACL $SCPortACL -VMNetwork $SCVMNetwork –Verbose
To confirm if the ACL is attached to VM Network, you can use Get-SCVMNetwork:
Get-SCVMNetwork | Where {$_.Name -eq "Corp VM Network"} | FL Name, IsolationType, PortACL
Verify ACL and ACL Rules
Now in order to verify and test the ACL and ACL rules that are being applied to the Virtual Machines’ virtual network adapters connected to the VM network, you need to refresh the VM and then remediate the vmNICs in VMM Admin Console.
After you refresh the VM, click on the Fabric Node and then click on Virtual Machines in the Ribbon. Select the virtual adapter that you applied the ACL to, you should see the Network Compliance show up as “Not Compliant“. When the adapter is in this state, the Remediate button should be enabled. Click it and the ACL should take effect at this time.
Let’s remediate all adapters and then test the ACL.
After you remediate the vmNIC adapter, you can verify the Extended Port ACL by accessing the Hyper-V host and running (Get-VMNetworkAdapterExtendedAcl)
As you can see the ACL rules are applied, please remember the Weight in Hyper-V Port ACLs (a higher value will take precedence!).
Let’s see this in action!
As you can see Ping failed, however HTTP on port 80 is reachable.
The next test is to check RDP access from the management VLAN.
RDP is accessible from the management subnet.
Now let’s check RDP access from a different subnet.
And finally, let’s check other types of traffic…
Fantastic! everything is working as expected.
Viewing ACL Rules
To view the ACLs & ACL Rules, you can use the following PowerShell cmdlets:
Get-SCPortACL
ParamSet 1: All/By Name
Get-SCPortACL [-Name <>]
ParamSet 2: By id
Get-SCPortACL -Id <> [-Name <>]
Get-SCPortACLRule
ParamSet 1: All/By Name
Get-SCPortACLRule [-Name <>]
ParamSet 2: By id
Get-SCPortACLRule -Id <>
ParamSet 3: By AccessControlListId
Get-SCPortACLRule –PortACL <NetworkAccessControlList>
Updating ACL Rules
When you update the ACL attached to virtual network adapters, the changes are reflected in all the network adapter instances using that ACL. For an ACL attached to a VM Subnet or VM Network, all the network adapter instances connected to that subnet/network are updated with the new changes.
Note: The task of updating ACL Rules “physically” on individual network adapters is done in parallel in a one-try best-effort scheme – for those that can’t be updated for any reason are marked “security incompliant” but the task finishes successfully with an error message stating the network adapters that were not updated successfully. Security incompliant here refers to compliance errors on a virtual network adapter due to a mismatch in expected vs actual ACL rules. As per the existing model, the adapter has a compliance state of “Not compliant” along with relevant error messages.
To update an ACL rule, we need to use Set-SCPortACLRule
Set-SCPortACLRule [-PortACLRule] <PortACLRule> [[-Description] <string>] [-Type <PortACLRuleDirection> {Inbound | Outbound}] [-Action <PortACLRuleAction> {Allow | Deny}] [-SourceAddressPrefix <string>] [-SourcePortRange <string>] [-DestinationAddressPrefix <string>] [-DestinationPortRange <string>] [-Protocol <PortACLRuleProtocol> {Tcp | Udp | Any}]I will update the “DenyAllInbound” rule to deny only a specific IP subnet.
Set-SCPortACLRule -PortACLRule $SCPortACLRule -DestinationAddressPrefix 172.16.20.0/24
Deleting ACL & ACL Rules
An ACL can only be deleted if there are no other dependencies attached to it. Dependencies include VMNetwork/VMSubnet/VMNetworkAdapter/GlobalPortACL attached to the ACL. When you try to delete a PortACL using the PowerShell cmdlet it will detect if the PortACL is attached to any of the dependencies and will throw appropriate error messages.
Note that deleting a VM subnet/network adapter automatically removes the association with that ACL. An ACL can also be dis-associated from the subnet/network adapter by modifying the subnet/network adapter.
PowerShell cmdlet to delete an ACL:
Remove-SCPortACL -PortACL <NetworkAccessControlList>PowerShell cmdlet to delete an ACL rule:
Remove-SCPortACLRule -PortACLRule <NetworkAccessControlListRule>
Out-Of-Band Changes to ACL Rules
If you are doing Out of Band (OOB) changes to ACL Rules from the Hyper-V vSwitch side, VM Refresh in VMM will show the NIC as “Security Incompliant“. The Network Adapter can then be repaired from VMM using the below PowerShell Cmdlet. However, remediation will overwrite all the Rules done from the Hyper-V side with the rules as expected by VMM!
Repair-SCVirtualNetworkAdapter - VirtualNetworkAdapter <VirtualNetworkAdapter>That’s it there you have it!
You can read more about the Update Rollup 8 for System Center Virtual Machine Manager here.
Until then… see you in the next post!
Cheers,
-Charbel
