posted

5 Comments

By Michael Haines, vCloud Architect

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:

VCDconsoleproxy

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:

VCDconsoleproxyplugin

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

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

VCDconsoleproxy2

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:

VCD3

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.