Access to console fails unless use is at the LAN

Submitted by ghomem on Sun, 04/28/2013 - 17:05

CORRECTION: "unless user is at the LAN"

Seems that Cloudmin's embedded VNC application is trying to open a connection directly between the client computer and the Cloudmin server.

This fails if Cloudmin is on a remote datacenter where there is only access to port 10000. It also fails if the user is accessing a LAN installation using port forwarding (either iptables or ssh...).

The web application should be able to manage all the functions, including direct console access, using port 10000 - probably using Ajax + a separate URL for VNC communication)

(please correct me if I am seeing this wrong)

Status: 
Active

Comments

Submitted by JamieCameron on Sun, 04/28/2013 - 17:35

Currently the VNC console java applet cannot use port 10000, as it only speaks the native VNC protocol which is not HTTP-based. However, it doesn't need to connect to the KVM host system - only to the Cloudmin master on a port in the range 5900 to 5900+(number of VNC connections active).

In theory a VNC app that uses port 10000 could be created, but we are unlikely to implement that any time soon. So I would recommend opening up your firewall to ensure that ports 5900+ can be used.

Submitted by ghomem on Sun, 04/28/2013 - 18:17

But then the traffic is not going through https like the rest of what is going on. Isn't VNC unencrypted?

Submitted by JamieCameron on Sun, 04/28/2013 - 18:32

That is unfortunately true.

Submitted by ghomem on Mon, 04/29/2013 - 12:00

I think you should find a way to tunnel the VNC connections through port 10000.

Probably something like http tunnel where the server is at the Cloudmin host and the client runs in the browser.

http://http-tunnel.sourceforge.net/

I don't feel confortable with unencrypted connections nor with a long list of ports that has to be managed manually on the firewall.

Submitted by JamieCameron on Tue, 04/30/2013 - 09:33

It may be possible to add this by switching to a flash-based VNC client, instead of the Java one we use currently.

Submitted by ghomem on Wed, 04/02/2014 - 12:19

Dear devs,

We plan to move forward with more Cloudmin Pro purchases this year and would like to let you know that the major annoyance at the moment is the lack of console transparency. We have different customers at different LANS and each time we need to use a console we need to run ssh with a port forwarding parameter (that depends on the VM) and run a local vnc client.

This is very inconvenient. Do you have plans to fix this soon?

Openstack has network transparency working as far as I was told.

Cheers Gustavo

Submitted by JamieCameron on Wed, 04/02/2014 - 19:35

Sorry, but we haven't made any changes here to the port used for the console - it is still 590x. We do have a flash-based console viewer though.

Submitted by ghomem on Wed, 04/02/2014 - 22:56

I don't understand your answer. The port number is not the problem. The problem is that the applet tries to connect directly to that port number (doesn't matter which number it is) instead of using the connection that is established through port 10000. Therefore if we are outside the LAN and only port 10000 is exposed to the outside, the console can't be reached.

Does the flash viewer fix this?

Submitted by JamieCameron on Wed, 04/02/2014 - 23:44

No, the flash viewer doesn't fix it. The reason another port is used is that 10000 is for the Cloudmin HTTP server, while VNC uses a completely different protocol.

Submitted by ghomem on Thu, 04/03/2014 - 06:45

Jamie,

We are now managing only 5 Cloudmin Pro instances but during this year we might well be managing many more directly or through partners.

What options do we have regarding this:

1- open ports 5900-59XX to the internet? 2- manually use ssh each time we need to access a remote console? 3- configure a VPN on every Cloudmin Pro site?

I hope that you realize that none the options is practical, not to mention that it is sometimes impossible to even get permission from customers to do such unpractical things.

Therefore I think that for Cloudmin to be viable you have to tunnel the VNC protocol directly between the browser and the remote machine.

Can you look at what Openstack (and maybe Archipel) does?

Submitted by JamieCameron on Fri, 04/04/2014 - 00:50

Right now, only option 1 is supported. In theory something like websockets could be used to tunnel the VNC connection over port 10000, but browser support for that isn't great .... and it would require significant work to create a VNC client flash or Java app that can use websockets.

Submitted by JamieCameron on Fri, 04/04/2014 - 22:50

I don't know how openstack does it, but that kanaka project uses websockets as I mentioned.

Submitted by ghomem on Sat, 04/05/2014 - 05:14

My suggestion would be integrating this open source project into Cloudmin to overcome this console situation.

Submitted by JamieCameron on Sat, 04/05/2014 - 12:42

So I had a look at the docs for that websockets VNC client at https://github.com/kanaka/noVNC/blob/master/README.md , and it looks like unless the VNC server supports websockets (which KVM does not) you still need to run a separate websockets to VNC proxy on its own port ... which would need to be opened up on the firewall.

