Service Console Access Question

[CeriRich]

Hi All,

I'm fairly new to ESX 3 so please be gentle!

My issue relates to access to the SC within ESX 3. Currently we have the SC setup on its own private subnet with nothing outside having access. This was on the recommendation of our VMware supplier. When we install the VI client on our VC server we can obviously gain full access to each of our VM's and their respective consoles views due to the VC server having a network card on the same subnet as the SC.

Our problem arrises when we try and install the VI client on machines outside the SC subnet as our supplier thought that VI clients only need access to the VC server. We can talk to the VC server from machines outside the SC subnet running the VI client but (this is the big BUT) we cannot see the VM's console view.

To solve this - do we need to open the SC subnet up (port 902) to machines running the VI client outside the SC subnet? Or is there a setting in VC or a software firewall in place on ESX which we need to modify so VI clients can see the VM consoles by bouncing of the VC server?

I'm just reluctant to do this as most best practise guidelines tell you to isolate the SC subnet.

Thanks in advance,

Ceri

[bertdb]

As you've noticed, the remote console functionality of the VI-Client needs a direct connection between VI-Client and ESX.

you can run your VI-Client remotely (rdesktop, citrix, vnc, NX) on a machine that is on the management network.

Or have routing (+firewalling) in place so that your desktop machines (running the VI-Client) can reach the necessary ports on the ESX.

[GavinJ]

If you want to pass the traffic thorugh the firewall, remote console traffic generated by user access to VM’s is carried over TCP port 903 inbound.

Depending upon how security conscious your organisation is you could use RDP or equivalent to access VM's rather than the VM console - and use the VI Client on the protected network in emergency if a VM hangs. It's generally not recommended to manage VM console sessions from the VIC

Alternatively you could also limit VI client access from PC's on the unprotected network by binding the PC MAC address to the firewall rule so only authorised PC's can access the VIC thereby limiting exposure.

Gavin

[CeriRich]

Thanks both - suppose our problem is mainly caused by the fact that we need to be able to allow other teams within our organisation to have access to their VM's though VIC (then lock down access). We dont want them to RDP into our management server.

Even though we create, and have overal management of ESX and VC we need to rollout access to VIC to allow other teams to actually build a server in the first place which can only be done through VIC. Bottom solution sounds like a good solution to this.

Thanks again!

[GavinJ]

Good stuff - glad it helped; you're welcome to allocate points to posts which you find useful also.

Thanks

Gavin