When you decouple the user from the physical hardware that sits on their desk, you provide new opportunities to change the way they work because they are no longer tethered to their desk. If you can provide secure remote access to their desktop, they are no longer tied to their VPN connection or corporate laptop.
Horizon View provides a secure method for granting users access to their desktops from anywhere with an Internet connection on any device without needing a VPN connection. Now that a desktop pool has been set up and desktops are provisioned, it’s time to set up that remote access.
The Security Server
The View Security Server is VMware’s original method of addressing remote access. This component of the Horizon View environment contains a subset of the Connection Server components, and it is designed to sit in a DMZ and act as a gateway for Horizon View Clients. It’s essentially a reverse proxy for your View environment.
Each Security Server that is deployed needs a corresponding Connection Server, and they are paired during the installation process. Because the Security Server is an optional component, each Connection Server is not required to have one, and a Connection Server cannot be paired to more than one Security Server.
Each Security Server also needs a static IP address. If it is externally facing, it will need to have a publicly addressable static IP. This IP address does not need to be configured on the server’s network card as both Static 1:1 NAT and PAT work with Horizon View.
Since the Security Server is built on a subset of Connection Server components, it requires a Windows Server-based operating system. This may require putting Windows servers into a DMZ network, and this can present some security and management challenges.
Security Server Alternatives
There are two alternatives for providing remote access to Horizon environments if you don’t want to place Windows servers into a DMZ environment. These two alternatives are the Horizon Access Point, a hardened purpose-built remote access appliance for Horizon and Airwatch, and the F5 Access Policy Manager for Horizon.
The Horizon Access Point was officially released for Horizon environments with Horizon 6.2.2, and it has received new features and improvements with every major and minor Horizon release since. In addition to being a Security Server replacement, it can also act as a reverse proxy for VIDM and as endpoint for Airwatch Tunnels to connect on-premises services with a cloud-hosted Airwatch environment. The Access Point is designed to be disposable. When the Access Point needs an upgrade, settings change (such as a certificate replacement), or breaks, the appliance is meant to be discarded and a new one deployed in its place. The Access Point also has no management interface. It does have a REST API that can be used to view configuration details and monitor the number of connections that are connecting through the Access Point.
The F5 Access Policy Manager is a feature of the F5 Application Delivery Controller. Access Policy Manager provides context-aware secure remote access to applications and other resources. One of the feature of APM is a Horizon Proxy. The Horizon Proxy can authenticate users to the Horizon environment and handle both PCoIP and Blast connections. F5 APM is configured using a Horizon iApp Rule – a template with all of the F5 rules required for Horizon and a graphical interface for configuring it to your particular environment. The APM feature is licensed separately from other F5 features, and there is an additional cost for F5 APM licensing.
The table below outlines the features of the Security Server, Access Point, and F5 APM.
|Access Point||F5 Access Policy Module|
|Platform||Windows Server||Virtual Appliance||Physical or virtual Appliance|
|Protocol Support||PCoIP, Blast Extreme||PCoIP, Blast Extreme||PCoIP, Blast Extreme|
|Interaction with Horizon||Paired with Connection Servers||HTTPS connection to load-balanced Connection Servers||HTTPS connection to pool of connection servers|
|Two-Factor Auth Support||Handled by Connection Servers||RSA, Radius-Based||RSA, Radius-Based|
Security Server Firewall Ports
In order to enable remote access, a few ports need to be opened on any firewalls that sit between the network where the Security Server has been deployed and the Internet. If the server is deployed into a DMZ, the firewall will also need to allow traffic between the Security Server and the Connection Server.
The rules that are required on the front-end, Internet-facing firewall are:
- HTTP – TCP 80 In
- HTTPS – TCP 443 In
- HTTPS – UDP 443 In (for Blast Extreme UDP Connections)
- HTTPS – TCP 8443 both directions (if Blast is used with the Security Server)
- PCoIP – TCP 4172 In, UDP 4172 both directions
Backend firewall rules between the remote access solution and the Horizon Connection Servers and desktops depends on the remote access solution being configured. The following table outlines the ports that need to be opened between the DMZ and internal networks.
|443 TCP||HTTPS||DMZ –Connection Servers||Access Point only|
|4172 TCP/UDP||PCoIP||DMZ to Virtual Desktop Subnets|
|22443 TCP/UDP||Blast||DMZ to Virtual Desktop Subnets|
|9427 TCP||Client Drive Redirection/MMR||DMZ to Virtual Desktop Subnets|
|500 UDP||IPSec||DMZ to Connection Servers||Security Server Only|
|4500 UDP||NAT-T ISAKMP||DMZ to Connection Servers||Security Server Only|
If you are deploying your Security Servers in a DMZ configuration with a back-end firewall, you need to configure your firewall to allow IPSEC traffic to the Connection Servers. These rules depend on whether network address translation is used between the DMZ and Internal network. For more information on the rules that need to be enabled, please see this VMware KB article.
Note: If you’re using application-aware firewalls like Palo Alto Networks devices, make sure that any application protocols required by Horizon View aren’t blocked between the DMZ and Internal network. Also, updates to the application signatures or the PCoIP protocol may impact users’ access to virtual desktops.
So Which Should I Use?
The million dollar question when deploying a brand new Horizon environment is: which remote access method should I use? The answer is “whichever one fits your needs the best.” When designing remote access solutions for Horizon, it is important to understand the tradeoffs of using the different options and to evaluate options during the pilot phase of the project.
If possible, I would recommend staying away from the Security Server now that there are other options for remote access. I don’t recommend this for many clients because the Access Point has feature parity with the Security Server, and it avoids the security and management hassles of deploying Windows Servers into an organization’s DMZ network.