Submitted by JamieCameron on Sat, 04/05/2014 - 16:21

Right - websockify is a websockets proxy that runs on its own port.

Submitted by ghomem on Sat, 04/05/2014 - 18:03

It is better one proxy on a single port than opening a range of VNC unencrypted ports to the Internet.

But I will retry the openstack demo to see if I can get some more info.

Submitted by JamieCameron on Sat, 04/05/2014 - 18:27

It's likely that multiple proxies would be needed on multiple ports if there are several VNC sessions active at once.

Cloudmin is similar - if you are only ever doing one VNC session, only port 5900 on the master system needs to be opened.

Submitted by ghomem on Sun, 04/06/2014 - 14:21

Just confirmed that Openstack, which uses noVNC, only needs a single port for proxying all the traffic.

The URL to access a VM console is of the form

http://hostname:6080/vnc_auto.html?token=LOTSOFNUMERS&title=ANDMUCHMORE

I opened 2 different consoles directly on the browser by using 2 URLs of the above form.

Therefore, the Openstack server needs ports 443 and 6080 to operate.

This is already a lot better because you can have a fixed rule (either on firewals, or ssh port forwarding) for all instances, and in terms of security you have only one port to monitor. It is also nice that it doesn't need flash or java.

Submitted by JamieCameron on Sun, 04/06/2014 - 14:25

Interesting, so the websockets proxy must support connections to many different backend VNC servers - I didn't realize the protocol supported that. I'll look into adding support for this.

Submitted by ghomem on Sun, 04/06/2014 - 20:59

Thanks Jamie. We consider that very important, and I'm sure the other customers will benefit too.

Submitted by JamieCameron on Sun, 04/06/2014 - 21:41

Understood. Until then, you can operate in most cases by just opening port 5900.

Submitted by ghomem on Sun, 11/30/2014 - 06:55

Is there any update on this?

I'd like to point out another example which is digitalocean.com : they have effortless console access embedded in the web interface. Firefox connects to something running on port 5000 apparently.

Submitted by JamieCameron on Sun, 11/30/2014 - 16:48

We haven't made any changes here yet, sorry.

Submitted by ghomem on Sun, 11/30/2014 - 16:56

Ok but is there a plan to fix this?

I think this could be a blocker for further sales (especially reselling) as most sysadmins won't be happy with this.

Submitted by JamieCameron on Sun, 11/30/2014 - 22:34

It's on our TODO list, but I can't promise when it will be done.

Submitted by ghomem on Mon, 12/01/2014 - 17:46

I'm not asking for a promise but an estimation would certainly make sense.

Submitted by JamieCameron on Wed, 01/14/2015 - 16:24

I've started work on it, and completed some preliminary re-factoring of the VNC console page so that any change like this doesn't need to be implemented separately for each virtualization type.

Submitted by ghomem on Thu, 01/15/2015 - 22:08

Nice to hear, we are working on a new business oportunity where I'd like to have this addressed.

Thanks for the effort.

Submitted by ghomem on Wed, 01/21/2015 - 11:02

I realized that this doesn't work:

ssh -L 5903:192.168.5.2:5903 -L 10000:192.168.5.2:10000 -X remoteuser@remotegatway

even though we are accessing the system with https://localhost:10000 and

telnet localhost 5903

shows "RFB...etcetc".

We see this error on the flash console:

"An security error occured (Error #2048). Check your policy-policy server configuration or disable security for this domain."

So we are really stuck with running vncviewer by hand.

Any news on when we will have a single-port-port-forwardable console?

Submitted by ghomem on Thu, 01/22/2015 - 05:19

adding

-L 843:192.168.5.2:843

made it work at least on one server. I'll test further.

Meanwhile, to which version of Cloudmin do we need to update to have the flash applet?

Cheers Gustavo

Submitted by ghomem on Thu, 01/22/2015 - 05:38

We also have a server that says this for all VMs, after running SSH with all port forwardings:

VNC has been configured on this system by Cloudmin, but the VNC server on port 5904 on host system HOSTNAME.TLD is not accessible. If it was just enabled, the system will need to be rebooted before VNC is available.

But I have checked and

vncviewer localhost:5904

works.

Netstat shows several VNCs listening:

[root@vmserver02 ~]# netstat --tcp -n -l |grep 59

tcp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5904 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5906 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5988 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5989 0.0.0.0:* LISTEN
[root@vmserver02 ~]#

How can we fix this?

Submitted by ghomem on Sun, 01/29/2017 - 15:12

Any plans to fix the original situation?

Submitted by JamieCameron on Sun, 01/29/2017 - 17:42

We have a long-term plan to avoid this problem entirely by switching to a VNC client that uses websockets, and so can share the existing port.