We fortunately see a lot more NSX with EUC deployments. Used for microsegmentation of the virtual desktop infrastructure, virtual desktop security protection and load balancing of the workspace components (see my previous post here: https://www.pascalswereld.nl/2017/06/09/euc-layers-horizon-connectivity-from-nsx-load-balancers-with-love/).

I want to focus a bit on the microsegmentation and mainly on the NSX service profiles, groups and standard set of rules for EUC with VMware Horizon. Currently neither NSX for Desktop as Horizon ships with a prepared set to use. Well the Horizon suite does not ship with NSX in any form, what is still a miss in my humble opinion. It can be a little difficult I know.

This blog post will try to focus on the expected to be part of your desktop environment and Horizon components and their NSX rules. Focussing on static Horizon services, static Infrastructure services and dynamic applications based on group membership. And using a fling to get them in your environment. I also have added more services and rules to the fling configuration file, and put up a github project to manage these changes. You can download an updated yml file from there, details a little later on so do read or scroll ahead ;). This is a work in progress as I am also just working on it in my current project.

I think we EUC consultants all seen and know the Horizon 7 network ports diagram. If not you can get it here https://www.vmware.com/techpapers/2015/vmware-horizon-7-network-ports-diagram-10492.html. I know that part of the component and rules depend on how the infrastructure, applications and choices on (security) requirements will influence your environment and data flows. However the dynamics are more about choices whether there be components like Unified Access Gateways, Identity Manager, App Volumes, Connection Servers, Composers and virtual desktop agents in the environment and how they must be connected. And also infrastructure components, for example Active Directory, DNS, NTP and more of these. The dynamic part will be most of the time unknown application rules, and how they will be handled. They will be set in a project phase approach when staging applications to your environment. Get the information from the vendor, and/or analyse the flows with Network Insight or firewall forwarded logs. This is a whole different ballpark with decisions on process and procedures as well. The application part will for now be kept out of this blog post.

Lets start, what is already there?

Lets do a current state analysis on getting the rule set. Do we have something from the community or previous projects? Unfortunately there is not that much. If you have from a previous project, great use them. If not, we can turn to flings. And yes here we can use the Horizon Service Installer to jump-start the rule set. Download here: https://labs.vmware.com/flings/horizon-service-installer-for-nsx.

This fling is a batch script that calls a java application that in turn inserts Horizon services into NSX Manager. Furthermore the application combines these services into Horizon service groups for all the well-known Horizon, App Volumes, Identity Manager, Access Point and vROPS for Horizon services. It will also create empty security groups for desktops and Horizon components (Horizon only, not for example App Volumes. we will come back to this later in this blog post), and will add firewall rules for communication to and from these Horizon components.

The fling will add the following NSX Distributed Firewall Rules for the Horizon environment:

Reject desktop between desktop communication

Allow communication to desktops

Allow communication between connection servers

Allow communication to connection servers

Allow communication to security servers

Allow communication to composer servers

Allow communication to Enrollment servers

The service groups are empty and an administrator can decide what kind of objects are added. In a very simple deployment, add the virtual machine connection servers to the connection server security group and change the dynamic membership to add all of the desktops in the desktop security group based on the desktop pool prefix.

This simplifies the creation of NSX based Horizon network infrastructure, that can be used to protect both Horizon infrastructure and hosted desktops and applications.

How we use the fling?

Download the fling from: https://labs.vmware.com/flings/horizon-service-installer-for-nsx. Unzip on a Windows 7/10/2012R2 system with Java runtime 1.6 or above installed. And of course we need an installed and licensed NSX Manager.

Unzip the downloaded file on the server/desktop. Change JAVA_HOME in the install.bat to the location of JRE on the Windows system. Open a command prompt and go to the extracted location. Run install.bat Enter https://FQDN or IP of the NSX Manager. Login with username and password (with permissions). Do note that the password is plaintext on-screen. Trust the certificate when prompted by typing Yes. Sit back and let the script add the stuff.

And in NSX things will look like:

Note: please do note the Default rule which is added in the section, need to trash that one.

Pretty awesome! Next you will need to decide on how to add components to the groups.

Note: When changing the yml file and pushing the configuration to an already existing Horizon service, do take care that not all components will be checked if already existing. Services and security groups will be checked and only added when not existing (not changing existing ones though. Service groups and firewall rules will be added no matter what is already in place.

Note: the succeed output in the script will not always be the same as the rule is actually added.

Note: When using multiple sources or destination use double quotes and separate with a comma and end with double quotes. For example:

source : “App Volumes Manager,VMware Identity Manager,vSphere vCenter – Hosts”

Edited and added services

I have added some Horizon services like connections to vCenter/vSphere, App Volumes and added common infrastructure services and rules. You can download the updated yml file on Github, find it here https://github.com/Paikke/NSXHorizonJumpstart. If you miss something please comment below or on Github and I will add this to the file(s).

This rules are focussed on the desktop block in a zero trust model (default should be deny any any) where other network zones might or might not trust the desktop zone. But that is a bit up to the organizations and complexity.

What is edited in the Horizon Services:

I have edited the names of the desktops, connection servers, composer.

I have added UAG for external connection as these are more often used than Security servers.

I have added more sources instead of the large amount of any.

What is added:

vCenter and vSphere communication (TCP 443, 902 UDP 902)

File Repository Shares (TCP 445)

Active Directory LDAP (TCP 389/636)

Database MSSQL (TCP1433)

DHCP (UDP 67/68)

DNS (UDP 53/TCP 53)

NTP (UDP 123)

Take a peek at these rules inserted in NSX manager:

Important note: this is a work in progress and I will try to update the couple of weeks while I’m working at this to get it running a staging/test environment. Just the same goes for this set of rules as VMware Flings, use with caution and test test test before going anywhere near what some call production.

– Happy using NSX for Desktop in your EUC solution!

Sources: vmware.com