VMware vCloud Director – Remote Console Proxy and VMware Remote Console Plugin

Information

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.

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 tunneled over the HTTPS protocol. This approach uses the standard port 443 and can be passed via corporate HTTPS proxies if needed.

Supported 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

Details

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 the user 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:

1. The vCD Remote Console Proxy plugin uses the proxy settings configured in the browser to connect to the Remote Console Proxy.
2. The Remote Console Proxy presents itself as a vCenter server and ESX/ESXi server to the vCD Remote Console Proxy.
3. 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.

Steps to create new web and console proxy SSL certificates on the vCloud cell:

One must have access to a computer that has a Java 6 runtime environment, so that one can use the keytool command to create the certificate. The Cloud Director installer places a copy of keytool in /opt/vmware/ cloud-director/jre/bin/keytool, but one can perform this procedure on any computer that has a Java runtime environment installed.

1. Create an untrusted certificate for the HTTP service host.This command creates an untrusted certificate in a keystore file named certificates.ks:keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey -keyalg RSA -alias httpIn response to the keytool question:What is your first and last name? Enter the fully qualified domain name of the HTTP service host. For the remaining questions, provide answers appropriate for the organization and location, as shown in this example.What is your first and last name? [Unknown]:mycloud.example.comWhat is the name of your organizational unit? [Unknown]:EngineeringWhat is the name of your organization? [Unknown]:Example CorporationWhat is the name of your City or Locality? [Unknown]:Palo AltoWhat is the name of your State or Province? [Unknown]:CaliforniaWhat is the two-letter country code for this unit? [Unknown]:US Enter key password for <http> (RETURN if same as keystore password):
2. Create an untrusted certificate for the console proxy service host.This command adds an untrusted certificate to the keystore file created in Step 1: keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey -keyalg RSA -alias consoleproxyIn response to the keytool question:What is your first and last name? Enter the fully qualified domain name of the console proxy service host.For the remaining questions, provide answers appropriate for the organization and location, as shown in the example in Step 1.
3. To verify that all the certificates have been imported, list the contents of the keystore file:keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -list
4. Make sure to move or copy the certificates.ks file to the /opt/vmware/cloud-director/ directory.
5. To use the new keystore file, the user will need to reconfigure the vCD cell. First run the following to stop the vcd cell: service vmware-vcd stopNext, run the configuration script: /opt/vmware/cloud-director/bin/configureNOTE: The user will not lose any data by running this configuration utility.Once the script starts, it will ask the user for the SSL certificate. He will need to identify it by typing in the keystore name (example: certificates.ks). The user will be prompted to enter the required passwords. Accept the question asking the user if he wants to start the vCD service again.
6. Once the service is back up, please try opening a console in vCD once again and let me know if the same error is received.

Troubleshooting:

Here are some of the most common things to check if for some reason the user is not able to use the Remote Console Proxy:

1. Does netstat -nape | grep 443 show a java process listening on the IP Address that the user is specified as the (internal) console proxy IP Address when running the configure script? This should also show port 443 open on the HTTP service IP.
2. Can the user telnet to port 443, 902, and 903 on the vCenter server from the vCD server?Can the user telnet to the public console proxy IP on port 443 from outside of your Load Balancer?
3. Do the VMware Remote Console Plugin logs, which exist on the client, tell the user anything? On Windows clients, the VMware Remote Console Plugin logs are typically found in C:\Documents and in Settings\LOGINUSER\Local Settings\Temp\vmware-LOGINUSER. The file names follow the pattern of vmware-LOGINUSER-VMWAREVMRCPID.log and vmware-VMWAREVMRCPID-mks-LOGINUSER-VMWAREREMOTEMKSPID.log. On Unix clients, the VMware Remote Console Plugin logs are typically found in /tmp/vmware-LOGINUSER. Again, the file names follow the pattern vmrc-VMWAREVMRCPID.log and VMWAREVMRCPID-mks VMWAREREMOTEMKSPID.log.
4. Do the Console Proxy logs tell the user anything? The Console Proxy logs all its activity in the same way as the rest of the vCD server. Its logs therefore can be found in <vCD dir>/logs/vcloud-container-info.log and vcloud-container-debug.log.

©Copyright 2023 Hewlett Packard Enterprise Development LPHewlett Packard Enterprise Development shall not be liable for technical or editorial errors or omissions contained herein. The information provided is provided “as is” without warranty of any kind. To the extent permitted by law, neither HPE nor its affiliates, subcontractors or suppliers will be liable for incidental, special or consequential damages including downtime cost; lost profits; damages relating to the procurement of substitute products or services; or damages for loss of data, or software restoration. The information in this document is subject to change without notice. Hewlett Packard Enterprise Development and the names of Hewlett Packard Enterprise Development products referenced herein are trademarks of Hewlett Packard Enterprise Development in the United States and other countries. Other product and company names mentioned herein may be trademarks of their respective owners.