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.
This is very welcome news Mark, although I have to say it is something that you should have been publicizing MUCH sooner.
And really - hiding this away in your blog was a BIG surprise
"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"
This is awsome. Our Company is setting up a pilot to test out VMware View. We are a call center, so we will have VOIP phone software running on the vmware machines, and the employees will be working from home. We tried using USB headsets through RDP, and the sound was horrible over internet. Then we tried using the Teradici driver for the microphone support, but this required PCOIP, which requires vpn. Using the PCOIP with teradici driver to provide a microphone actually gave good results from a work at home employee through VPN. So if we cut out the VPN, I'm sure sound and performance will be even better. We need to be able to support 300 employees working at home.
We'd be willing to pilot this in our Company
Just got off the phone with someone from VMware, and it looks like the security server that will support pcoip will still require some sort of VPN, but it sounds like the VPN will somewhat integrated into the security server.
There will still be cases where a VPN is appropriate such as if PCoIP is blocked by any networking component. PCoIP works well in such environments.
If PCoIP is not blocked then secure remote access with this new feature is supported without a VPN.
Thanks for clearing that up Mark.
I am looking into deploying View and ThinApp in our organization. I was very disappointed to find out that Security Server did not support PCoIP. Now that I know PCoIP support is coming I am much more comfortable in making a significant investment of time, money and servers to implement View.
I'm shocked that no one has asked the question yet...
Is there an ETA on when "the forthcoming View release" will be GA?
Thanks for your comments "TekMason".
We can't give you an ETA for this just yet. Announcements of GA dates need to be made officially. I just wanted to share some information about what we've done to add this View Security Server capability ahead of any announcement.
Hi Mark, hopefully this is available this year. Can you also comment on the RTO virtual profiles availability? While we do not have the demand yet for remote access to View desktops or a large enough environment where we need profile management, when and if we have that demand we will need to be able address it quickly.
Just to be clear, this forthcoming PCoIP View Security Server feature has been fundamentally designed for optimised WAN remote access use.
It's true that for remote WAN access with the current version of View (4.5), you do need to either run PCoIP through a VPN, or drop down to RDP with or without an "RDP booster" technology.
With this forthcoming feature, PCoIP runs directly over the WAN without interference and we know from our own experience and the experience of our customers, this works really well in the vast majority of WAN cases. It gives the best user experience, is supported by all PCoIP clients and gives the user a consistent PCoIP interface for both LAN and WAN use.
I'm not able to give a GA release date for this, but I can say that our beta customer trials have gone extremely well. Stay tuned!
I'm pretty happy about this. I just downloaded View 4.6 and hope to put PCoIP via Security Server into action soon.
We're very pleased to have announced the general availability of View 4.6 now, which among other updates contains this PCoIP remote access feature for View Security Server. See View 4.6 Announcement.
There is a document about the architecture and deployment of this here Setting up PCoIP Remote Access with View 4.6. which also contains a video that describes the setup in a lot more detail.