Getting Started with vCloud Director, VMware Remote Console Proxy and VMware Remote Console Plugin

The Remote  Console Proxy allows a tenant (a vSphere Remote Console client) using  VMware vCloud Director (vCD) the ability to access a vApp (VM) and open  and present the console of that vApp (VM) in question.

So, why do we  need to have a Remote Console Proxy at all? In the context of VMware  vCloud Director, we have a product that is designed to work over the  public Internet. For security reasons, we need an intermediate  communication module, the Remote Console Proxy. The security aspect and  benefit here for the Service Provider means that they do not have to put  their vSphere infrastructure directly on the internet, and for the  consumers (tenants) of such a service, they gain the ability of access  through an additional security layer such as a firewall, etc.

Here’s How it Works:

The VMware  Remote Console clients (also referred to as VMRC) communicate with the  vSphere servers using a custom protocol developed by VMware. However,  cloud users will more than likely be behind corporate firewalls that  limit the possible network communication only to selected protocols and  thus custom protocols would not be allowed. To resolve this limitation,  the Remote Console Proxy allows the entire Remote Console communication  to be tunnelled over the HTTPS protocol. This approach uses the standard  port 443 and can be passed via corporate HTTPS proxies if needed.

Below I try to  answer the 11 top questions about some of the key components that you  need to understand about VMware vCloud Director and the Remote Console  Proxy.

1. What are the components of Console Proxy (CP)?

VMware Remote Console Plugin

The VMware  Remote Console Plugin provides the scripted interface to launch the  VMware Remote Console. The plugin is provided as an ActiveX control for  IE and a Mozilla plugin for Firefox. The plugin launches vmware-vmrc.exe  on Windows and vmware-vmrc on Unix that renders the Virtual Machines  (VM) console. vCloud Director uses client-side JavaScript to call into  the plugin. The VMware Remote Console Plugin also queries the proxy  settings from the browser. Note: the VMware Remote Console Plugin caches  browser proxy settings and hence if you make changes, you need to  restart the browser for the plugin to reload the settings.  The VMware vCloud Director Remote Console is vSphere 4.1 plus vCloud  specific features (browser proxy support and HTTPS tunnelling for MKS  traffic). VMware vCloud, allows you to open the console of a Virtual  Machines (VM), only if the state of the Virtual Machines (VM) is powered  off. vCD and not the VMware Remote Console enforce this behaviour.

VMware Remote Console

The VMware  Remote Console can be thought of a lightweight VIM client (VIM stands  for VI Management. For the VI, it could be VMware Infrastructure or  Virtual Infrastructure), that is spawned by the VMware vCloud Director  in this case, and which is capable of providing MKS (For virtual  machines residing on a VMware ESX/ESXi server, console connections are  offered through the VMware MKS ActiveX control). This control is  downloaded through a secure channel when you try to view a live VMware  virtual machine) and device interactions with a single remote Virtual  Machine (VM) that lives on a vSphere server. As such, the Remote Console  can talk to either a Virtual Machine (VM) residing directly on an  ESX/ESXi server or go through the vCenter server. It also has some  limited Virtual Machine (VM) management functionality for the Virtual  Machine (VM) it is connected to.

Note:  The Remote Console only operates on powered on Virtual Machines (VMs).  This is enforced by vCD, which means that vCD does not allow you to open  the console of a powered off Virtual Machine (VM). However, Remote  Console does allow opening console of a powered off VM and the behaviour  is to automatically power it on.

Remote Console Proxy (CP)

The Remote Console Proxy performs three distinct functions:

a) Provides a  single entry point. A VMware vCloud Director installation works with a  large number of vCenter servers and ESX/ESXi servers and therefore the  Virtual Machines (VM) can be located on many different hosts. The  vCD clients are not aware of that however – they communicate only with  the Console Proxy in order to open Remote Consoles. It is the only  visible entry point for Remote Console communication from the viewpoint  of the vCD clients. The Console Proxy is responsible for redirecting the  requests to the correct vCenter server and ESX/ESXi servers.

b) HTTPS  communication. The VMware vCloud Director clients communicate with the  Console Proxy only via HTTPS on port 443. This communication can be  channelled through a client's HTTPS proxy as well if needed. The Console  Proxy converts the incoming HTTPS communication to the protocols  specific to the vCenter server and ESX/ESXi servers.

c) Security.  The Console Proxy provides an additional layer of VMware vCloud Director  specific security on top of the standard vCenter server security. The  Console Proxy assists with the protection of customer Virtual Machines  (VMs) in a multi-tenant environment. In this case it ensures that a  client in one organization does not get access to the Virtual Machines  (VMs) of another organization. The Console Proxy also protects the  vCenter and vSphere servers from denial of service attacks. This works  through the Console Proxy communicating with the vCenter and ESX/ESXi  servers, but only if the connection is made by clients who have already  authenticated to the VMware vCloud Director server. Other clients are  denied access, and as a result the vSphere servers cannot be subjected  with connections from anonymous users.

Cipher Suites

The Console  Proxy accepts only FIPS-140 compliant cipher suites. These suites only  use "Triple-DES (3DES)", which is the "Data encryption standard (DES)"  and is a symmetric encryption standard based on a 64-bit block and  "AES", which is "Advanced Encryption Standard" and is also an example of  a symmetric algorithm.

The following is the specific list of supported Console Proxy cipher suites:

• TLSv1:DHE-RSA-AES128-SHA - ENABLED - STRONG 128 bits
• TLSv1:DES-CBC3-SHA - ENABLED - STRONG 168 bits
• TLSv1:AES128-SHA - ENABLED - STRONG 128 bits
• SSLv3:DHE-RSA-AES128-SHA - ENABLED - STRONG 128 bits
• SSLv3:DES-CBC3-SHA - ENABLED - STRONG 168 bits
• SSLv3:AES128-SHA - ENABLED - STRONG 128 bits

