Mark Benson - View Architect - VMware End User Computing CTO Office
View Security Server is a component of View that is typically deployed in a DMZ to support remote access to virtual desktops. When accessing desktops from the Internet, such as by the home or mobile worker, Security Server provides the required level of security and connectivity. It ensures that the only remote desktop traffic that can enter the corporate data center is traffic on behalf of a strongly authenticated user. It also ensures that the user can only access desktop resources they are authorized to access.
In View 4.5 and earlier, Security Server supports the secure tunnelling of TCP based protocols (such as RDP, USB redirection etc.). PCoIP is an advanced remote desktop protocol and makes more efficient use of the network by encapsulating video display packets in UDP instead of TCP. To read more about the benefits of PCoIP and UDP for remote display protocols, see Scott Davis’s post on Why PCoIP is Ideal for Remote Virtual Desktops. This means that currently, PCoIP can only be used with View on an internal network or when users have a VPN connection to the corporate data center. Remote View users without VPN access are restricted to using RDP.
I thought I’d share with you what VMware is doing about this.
We initially looked at various options around tunneling the PCoIP traffic through Security Server but we really didn’t want to interfere with the advanced performance characteristics of the protocol. The step improvement in having a UDP based remote display protocol would be somewhat eroded if we just tunneled that over an HTTPS connection which uses TCP as its underlying transport protocol. HTTPS encapsulation is good for RDP, but PCoIP is already secured by AES-128 encryption over the wire and so double encryption is unnecessary. We also wanted to ensure we will support existing PCoIP based View clients, newer clients such as Wireless and 3G enabled iPad etc., and third party clients based on the Teradici zero client in a really easy and intuitive way. It was clear that customers want the same security, connectivity and ease of administration benefits from Security Server that they are used to for RDP and other TCP based protocols, but also want to maximize the user experience with PCoIP for the remote access case.
The answer was to support a PCoIP protocol gateway on the Security Server and tie this into the strict authentication, authorization and session controls from View. We have undertaken a joint development with Teradici on this and we’re currently conducting internal QA and high volume performance testing and beta trialing this with some “early adopter” customers now. This will be an upgrade to View Security Server and View Connection Server. Security Server with PCoIP support runs on Windows Server 2008 R2 and takes full advantage of the 64-bit architecture. This Security Server upgrade can also take advantage of Intel processors that support AES New Instructions (AESNI) for highly optimized PCoIP encryption and decryption performance.
It is necessary to open up the Internet facing firewall for PCoIP to get the benefits of native AES-128 encrypted PCoIP performance over the WAN. This is TCP port 4172 in and UDP port 4172 in both directions. In gateway mode, when the Connection Server gives the destination IP address and port numbers for PCoIP to the View Client at desktop launch time, the addresses are for the Security Server and not the virtual desktop. This ensures all PCoIP communication is routed through the Security Server. This is shown in the following diagram.
The Security Server verifies the PCoIP traffic and if the user is authorized, forwards it to the appropriate virtual desktop.
The focus of the beta trials of this in real life situations has been to look at places where this approach works and where it doesn’t. We wanted to test it in situations where there are complex NAT setups, public wi-fi hotspots, hotel rooms through Web proxies, and homes with Internet connections via home router/firewalls etc. Clearly if any network component blocks PCoIP then PCoIP is not going to be possible, but our experience to date has indicated that in the vast majority of cases, this approach works well and absolutely optimizes the user experience.
At VMworld 2010 in San Francisco in August this year, we used a beta build of the PCoIP feature of Security Server for the attendee lab sessions. We hadn’t actually planned to do this, but the VPN connection we initially used to our cloud provider was set up for TCP over the wire and as this was not optimal, this gave an opportunity to try out direct PCoIP support through this new Security Server feature. Refer to the post on Chris Wolf's observations on PCoIP performance here A Simple Experiment.
Upgrade from an existing View deployment or a new install will be very straightforward. There are no changes required to View Clients or View Agents and so disruption to an existing environment will be minimal.
We plan to release this new Security Server feature as part of the forthcoming View release and we’re very exited about the remote access opportunities this will bring for View.
