VMware Cloud Community
JoelPx
Contributor
Contributor

Getting error when opening console while remoteing to ESX

Hi all,

Finally got our little Virtual network off the ground, but trying to setup to remote to it using a SSL gateway, where we have to plug in the ports that have to be used.

Have 902 and 903 opened for the Virtual Client to use from a remote system.

So far I can remote to the ESX server perfectly using the Virtual Client, can even power on the virtual machines.

Problem comes in when I try to open a console to the virtual machines.

It will hang for a minute before timing out and coming up with this message:

Error connecting. Cannot connect to host x.x.x.x: A connection attempt failed because the connected party did not respond after a period of time, or established connection failed because connection host has failed to respond.

If I run netstat –a right after trying to open the console I see that my remote box is trying to talk to the ESX server.

TCP :903 SYN_SENT

But it just times out every time. If I remote to the server from internally it works great. So I’m fairly sure there is some other port I must be missing to put in our SSL gateway.

Anyone have any suggestions?

Thanks!

Joel

Reply
0 Kudos
63 Replies
JoelPx
Contributor
Contributor

Day two of this issue.

Definaly sure it's something up with port 903.

Trying to narrow it down to our networks firewall (which I doubt) or something with ESX server.

/bump

Reply
0 Kudos
crnielsen
Contributor
Contributor

I had a similar problem.

I shutdown the VI client and deleted this registry key, then it worked...

HKEY_CURRENT_USER\Software\VMware\Virtual Infrastructure Client\Preferences

Regards

Claus

Reply
0 Kudos
JoelPx
Contributor
Contributor

Thanks for response!

