Red Hat Bugzilla – Bug 1264386
HTML5 VNC console is not load balancer compatible
Last modified: 2017-08-21 09:04:36 EDT
Description of problem:
The current implementation isn't load balancer aware. When opening a HTML5 VNC console, it redirects to the host name of the CFME UI where the user is logged on, bypassing a load balancer. Furthermore, it uses a different port range for external connectivity (f. e. 5900-5999) for the incoming VNC console.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Put a load balancer or reverse proxy in front of CFME which does SSL offloading or at least SSL session affinity
2. login to CFME
3. open a console to a virtual machine
When analyzing the console page, it becomes visible that the connection goes to the external hostname and a port in the defined VNC port range.
The load balancer isn't aware of the VNC ports and cannot know on which UI the user is logged in. The connection may go to the wrong CFME instance, the console connection doesn't start.
The console part shouldn't create absolute URLs.
The connection should be redirected to the CFME UI where the user is logged on.
This could be achieved with SSL affinity on the load balancer or reverse proxy, and the VNC connection going the same way that all other requests go. That means,it should through port 80 or 443.
If a CFME UI instance fails - goes down, is shutdown, whatever -, existing connections will be dropped, users will have to reconnect - that's acceptable.
One more to add: CFME users (external customers for a cloud provider) will have to open our console port range (5900-5999) from their users desktops to the CFME UI. They won't like that. They want to be able to pass that traffic through an existing ruleset covering HTTPS, and probably a proxy or an application layer gateway.
Created attachment 1083280 [details]
eww ag ITandTEL cloud infrastructure external user access via load balancer
This is an overview about the architecture that the customer would like to use for external CloudForms access. External users come in via 443/HTTPS only. The HTML5 console is also tunneled through 443U/HTTPS. There will be an SSL proxy and load balancer in front of two CFME UIs. Internal traffic between load balancer and CFME will be HTTP or HTTPS. HTTP will be fine as it is internal traffic, but it doesn't matter.
With the changes we did in 5.6, all the wss:// is proxied through :443.
I'd say that we can close this issue, but I have not tested this setup.
Martin, can you, please, test if 5.6 meets your requirements?
(In reply to Martin Povolny from comment #5)
> With the changes we did in 5.6, all the wss:// is proxied through :443.
> I'd say that we can close this issue, but I have not tested this setup.
> Martin, can you, please, test if 5.6 meets your requirements?
This sounds like a good solution, but right now, I have no chance to test this: at the moment, I'm not on-site on the affected customer. My current customer has similar requirements, but of course, they are using CFME 5.5.3 at the moment.
Can we backport this to 5.5 for testing (probably temporarily)?
We have a test UI there where we could put it on.
I am afraid that it's not feasible to backport this to 5.5.3. The changes are quite complex and include a new worker.
Could you suggest some proxy software that we could you to verify/demo that this actually works now?
My customer is preparing the upgrade to 5.6 now. I will check with them if they can test the scenario.
We deployed both cfme 5.6 and cfme 5.7, and seems that this bug is still open, isnt't it?
Well, since the HTML5 console connectivity runs now through the Apache HTTP Server on port 443 with the host name of the appliance, I think it should be load balancer aware now, if the load balancer supports "sticky" SSL sessions. This makes perfect sense as the console connection won't work in case of an automatic failover to another UI appliance anyway, it has to be re-established.
Unfortunately I have no chance to verify this in a customer environment at the moment.
Documentation for the HTML console details could be better.
I do not insist on keeping this BZ open :)
(In reply to Martin Welk from comment #10)
> Well, since the HTML5 console connectivity runs now through the Apache HTTP
> Server on port 443 with the host name of the appliance, I think it should be
> load balancer aware now, if the load balancer supports "sticky" SSL
> sessions. This makes perfect sense as the console connection won't work in
> case of an automatic failover to another UI appliance anyway, it has to be
> Unfortunately I have no chance to verify this in a customer environment at
> the moment.
in the next few days / weeks, we could verify in our environment :D
> Documentation for the HTML console details could be better.
> I do not insist on keeping this BZ open :)
This bug has been open for more than a year and is assigned to an older release of CloudForms.
If you would like to keep this Bugzilla open and if the issue is still present in the latest version of the product, please file a new Bugzilla which will be added and assigned to the latest release of CloudForms.