comp.os.linux.networking

I am confused why you would use stunnel arg '-r 5801'
when you started the server with 'vncserver :5'

So I think that stunnel arg should be '-r 5905', i.e. port
5905 is the port your VNC server is listening on.

The 5900+N port is the VNC server and the 5800+N port is
the mini http server port for delivering the applet html
and jar file. Since you serve both of those up by your
own webserver, there is no need to have stunnel redirect
to a 5800+N port.

I don't think your choice of 5835 causes, a problem but I
changed it to 5935 and it all worked fine like this:

vncserver :5

stunnel3 -f -d 5935 -r 5905 -p ~/.vnc/certs/server.pem

point firefox to http://hostname/vnc.html

where vnc.html is like your file but with the changes I
mentioned (i.e. PORT 5935)

BTW, The failure with httpd: get 'check.https.proxy.connection'
should be OK: it it just the applet doing a test connection
to look for a the presence of a webproxy.


For some people it might be easier to use SSVNC and x11vnc
in SSL mode:

http://www.karlrunge.com/x11vnc/ssvnc.html

http://www.karlrunge.com/x11vnc/#faq-ssl-tunnel-int

where one might start x11vnc like this:

x11vnc -ssl SAVE (connect to console
display :0 )

x11vnc -ssl SAVE -create (create a virtual X session
with Xvfb)

x11vnc -ssl SAVE -redirect localhost:5 (redirect to Xvnc on
display :5 )

SSVNC can then connect to these using SSL.

If instead you want to use a web browser with Java
viewer, supply '-http' option to x11vnc and it will
serve up the SSL VncViewer.jar (or use '-httpdir dir'
to explicitly point to the classes/ssl subdir contents).
Then point your web broswer to http://hostname:5800 or
https://hostname:5900 (note the different ports).