VNC connections fail with UltraVNC

[Brian Bergin]

When I have UltraVNC installed on customers' systems I'm unable to get the .vnc file to launch locally.  I get the attached error.  RDP and HTTP works perfectly, but we have hundreds of UVNC installs out there so any help here would be great.

Thanks...

[jamwyatt]

Danny,

I've checked this out this morning and find that my native VNC viewer on my Mac can connect (at least to the part where I don't have a password). I've checked the back end mappings of the tunnels and it seems to be setting everything up correctly. The tunnels for connections like VNC are simple pass through tunnels and they don't do anything interesting to the data stream, unlike the Web tunnels.

As a test, I was able to use telnet to attempt to connect to the tunnel to see that the TCP connect worked. Here's the output:

     $ telnet xlx-1-1050-001e58fee103.ciscovar.com 11700

     Trying 173.37.195.221...

     Connected to www.ciscovar.com.

     Escape character is '^]'.

     RFB 003.006

     ^]

     telnet> quit

     Connection closed.

The part in bold is sent from the server upon connection. I did the same test from the thunder bolt itself and got the same response. Port 11700 is mapped through to the specific PC on its port 5900. Another interesting note about our tunnels, once they receive a connection, the tunnel becomes directly locked to that remote IP address. The only way that this might be an issue is if there was actually two attempts to connect to the tunnel, using two different IP addresses. The first would win and the second would lose. When a tunnel is rebuilt, the first time IP address is reset. I should note, that this might change to be even stricter in the future.

If I had to make a guess, I'd suggest trying another VNC viewer. If that doesn't work, maybe you and I could work on this directly over the phone. That way, I can watch the tunnel creation and verify the first connection is being registered properly.

Robert

[danny]

Thanks,

The version of VNC I am using is UltraVNC Viewer 1.0.8.0.  If this is different from what you are using then maybe it would be a better test for you to try it.  I will be more than happy to do this over the phone since Brian and I are having the same problem and using the same Viewer then maybe its the Viewer we are using.

[jamwyatt]

I have tried with UltraVNC using a connection target as "xlx-1-1050-001e58fee103.ciscovar.com::11700". According to the tool tip, the double colon means that it is directed port 11700, as required. I checked our security tools and there is an association to the originating IP (TCP connection was made). Unfortunately, it fails to fully connect the protocol and offer any authentication request. I then tried, on the same computer, using 'TightVNC' and it works fine, as far as connecting and requesting the credentials. If I had a guess, I would suggest that UltrVNC might be making > 1 connections and only one of the connection attempts uses the correct, non-default, port 11700. A test would be to change the sever on the target machine to use a port other than 5900, allow this through the Windows firewall, and then try to connect locally on the LAN. It might also fail under this condition.

Robert

[danny]

Tried changing the port and it did fail.  So TightVNC works and UltraVNC does not.  Intresting.

[danny]

I removed UVnc from my system and installed TightVnc and it fails with the following error:  "Error reading port number from file".  I put the VNC Server back on port 5900 reset the firewall and tested it locally using UltraVNC viewer and it connects but TightVNC will not from the TBA.

[jamwyatt]

Can you verify that it is the .vnc file that is the problem by verifying that you can enter the connection manually into TightVNC? If that works, and I expect it to, then it might just be a file format difference between UltraVNC and TightVNC.

Thanks,

Robert

[Brian Bergin]

The Windows firewall should be moot as if I VPN to a customer site I can VNC to any of their machines on 5900 with no problems so I don't see how it can't be an internal issue.

[Marcos Hernandez]

Probably a little silly and redundant at this point, but Danny, are you absolutely sure that on the client side you are pointing the session to port 11700 and not 5900?

[jamwyatt]

Marcos,

In my test, I was able to repeat Danny's problem and validate that the tunnel was being connected to in terms of security locking. It appears to be a bug in UltraVNC when not dealing with the default port 5900.

Robert

[danny]

Not quite following you Marcos, the server on the remote system is on port 5900, the port in the TBA connection setting is 5900.  I changed the port setting in the TBA device to 11700 and still got the same results.

[Michael Holloway]

Let me enumerate the scenario below, so that we are all on the same page:

VNC Client -----> Internet -----> Portal -----> TBA -----> VNC Server

where the VNC Client is on a different subnet/network than the VNC Server.

The steps to set up VNC should be:

1. Configure VNC Server, listening on port 5900 (for example, usually the default for server)

2. In the Portal, double-click the target device in the topology or dashboard, and check the Connections tab > VNC and verify that it is pointing at port 5900.

3. Press the Connect button. The Portal will give you a target URL and port to connect the VNC client to, probably in the port range of 11700 or higher. Copy this information by pressing the 'stick pin'.

4. Manually launch the VNC Client. Where it asks for the server to connect to, paste in the information just copied from the portal, in the form of xlx-00000000000.ciscovar.com:11700

Does this work?

-mike

[danny]

Michael,

Ok, your instructions were great and it works from both UVnc and TightVnc.  So is this the way it will be or is there a plan fix the other method.

[Michael Holloway]

I'm sure that some of us engineering folks will have a look at exactly what is upsetting UltraVNC, I can't say absolutely that we will make a fix for any specific VNC client as there are quite a few out there after all, but at least we can always fall back on the cut-n-paste method.

-mike

[jamwyatt]

The firewall reference I think you are referring to is for the server side of the connection, if you change the port from 5900 to something else to test the UltraVNC client connection to the server. The client side doesn't care, but the server is likely currently only opening port 5900 before the test? Maybe Windows is using some sort of dynamic FW these days and opens any port that privileged  apps open for listening?

Robert

[danny]

Yes I can connect using TightVNC manually localy.