TonyJK
Enthusiast
Enthusiast

Cannot connect to host xxxx: No connetion could be made .....

Jump to solution

Recently, we add an ESX 3.5 U3 Host to a VI Cluster. We are able to start VM / get performance statistics for that ESX Host.

However, when we go to console, we get the error message: "Cannot connect to host ESX3.yourcompany.com: No connecction could be made because the target machine actively refused it.

I have tired to use VI Client to connect to that particular ESX Host and get the same result for all VMs (when I attempt to go to the Console Tab).

Your advice is sought.

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Craig_Baltzer
Expert
Expert

Without knowing the network configuration between the ESX host and the VI Client I'd guess that the other 2 ESX hosts are not firewalled or port blocked. The line in your original error message about "the machine actively refused it" is usually the tip-off that there is a firewall in the middle that is blocking a given port.

The typical NAT issue happens when a client connects to a server and the server then tells the client to contact it again by passing back its IP address and a new port #. So for example in the VI Client case, the VI Client connects to an ESX server, and then selects to open the console. The ESX server passes the client back its IP address and port 903 and tells it to make a connection. If there is NATing between the VI Client and the server, then things go amuck as the server passes back its "real" IP address (which is unreachable) to the client, so the connection request fails. In more specific terms...

  1. VI Client and ESX server are seperated by a NAT firewall. The VI Client is 10.1.1.2 and the ESX Server is 100.100.100.1. There is a NAT rule on the firewall that "NATs" 10.1.1.1 to 100.100.100.1. The DNS server that the VI Client uses has an A record for the ESX server that points to 10.1.1.1

  2. VI Client wants to connect to the ESX server so it opens a connection to 10.1.1.1. The firewall sees that connection and "NATs" (translates) it to 100.100.100.1 and passes it along. A connection is made and the VI Client and the ESX server are talking

  3. VI Client picks the option to Open the console session to a VM. The ESX server sends back instructions to connect to it using its IP address (100.100.100.1 as the ESX server has no idea its being "NATed") on port 903

  4. VI Client tries to connect to 100.100.100.1 on port 903 but can't because it has no route to 100.100.100.1

So what the alwaysProxy says is for the ESX server to use the already existing connection the VI Client has to it on port 902 for the console connection. Since the connection already exists, then everything works as expected. This also works in situations where port 903 is blocked on the firewall but port 902 is open.

View solution in original post

0 Kudos
3 Replies
Craig_Baltzer
Expert
Expert

Is there a firewall between the VI client and the ESX host? Opening the console requires port 903 to be open in addition to 443 and 902. You can force the 903 traffic to be proxied over 902 by adding

vmauthd.server.alwaysProxy=TRUE

to /etc/vmware/config on the ESX host. http://communities.vmware.com/thread/175881 has some prior discussions on this...

TonyJK
Enthusiast
Enthusiast

Dear Craig,

Many thanks for your advice. I have added the statement and restart the network service. It does work properly.

I have digged into this case and found that a fellow said that

"if the ESX Server is being NAT'ed (i.e. the IP Address you connect to is not the same IP Address that is on the ESX Service Console), you'll need to add the following to /etc/vmware/config on the ESX host:

vmauthd.server.alwaysProxy=TRUE ".

I would like to seek your advice

1) I can still use VM console for the remaining 2 ESX hosts without that Proxy Statement. Do you have any idea ?

2) From what the fellow says, the ESX Server is being NAT. Can you elaborate on this point ? I wonder what is the difference between the ESX Server IP Address and the ESX Service Console IP Address). As far as I know, it is the same in my case.

Thanks again

0 Kudos
Craig_Baltzer
Expert
Expert

Without knowing the network configuration between the ESX host and the VI Client I'd guess that the other 2 ESX hosts are not firewalled or port blocked. The line in your original error message about "the machine actively refused it" is usually the tip-off that there is a firewall in the middle that is blocking a given port.

The typical NAT issue happens when a client connects to a server and the server then tells the client to contact it again by passing back its IP address and a new port #. So for example in the VI Client case, the VI Client connects to an ESX server, and then selects to open the console. The ESX server passes the client back its IP address and port 903 and tells it to make a connection. If there is NATing between the VI Client and the server, then things go amuck as the server passes back its "real" IP address (which is unreachable) to the client, so the connection request fails. In more specific terms...

  1. VI Client and ESX server are seperated by a NAT firewall. The VI Client is 10.1.1.2 and the ESX Server is 100.100.100.1. There is a NAT rule on the firewall that "NATs" 10.1.1.1 to 100.100.100.1. The DNS server that the VI Client uses has an A record for the ESX server that points to 10.1.1.1

  2. VI Client wants to connect to the ESX server so it opens a connection to 10.1.1.1. The firewall sees that connection and "NATs" (translates) it to 100.100.100.1 and passes it along. A connection is made and the VI Client and the ESX server are talking

  3. VI Client picks the option to Open the console session to a VM. The ESX server sends back instructions to connect to it using its IP address (100.100.100.1 as the ESX server has no idea its being "NATed") on port 903

  4. VI Client tries to connect to 100.100.100.1 on port 903 but can't because it has no route to 100.100.100.1

So what the alwaysProxy says is for the ESX server to use the already existing connection the VI Client has to it on port 902 for the console connection. Since the connection already exists, then everything works as expected. This also works in situations where port 903 is blocked on the firewall but port 902 is open.

0 Kudos