vSphere Web Client - Console???

[1q2w3e4r]

I have a functional vSphere 5 Web Client server, which I've NAT'd on my firewall so I can manage VMs from the Internet. The client works well for everything except the Console. I've installed the plug-in, and I see a little screen of my VM with "Launch Console", but if I click on the link it brings up another page and errors out with "Host name could not be resolved". What is it trying to connect to here? The Web client server? The vCenter server? Or the ESXi host itself?

All servers are behind a firewall and I use all internal DNS (eg. esx1.xxx.local), with only the Web Client server being NAT'd to the outside, which I connect to via IP address. As I said it all works, except so the console so i assume this is trying to do something different? Is it trying to resolve internal server names?

[ranjitcool]

Hello,

Yes, the system you are using must be aware of the dns to the vms. I tried this at home and it said the same thing as well.

When i removed my router from being dns and had a dedicated dns server within my network, it worked fine. May be static dns entries might help? My guess is for console access it uses a port to connect to it.

I did some googling and went through some kb articles but zippo.

Keep us posted.

RJ

[1q2w3e4r]

When you say DNS to the vms, are you talking the ESXi hosts? or the actual VMs themselves?

None of these machines are externally resolvable, nor have public IPs, as the only public facing box is the Web Client Server itself.

[Slingsh0t]

The vSphere client console is trying to connect directly to the ESXi host.

You will need to setup DNS entries for each and every ESXi host (with external IP's - perhaps you'll need to setup NAT or PAT depending on your config) along with opening the console port in any configured firewalls (port 903 if I remember correctly) to ensure you can open a console session with any running VM's on any hosts.

Cheers,

Andy

[admin]

Console needs to connect to both VC and ESX, I think ports 902 / 903, please double-check. Yes it must be trying to resolve internal host names.

[cbarber]

I have the same problem with my configuration, basically identical to yours. As far as I can tell the console is in fact attempting to communicate directly with the esxi host on which the given vm resides, which is intentionally impossible in this configuration because we want to keep our hosts completely firewalled off from the outside. The only thing that should be visible is the VS server and it ought to be proxying all communications, including consoles, between the esxi host machine and the VS client.

I can see the VS client attempting to DNS the name of my host, and when I place my client on a network in which this will work, and in which there is a route to the host, all is fine. When the client is outside of that network, and the only thing visible is the VS Server, it's no good.

The fact that dns fails to resolve host names, etc, is not strictly the problem; it is a symptom of this (to me) bizarre behavior of the client attempting the impossible.

Is it not possible to have the VS server proxy the console back to the client? I cannot believe that this is not the defaut out-of-the-box configuration...

Does anyone have a solution to this (other than to RDP onto the VS server box) that does not involve opening ports and providing DNS outside of the firewall for the hosts?

Chris

[Slingsh0t]

You can use vCloud director which has a console proxy feature included.  Other than that there is the option for a jumpbox or citrix vsphere client etc...

[cbarber]

one detail I failed to notice initially - I'm using the normal VS client, not the web client/server version like you are. Behaviors seem the same otherwise.

[Slingsh0t]

From what I've observed the consoles for the web client and vsphere client work the same way, a direct connection to the VM's host.

[abbie11]

Hello

It seems the port not configure properly .

Please chekc the port number add exclude from firewall for testing purpose.

Yours, Abbie

[cbarber]

It's true that the ports are not configured to go through the firewall; this is intentional. I could accept opening those ports on the fw if the traffic was meant to go to the VS server, but the consensus seems to be that the client wants to hit the host directly, as evidenced by the attempt to dns the host name.

Doesn't it seem completely insane that we should be expected to allow external access directly to our hosts?

Perhaps the architecture wants to dns the host name, but then once resolved it will direct traffic through the VS server? If so then what should be the resolution of that host name? should it be the internal network address (e.g 192.168.1.xxx), or what? I just cannot rationalize any of these scenarios...

Chris

[Slingsh0t]

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=749640

Configure your firewall to allow communications between the ESX/ESXi  host and the workstation running vSphere Client using port 903. For more  information, see Testing port connectivity with Telnet (1003487).

On the one hand it hampers access, on the other hand represents a security risk.  Does seem silly, although having all console sessions running through the vc server could be taxing, especially for things like attached ISO's and transfer of data.  Perhaps in future we'll see console proxy VA's released by vmware instead of needing to open ports directly to the hosts.

[admin]

In fact VCD - Cloud Director - already have the Console proxy that allows you to connect to VMs without punching the whole in a firewall. This technology might eventially be available for VC.