Note: A description of FIPS-140 can be found here:

Logging

The Remote  Console Proxy logs the important events in the  logs/vcloud-container-info.log (in the vCD cell). Detailed information  about its operations is logged in logs/vcloud-container-debug.log (if it  is enabled).

2. How does the Remote Console Proxy Work?

The Remote  Console Proxy runs as a process on the VMware vCloud Director Cell and  communicates to the vCenter server on port 443 and to the ESX/ESXi host  on ports 902 and 903. The VMware Remote Console Plugin, which runs on  the client browser, communicates with the Remote Console Proxy only on  port 443. The VMware Remote Console Plugin then tunnels the MKS traffic  (902/903 traffic) over HTTPS to the Console Proxy. In terms of the flow,  a user creates a HTTPS session to the VMware vCloud Director Portal via  a load balancer (and is authenticated etc).  Note here that the MKS  traffic is already encrypted at this point, so we do not need to encrypt  it again. Also, the initial handshake is SSL and the traffic after that  is encrypted in a custom way. The VMware Remote Console Plugin talks  only to a single address, that of the Console Proxy, or its Load  Balancer. The VMware Remote Console Plugin talks to the Console Proxy,  possibly through a Load Balancer only on port 443. If present, the Load  Balancer directs the incoming HTTPS connections only to the Console  Proxy. It is the Console Proxy's responsibility to direct the connection  to the correct vCenter server or ESX/ESXi server and to convert the  HTTPS connections to MKS connections on ports 902/903 if needed.

Note that the  VMware vCloud Director Remote Console Plugin detects whether the client  has an HTTPS proxy (using the IE settings) and it only talks to Console  Proxy through the HTTPS proxy if there is one.

As you will  note from the above, there is a difference in the way that the vSphere  Remote Console Proxy and the vCD Remote Console Proxy functionality  works. The following basically lists the differences:

• The vCD Remote Console Proxy plugin uses the proxy settings configured in the browser to connect to the Remote Console Proxy.
• The Remote Console Proxy presents itself as a vCenter server and ESX/ESXi server to the vCD Remote Console Proxy.
• The ticket  used by the vCD Remote Console Proxy is augmented to figure out which  real vCenter server and ESX/ESXi server it needs to communicate with.

3. How does VMware vCloud Director actually Remote Console to the ESX/ESXi Console?

The flow of operations goes as follows:

• The VMware Remote Console Proxy logs in via the vCenter server using the clone ticket that was provided to it.
• The VMware  Remote Console Proxy acquires an MKS ticket for the Virtual Machine (VM)  from the vCenter server and gets the address of the ESX/ESXi where the  VM is running.

The VMware  Remote Console Proxy connects to the ESX/ESXi using the MKS ticket. In  ESXi this occurs in one pass only on port 902. In ESX, the VMware Remote  Console Proxy first gets yet another MKS ticket on port 902 and then  connects on port 903, only then does it establish a VNC-like connection  that allows it to display the remote console of the Virtual Machine  (VM).

4. How does the Remote Console Proxy Work without a Load Balancer?

Diagram: vCD-Console-Proxy-Architecture without a LB:

The browser  interacts with the VMware vCloud Director Portal using the HTTP service  and requests a console session ticket. The VMware vCloud Director Cell  responds to the client with the console session ticket that includes an  IP Address to connect to – in this example (192.168.1.2). The VMware  Remote Console Plugin then connects to the IP Address (192.168.1.2) from  the console session ticket. If you do not have the VMware Remote  Console Plugin installed, you will be prompted to install this (please  see the diagram vCD-Remote-Console-Plugin). Once the VMware Remote  Console Plugin is installed on the client browser, the console session  will start between the VMware Remote Console Plugin and Console Proxy.

Diagram: vCD-Remote-Console-Plugin:

5. How does the Remote Console Proxy Work with Load Balancing HTTP Traffic?

Diagram: vCD-Console-Proxy-Architecture with a LB:

In this  scenario, the browser interacts with the VMware vCloud Director Portal  using the HTTP service, but this time the communication is performed  through the Load Balancer and again requests a console session ticket.  The VMware vCloud Director Cell responds to the client with the console  session ticket that includes an IP Address to connect to – in this  example 192.168.1.2. The VMware Remote Console Plugin then directly  connects to the IP Address (10.10.10.1) from the console session ticket.  If you do not have the VMware Remote Console Plugin installed, you will  be prompted to install this (please see the diagram  vCD-Remote-Console-Plugin). Once the VMware Remote Console Plugin is  installed on the client browser, the console session will start between  the VMware Remote Console Plugin and Console Proxy. In this scenario,  all HTTP traffic will be load balanced.

6. How does the Remote Console Proxy Work with the HTTP and Remote Console Proxy Load Balancer?

Diagram: vCD-Console-Proxy-Architecture with HTTP and Load Balancer:

In the above  architecture, the browser interacts with the HTTP service through the  load balancer and requests a console session ticket. On completion of  acquiring the session ticket, the vCD cell responds with the ticket that  includes the IP address to connect to, in this case either, 10.0.0.1 or  10.0.0.2. The VMware Remote Console Plugin then connects to the  external IP of 10.0.0.1 or 10.0.0.2 from the ticket again. Finally, the  console session then takes place between the VMware Remote Console  Plugin and the console proxy through the load balancer.

In Part 2 of  this post, I’ll cover resiliency of the remote console proxy, what ports  are required, operations available to the user, and run through  troubleshooting and tools.