The Problem
Usually VNC-clients and -servers use a proprietary protocoll (rfb-protocoll) on user-defined ports (e.g. 5900) to communicate through a bidirectional channel. This works well as long as client and server have a direct link (no proxies or firewalls in between) or the VNC-user has full control over all components involved. But in typical real-world scenarios we have no control over firewalls (usually opening only a few well-defined ports and blocking proprietary protocolls) and we have to deal with proxies (sometimes giving the client indirect internet-access only). Therefore VNC will often not work in such real-world scenarios.
The modified viewer works with Internet Explorer 5 (or newer) and with
Mozilla using the SUN JavaPlugin (other browsers may work as well, but are not tested. Opera 6.1 is known not to work)
If you want to use multi-session support, you need Apache and it's rewrite-engine (rewrite_mod; see INSTALL in downloaded file for details).
This version requires a CMU Common Lisp environment. If you don't have CMUCL and don't want to install it: try our java version: see (B)
Download CMU Common Lisp and install it on your machine.
Download the forwarder (lisp
source + binary), unpack it, and follow the instructions in the
INSTALL file. The "forwarder" is the server-part of HttpTunnel4vnc. Download the jforwarder (java
source + binary), unpack it, and follow the instructions in the
INSTALL file. The "forwarder" is the server-part of HttpTunnel4vnc. The viewer is heavily based on tightVNC 1.2.6 (see README) and has an
additional required applet-parameter:
This parameter is required in all cases. The RFB protocol is
tunneled on a connection to this port. The firewall (on the
client side) must not block this port. Setting TUNNELPORT to -1,
disables HTTP tunneling. Setting PORT to -1 forces HTTP
tunneling.
The Solution
HttpTunnel4vnc solves this problem by tunneling VNC's proprietary rfb-protocoll over HTTP. Almost all (protocol-filtering) firewalls are configured to be open for HTTP. Furthermore firewalls typically open the ports 80 and 443. In scenarios with clients placed inside a local network (often with a non-public IP) and internet-access only through HTTP-proxies, HttpTunnel4vnc will provide a working solution too.
Features
Requirements
The HttpTunnel4vnc server runs at least on GNU Linux/x86 (other
java-capable plattforms are possible, but not tested).
Installation
Server:
There are 2 versions available (choose one of them):
(A) Lisp Version: forwarder 1.5
This is our production version, which is well tested.
(B) Java Version: jforwarder 0.2
This is a re-implementation in Java - not well tested but no errors known.
Client:
Download and compile the modified viewer (java source).
--> TUNNELPORT
Value: TCP port number of the forwarder (server)
Default: none.
1. make clean; make all
2. java VncViewer HOST "myhost" PORT -1 TUNNELPORT "4567"
(note: no "-jar .." option used)
Prices
We do not charge fees for private use, but ask you to follow the following points:
License(s)
HttpTunnel4vnc is published under a BSD-style License.
VncViewer (java client) is published under the GPL.
Contributors
Helmut Eller | Lead programmer: he has done most of the coding (especially all the hairy stuff) - network expert and lisp guru |
Christoph Rettig | Testing and programming hints - java expert and dog owner (dog's-name: "Pepe", dog-size: x-small ;-) |
Martin Eller | Project coordination and marketing - responsible for all the rest |
The development of HttpTunnel4vnc has been sponsored by "Eller & Partner Unternehmensberatung KEG", Austria, Vienna.
Referrences