Shut down the VI client and deleted the key from the system. Still same results though =(.

Very weird indeed.

Went as far as using esxcfg-firewall and opening an inbound tcp connection for port 903, as well as udp and tcp for outbound with 903 as well. But yeah didn't work either heh.

Pretty much ruled out everything in between the ESX server and this box remoting from the outside. Seems to be something with ESX, that just doesn't want to respond on 903 back to the remoting system.

Reply
0 Kudos
Ryan_Auclair
Contributor
Contributor

I'm having the exact same problem. Is the computer you are connecting from and the server on a different subnet by any chance? My problem is more extended then that but started off that way, and just trying to narrow down to if it's a bug or something. I have a thread opened on my issue.

Reply
0 Kudos
JoelPx
Contributor
Contributor

They are on different subnets.

When we try to use the client from the same subnet there is no problem.

Reply
0 Kudos
JoelPx
Contributor
Contributor

It may be a bug, we have escalated it back to our VMWare engineer POC and he says they are having the same problem.

When we get a fix will post it here too in case they are the same thing and you are still having the problem too.

Reply
0 Kudos
ghooper
Contributor
Contributor

I am having this exact issue as well. I am going across subnets to our remote datacenter. All documented tcp and udp ports are open through the firewall. I have ESX servers in both locations, but I am trying to use the same VC Server to manage all of them.

Reply
0 Kudos
ttsen
Contributor
Contributor

Having the same issue here, anyone have any ideas/solutions? its extremely frustrating

Reply
0 Kudos
ghooper
Contributor
Contributor

Has anyone gotten any response back on an SR or any support whatsoever?

Reply
0 Kudos
kitcolbert
VMware Employee
VMware Employee

Here's one thing you could try:

- ssh to your ESX box

- add the following to /etc/vmware/config:

vmauthd.server.alwaysProxy=TRUE

- try reconnecting

Hopefully that should allow you to work around the problem.

Reply
0 Kudos
ArildS
Contributor
Contributor

>- add the following to /etc/vmware/config:

>vmauthd.server.alwaysProxy=TRUE

This solved the problem for me. We connect over different subnets and the problem surfaced 3-4 days after the ESX 3 upgrade.

Reply
0 Kudos
ghooper
Contributor
Contributor

I tried this and it works. Nice suggestion. Where did u find that at? I didn't see it anywhere in the docs.

Reply
0 Kudos
kitcolbert
VMware Employee
VMware Employee

Yeah, I don't believe it's documented anywhere.

And I know about it because I'm an engineer at VMware familiar with this area of the code. Smiley Happy

Reply
0 Kudos
ghooper
Contributor
Contributor

Thanks again. If Virtual Center is designed to work across subnets, in an enterprise, there should probably be a portion of the documentation devoted to that type of setup. Who would I submit that suggestion to, and reference this thread?

Reply
0 Kudos
lambeth
Hot Shot
Hot Shot

The problem isn't the docs, it is a software bug which will be fixed. The option you had to set is just a workaround until a fixed version of the software is available. You should not use this option except as a workaround for this and once you have installed the update to fix the issue you should remove the option.

Reply
0 Kudos
kitcolbert
VMware Employee
VMware Employee

Sorry, I should have been more upfront about this: the remote console not working is definitely a bug! The workaround I gave above is exactly that: a workaround. We didn't document it because we didn't think anyone would need it. Unfortunately that's not the case. Be assured that we are investigating this issue.

One question: do you (or anyone else on this thread) have any NAT'ing going on between the remote console and the ESX machine? There is a known (and understood) issue for that. However, if you simply have two subnets connected by a router, then that would be a new issue. Is there anything interesting or fancy about the routing? The reason I ask is that I believe we have people here in-house connecting the remote console across subnets to the ESX server. Thanks.

Reply
0 Kudos
cantuc
Contributor
Contributor

Two problem has shown up in this thread that manifest similarly in VC not able to connect to esx-host. One problem is related to having VC and esx-host on different subnets, and the other is related to SSL gateways.

I've lost trak of who is hitting the one or the other so I'm describing them both here:

(1) VC and esx-host on different subnets

There is a problem introduced after esx30 GA (build 27701) that prevents remote MKS to work. The workaround is that indicated by Kit earlier and a fix is underway.

(2) VC connecting to esx-host across SSL Gateways or SSLVPNs

It is a well known problem of SSL/SSLVPN deployed in port forwarding mode. This mode is similar to ssh port forwarding and it breaks applications who negotiate an IP address or a TCP port on one connection and then use the address or the port to open another connection. Our protocol between VC and esx-host does that, and another example is ftp.

SSL/SSLVPNs gateways may name this port forwarding mode differently (and the name is not necessarly explanatory). In Cisco SSLVN this mode may be called "Thin Client". Juniper (aka Neotris) uses this mode and I'm not usre how they call it or it may be the default or the only mode available.

There is a SSLVPN mode that works with VC kind of applications and that is adequate (and more convenient than port forwarding) for most enterprise networks and for most enterprise kind of PCs where the VC Client runs.

A workaround is to ask your SSL/SSLVPN gateway administrator to enable that mode.

That mode is basically tunnelling the client VC IP traffic through the SSL connection and therefore it is called "tunnel mode" in Cisco SSLVPN and it is configurable on the gateway.

First look this may arise security concerns, but in practice on Cisco equipment it allows to turn on the usual IP/TCP ACLs which are otherwise unavailable with other modes.

Still your SSLVPN admin has to be confortable with the ACLs and she may have to do some job to set up ACLs for your network, in case ACLs was not available earlier, and of course feel comfortable with it.

That's why tunnel mode is convenient on Cisco equipment, while it may have another names or not being available on other SSLVPNs solutions.

Alternatively, IPsec based VPN would work just fine.

Reply
0 Kudos
vreihen
Expert
Expert

The reason I ask is that

I believe we have people here in-house connecting the

remote console across subnets to the ESX server.

I'm not quite following the problem that everyone is having here, but will throw in my observations. I have VC2 and ESX3 on the same subnet, and have used my VIC client to connect to both of them via:

1) Local IP subnet

2) Different IP subnet via layer 3 switch

3) From home, via OpenVPN gateway (builds IP tunnel via SSL) and cable modem

I'm really amazed at #3, since the remote console tool from GSX had some sort of intermittent issues where it didn't work about 85% of the time across this same link whereas VIC to ESX3 and VC2 are rock-solid. I couldn't even tell that I wasn't in the office over the remote link!

This thread seems to be taking about VC2 and ESX3 being on different subnets in one post, and VIC talking to VC2/ESX3 on different subnets on another post. I'm reporting my observations, in case they arehelpful to debug the problem or troubleshoot what's going on in general...

Reply
0 Kudos
JoelPx
Contributor
Contributor

kitcolbert: Thank you! Thank you!

Adding that line in the config file did the trick!! Sorry haven't responded, have been working with other folks on your end and hadn't thought to check here till today, will let them know now that my issue is resolved :smileygrin:

Reply
0 Kudos