Socks support

[skanga]

Is it possible to connect via a socks server? If so what is the syntax/method to do this?

[dcommander]

You are trying to use the TurboVNC Viewer behind a firewall to connect through a SOCKS server to a VNC server outside the firewall? It might be as simple as setting JAVA_TOOL_OPTIONS=-DsocksProxyHost={socks_host} -DsocksProxyPort={socks_port}, replacing {socks_host} and {socks_port} with the TCP hostname and port of the SOCKS server. I have not tried that, however.

[dcommander]

If that doesn't work, then please provide more information to help me understand your setup. For instance, how would you normally connect to the TurboVNC host through SSH?

[skanga]

Thanks. I'll try it.

[skanga]

Tried it. Did not work. Got a dialog saying "Could not connect: Connection timed out: no further information"

I have a socks service and ssh service both on host "gateway" The socks service is on port 1080 (and ssh on port 22)

This is how I can connect via ssh ssh -J gateway user@remote-host

[dcommander]

Why do you need to use SOCKS? If you are able to use the gateway as an SSH jump host, then the -via option in the TurboVNC Viewer should work.

[skanga]

This gives error:

Security type not supported

[dcommander]

Are you using the TurboVNC Server? How did you start the server?

[skanga]

No. Using RealVNC server. Is that the problem?

[dcommander]

Probably. When RealVNC decided to take their code fully proprietary and closed source, they effectively created a hard fork with open source VNC implementations, cutting themselves off from any enhancements that have been made to GPL-licensed implementations since then. Those enhancements include:

• The performance enhancements to Tight encoding that I made, which produced the TurboVNC encoder that TigerVNC also uses (I don't think RealVNC even supports Tight encoding)
• VeNCrypt, an open source set of RFB encryption and authentication extensions
• The RFB flow control extensions, which allow VNC to perform decently on high-latency networks (unsurprisingly, RealVNC didn't perform well over high-latency networks the last time I checked, but that was admittedly years ago)

RealVNC has implemented its own proprietary set of RFB security extensions, since they can't use VeNCrypt, so that's probably why their server and the TurboVNC Viewer can't agree on a security type. The RealVNC Server should still support basic VNC password authentication, which is part of the core RFB spec, but maybe they have disabled it by default (because VNC password authentication uses an insecure form of encryption.)

Unless there is a compelling reason to use the RealVNC Server, I would strongly advise you to use the TurboVNC Server with the TurboVNC Viewer. Otherwise you're going to be limited to the intersection of the VNC features that both RealVNC and TurboVNC support, which is essentially just the slow encoding types and insecure authentication methods that are part of the core RFB spec. RFB was originally intended as a universal protocol, but the core protocol hasn't evolved, in part because of the aforementioned hard fork. RealVNC historically maintained the core protocol, but they have had no impetus to evolve it since they went proprietary. Instead, they have evolved their implementation through proprietary and opaque extensions, and the open source community has evolved our implementations using GPL-licensed extensions that RealVNC can't use. Thus, VNC compatibility is effectively limited outside of VNC implementation families. TurboVNC and TigerVNC try to be fully compatible with each other. TigerVNC adopted TurboVNC's encoder, and TurboVNC adopted TigerVNC's flow control extensions. Both adopted QEMU's and VMWare's keyboard extensions and VeNCrypt. LibVNCServer has TurboVNC's encoder and decoder, so it should perform similarly over a LAN, but since it lacks the flow control extensions, it won't perform well over high-latency networks. TurboVNC and TigerVNC can process everything that the TightVNC Server can send, but because TightVNC never adopted TurboVNC's performance enhancements, the performance won't be great when using the TurboVNC Viewer with the TightVNC Server. The UltraVNC Server uses TurboVNC's encoder, but they have yet another set of RFB extensions (including security extensions) that no one else supports. (At least theirs are open source, so it would be theoretically possible for us to support them.)

If there is a compelling reason to use the RealVNC Server, such as a feature that they have and we don't, then let me know.

[skanga]

Thank you for the impressively detailed response. I truly appreciate it. I will definitely try the TurboVNC server. It will take some time tho. Feel free to leave this issue open or closed at your discretion.

[dcommander]

I assume that that will fix the issue. The fact that you were getting a "Security type not supported" error means that the viewer was able to connect to the server. If you still encounter problems after switching to the TurboVNC Server, please add another comment.