Firewall VNC Client

Connect to your VNC Server with a client that uses HTTP proxy to connect through a firewall.

Harmen van der Wal
harmen.wal@tip.nl
Document Version 0.6, December 16th, 2000
Patch Version 0.1, June 12th, 2000

Introduction

VNC clients need to be able to connect out to ports >5900. So you may run into trouble if you're behind a firewall. One solution is to use HTTP proxy to connect through the firewall. I made a patch to the VNC Java software, which let you do just that.

VNC stands for Virtual Network Computing. If you don't know what that is, check the VNC site.

Disclaimer

This comes with ABSOLUTELY NO WARRANTY! In particular, but not limited to, damages resulting from compromised network security. I am by no means a reliable expert. Having a restrictive ISP just taught me a few new tricks.

Copyright

Except for the firewall piercing bit, all credits go to the VNC people. The patch is to the VNC 3.3.3 Java Viewer Source Distribution Copyright (C) AT&T Laboratories Cambridge.

How you can use this patch

First: simply use the applet hosted at this site with your Java capable browser (or maybe with an appletviewer for easy security settings). Use a form to get the HTML you need.

Second: you can download the patched Java client vncviewer.jar and run it as an application (if you have a JDK or JRE installed on your system) or use it to host your own client as an applet.

Third: download the patched sources vncviewer.java and rfbProto.java and do some hacking yourself.

About Firewalls

There are two types of firewalls: IP packet filtering firewalls and proxy firewalls. In the first case, you have a direct connection to the internet, but some traffic is not allowed to pass through. In the second case, you have no direct connection to the internet, and must connect through a proxy server, that gets the data for you. The latter type can be transparent or not. In case of a transparent proxy the client need not know about the proxy, otherwise it needs to be configured to use it.

This patch can handle both packet filtering firewalls, and HTTP proxy firewalls, and if needed on top of each other.

In the first case, it uses a HTTP proxy that is beyond the firewall, to connect to the server indirectly. This should work if combined with any form of transparent proxy, such as IP masquerading (have tried) or with SocksCap (haven't tried that myself yet though)
In the second case it uses the LAN HTTP proxy you're supposed to use to connect to the internet anyway. In case you have a packet filtering firewall on top of that, it uses a second HTTP proxy, that is beyond the firewall.

HTTP proxies can tunnel any application protocol, requesting an SSL connection with CONNECT host:port HTTP/1.0, as long as it's solely TCP based. VNC is TCP based:-)
I got the idea from HTTPort by Dmitry Dvoinikov.

What about applet security restrictions?

It's a pity that when an applet is loaded through a proxy, it knows nothing about that, and doesn't attempt to make network connections using that same proxy. Goes for both browsers and appletviewers.
So any connection through a proxy has to be coded (unless you can use some kind of transparent proxy). That's what I did for HTTP proxies.

You may have heard about applet security restrictions preventing applets to make network connections to hosts other than the one it came from. So how can the applet make a connection to some proxy host, when it's hosted on an entirely different webserver? Well it's done by simply loading the applet explicitly through the same proxy you want it to connect to later. The codebase in the applet tag looks like this:

codebase=http://proxyhost.proxydomain.net/-_-http://applethost.appletdomain.net/directory

The key is the "-_-" sign. Frankly, I was surprised this worked. It means an applet can make any TCP connection you want, once you load it through a proxy, be it only if you make those connections through that same proxy.

Unfortunately the only HTTP proxies that can do this that I know of, are Delegate proxies. I know it doesn't work with Squid.

That's not a problem if you only have to bypass packet filtering: you can choose any free internet HTTP proxy you like, so choose Delegate. Maybe you know another proxy that can do the trick: let me know!

But if you must use your LAN's proxy, the applet hosted at this site can't connect to that, unless you change your security settings.
With an appletviewer that's easy to fix, you'll need a JDK. You could also choose to run the client as an application with the JDK or JRE, and don't be bothered by Java Security at all.
In both cases you'll have a less mobile client, if that's of any importance. Maybe it will be more convenient to host the applet yourself, if your HTTP proxy and webserver are running on the same machine.

If all HTTP proxies could do the trick, then we would have a perfectly mobile solution. Now we don't:-( Note that for packet filtering firewalls we do:-)

So what do I do?

For use of the applet you need the right HTML. The un-patched client uses HOST and PORT as parameters for the VNC host to connect to. In case no host is specified, it gets the codebase of the applet. I have added the following:

PROXYHOST1
PROXYPORT1
PROXYHOST2
PROXYPORT2

All of these may be omitted, depending on what you need.

Remember to get the applet codebase right, to be able to connect to the proxy without adjusting Java security settings, if that's possible for your setup.

Here's an example that I used to connect to my Workspot account through my ISP's packet filtering firewall.

< APPLET codebase=http://proxy.spaceproxy.com:80/-_-http://www.workspot.net/~harmen/vnc code=vncviewer.class archive=vncviewer.jar width=800 height=600 >
< PARAM name=HOST value=www.workspot.net >
< PARAM name=PORT value=50442 >
< PARAM name=PROXYHOST1 value=proxy.spaceproxy.com >
< PARAM name=PROXYPORT1 value=80 >
< /APPLET >

I would need the following from my Windows machine; nachtschade is my Linux box, where Squid lives. I would use an appletviewer, with adjusted security and proxy settings.

< APPLET codebase=http://www.workspot.net/~harmen/vnc code=vncviewer.class archive=vncviewer.jar width=800 height=600 >
< PARAM name=HOST value=www.workspot.net >
< PARAM name=PORT value=50442 >
< PARAM name=PROXYHOST1 value=nachtschade >
< PARAM name=PROXYPORT1 value=3128 >
< PARAM name=PROXYHOST2 value=proxy.spaceproxy.com >
< PARAM name=PROXYPORT2 value=80 >
< /APPLET >

Another option would be to host the client with Apache on the Linux box. You figure it out.

I use http://proxy.spaceproxy.com a lot, so pay them a visit to see what they can do for you.

Here's a form that can get you the right HTML.

With use of the client as a Java application: just pass the parameters as command line options.

java vncviewer HOST www.workspot.net PORT 5901 PROXYHOST1 proxy.yourdomain.org PROXYPORT1 3128 PROXYHOST2 proxy.spaceproxy.com PROXYPORT2 80

Workspot

For use with your Workspot account, get a password and your PORT first. Quoted form Workspot Help:

Go to the "Linux desktop" page to see that you have at least one active desktop.
In the URL line of your browser, insert the characters "_pass" to turn something like http://www.workspot.net/cgi-bin /ws_vnc.cgi?id=12345678.1234567 into http://www.workspot.net/cgi-bin /ws_vnc_pass.cgi?id=12345678.1234567 and then hit return.
In the newly loaded page, enter your desired native vnc session password. (Can be different than your WorkSpot account password.)
Copy down the port number (from the first column of the table shown) of the Linux desktop that you wish to natively connect to. Let's assume it was 50933.

Experimental

I've been trying to solve the Java security problem with the applet... experimental

Feedback

Mail your suggestions, comments and questions to:
Harmen van der Wal
harmen.wal@tip.nl.

URL:http://www.workspot.net/~harmen/vnc/