In continuation of my previous post about this issue with VNC and direct access to a vm through the service console.

In my original findings, I stated that this was possible with both ESX3i and ESX 3.5.

I opened a SR with VMware on this issue. Together we have been trying backward and forward to troubleshoot the issue and try and re-create the scenario on ESX 3.5 hosts. Now we came across the fact that it was not consistent, some hosts would allow direct VNC access and others would not.

Thanks to lots of help from Edward I have managed to to find why it was not consistent.

On the hosts that would allow VNC into a guest VM - if you would run the command

iptables -L -n | wc -l

output would be 8

On the hosts that would not allow VNC into a guest VM - if you would run the command

iptables -L -n | wc -l

output would be a higher number (78, 120...)

Now as Edward pointed out to me the first case where the output was 8 meant that iptables was disabled on the ESX host, and therefore it would allow the VNC in by default. On a host that had the firewall enabled properly VNC connection to the VM was not possible.

A quick

esxcfg-firewall -r

reset the firewall on the problematic hosts and VNC "backdoor" was closed.


2 things to note.

1. This "Backdoor" still works on ESX3i - firewall configuration is minimal at best, more like non-existent.


2. Even though the traffic traveling through the port that was opened up by the changes in the VMX file was not forwarded to the VM, the port was still opened on the ESX 3.5 and ESX3i hosts as soon as the VM was powered on.