Console Proxy Traffic Enhancements

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.

By enabling it, you switch to the enhanced console proxy implementation that gives you the following benefits:
  • 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

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.

11 thoughts on “Console Proxy Traffic Enhancements

  1. 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.

    1. 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

      1. 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.

        1. 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.

  2. 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

    1. We are having a similar issue on VCD 10.3.3 after enabling the feature flag “New console proxy” and using Firefox.

      Firefox uses the “keep alive, Upgrade” values in Request Header “Connection”, which as per VMware KB is not supported with NSX-T Native load balancer < 3.2.x
      This is working just fine for Edge/Chrome instead, as they only contain "Upgrade" in the "Connection" request header field.
      This is the KB reference: https://kb.vmware.com/s/article/86288

      We are trying to rewrite request headers from the LB side, but no luck. Currently engaging VMware support for it.

      Just thought it useful to share with a wider audience, this might be applicable also on higher VCD versions with the same combination of browser (Firefox) and LB (NSX-T native LB).

      1. Well I was doing well until 10.4.2 or ALB 22.1.3, now it would seem vCD is doing an API call over the LB IP rather than FQDN so it’s going nowhere and bringing the performance count of the parent down. I figure a fix would be making vCD the parent pool rather than a pool of web servers but the catch all going to the corporate webpage seems a better choice.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.