
VMware Cloud Director provides direct access to tenant’s VM consoles via proxying the vSphere console traffic from ESXi hosts running the workload, through VCD cells, load balancer to the end-user browser or console client. This is fairly complex process that requires dedicated TCP port (by default 8443), certificate and a load balancer configuriation without SSL termination (SSL pass-through).
Especially the dedicated certificate requirement is annoying as any change to this certificate cannot be done at the load balancer level, but must be performed on every cell in the VCD server group and those need to be restarted.
However, VMware Cloud Director 10.3.3 for the first time showcases newly improved console proxy. It is still an experimental feature and therefore not enabled by default, but can be accessed in the Feature Flags section of the provider Administration.

- Console proxy traffic is now going over the default HTTPS 443 port together with UI/API. That means no need for dedicated port/IP/certificate.
- This traffic can be SSL terminated at the load balancer. This means no need for specific load balancing configuration that needed the SSL pass through of port 8443.
- The Public Addresses Console Proxy section is irrelevant and not used

- Load balancer application rules based on the URL can be used to secure such traffic or direct it to specific cells. Such traffic can be identified based on the following pattern:
GET https://vcloud.fojta.com/443;cst-ylR8ood/c2uM3TQGqw4GkwtDd7C8EtiJViZ3PzUBynysw1X3pDg1rt5QTpUDdE0gujaWGOniwcM9vNktCSJPHOUWpJqiLccY88wRJzvxWF9kIKvZzH+ZGPOTxE7Ul63BNa7FJbdZdQ6Bc/IjLRQ6MT/9yUF9U/5uF3wLQwzS+tmrr58v9x22nihCa0z/Eoteuatds6tBfKP9NyRPRvUbzyThNr7hJYO4uKo6p4xzkRoYCSoTk/d7iI2oA5T7qtUy/lToutkrxlYRQF3SEkMac7/tAYD9yfqcHtSCdiZ7E+E=-cpZbzXaCy74FCi2iF+f4vM+kEmkjvC7/iQJxwg==–tp-4A:3E:7C:11:28:AE:26:B0:54:E8:53:48:53:67:7D:FC:AC:6C:BA:A0– HTTP/1.1
Notice the /443 and the certificate thumbprint at the end.
The followin diagram shows the high level implementation (credit and shout-out goes to Francois Misiak – the brain behind the new functionality).

As this feature has not yet been tested at scale it is marked as experimental but it is expected that this will be the default console proxy mechanism starting in the next major VMware Cloud Director release. Note that you will still be able to revert to the legacy one if needed.
As always super explained Tom
Can’t wait to test it
Thanks
Have you tried accessing the console over a reverse proxy? I use NGINX and the legacy design worked fine but I’ve been unable to get the enhanced console to work except for inside the network. NGINX reverse proxy is in the DMZ, VCD is in the LAN, a NAT rule allows the traffic to VCD. I’ve disabled the ModSecurity module for VCD but that didn’t help. Wondering if you might have any ideas, thanks.
Hi Chad, I’ve got the same problem with Squid, the problem is the MKSticket URL has a semicolon in it which Unix systems treat as a escape / line break. I’ve no idea why VMware decided to put reserved characters in URLs, did you manage to get this working?
Thanks Dan
No I never have figured out how to get it to work, currently I use SNI. I’m testing 10.4.1 with its own dedicated public IP and NSX-ALB. Haven’t got the lab far enough to test yet though but if it works like that then I’ll test with SNI. Probably a week or two out still on getting everything in place for testing.
Reporting back, using Avi with a Parent/Child SNI configuration I was able to get vCD console working in a reverse proxy design. I’m using Avi 22.1.2, NSX-T 3.2.2, vSphere 7.0U3j (vCenter and ESXi) with vCD 10.4.1 additional Child I have VMware Chargeback 8.10 and both seem to be working fine, created a test company and deployed Ubuntu and was able to open the web console and VMRC.
We’ve got this working with Squid as well. The problem actually has nothing to do with special characters, but all to do with HHTTP request upgrade to WSS. This wasn’t supported on the version of Squid we were running and after upgrading and configuring http://www.squid-cache.org/Doc/config/http_upgrade_request_protocols/ we have the new console proxy implementation working with Squid as a reverse proxy.
Kudos to Niamh @ VMware support for helping and engineering for supporting
For Nginx engineering suggested the below works;
proxy_http_version 1.1; #needed as websockets are obsolete in HTTP 2
proxy_set_header Upgrade $http_upgrade; #hop-by-hop header injection needed to preserve the original client source
proxy_set_header Connection “upgrade”; #forces Upgrade connection