This website was created by a team of veteran VNC users looking to help solve problems and answer questions you might have about VNC.
Hopefully you will either find the information you're looking for here, or even contribute some information that can help someone else.

Other great sources of help for VNC can be found here:

• The VNC Documentation pages at RealVNC
• The FAQ pages at RealVNC
• The original AT&T VNC FAQ pages
• Search the VNC mailing list archives

If you've searched through this Faq-O-Matic and still have questions, please join the VNC mailing list at the RealVNC website and post your question there.

VNC Basics

Flavors of VNC and VNC Add-on's

VNC and Firewalls

Special setup tricks for VNC on Linux/Unix

Troubleshooting Guides

SSH and Other Step-by-Step How-To's

If you've a FAQ to contribute, just post it into this repository for New Contributions.
One of the site admins here will review it for content and clarity, and then place it into one of the above Groups.

Thanks to all of the VNC-FAQ supporters who've contributed content, including:
Glenn Mabbutt, Jerry Westrick, Floyd Russell, Mike Miller, John Aldrich,
Jorge Zingg, Beau Haefke, Dave Gayman, Barry Zubel, Adrian Umpleby, William
Hooper and Richard Harris.

A special thanks also to the Teachers of America.

This site is hosted by Echogent Systems, Inc. purveyors of the freeware
applications Kaboodle and EchoVNC

Introduction to VNC

VNC stands for "Virtual Network Computing". It is a completely free, remote-control system developped by some brilliant chaps at AT&T Cambridge Labs.

It comes in two pieces: a Viewer and a Server. Install the Server on one system, and you can use the Viewer on another to remotely-control it across your network or even across the Internet. There are Viewers and Servers for most every operating system, even Windows.

Is VNC Secure?
Is VNC always this slow?
Can I remotely install VNC?
Changing a VNC password on a Windows PC
How can I hide the WinVNC tray icon?
Why won't VNC work on my new WindowsXP machine?
What's my IP address?
What do those "poll" options mean?
How can I force a remote VNC Server to restart?
What does the "Java.net:NoRouteToHost" error mean?
Why doesn't VNC work when the PC is locked?
What's all this about VNC and Windows' Terminal Services?

Yes and no.

The data travelling between a VNC Viewer and a VNC Server is not encrypted, so anyone capable of monitoring (aka, "sniffing") that network traffic can easily see what you're seeing.

That doesn't mean, however, that someone can easily sniff the password VNC prompts you for when you try to connect to a Server. For VNC uses a challenge-response authentication scheme, so the password itself never crosses the network. That's the good news.

If while you're using VNC, however, you type a password for an application running on the remote server, that password could be easily captured.

In general, VNC is not considered really secure whenever the data traverses a network that you are not completely in control of. So naked VNC use within a home or office LAN is usually considered "secure enough", while using VNC across the Internet, without additional security measures taken, is usually considered "reckless and ill-advised".

A great tip from http://perso.wanadoo.fr/samfd/esvnc/:

TIP: In order to get maximum refresh rate, responsiveness and
performances, it is necessary that you completely disable "Hardware
Acceleration" on the machines that run WinVNC (server). It can be done
in "Display Properties" Panel -> "Settings" Tab -> "Advanced..." Button
-> "Troubleshooting" Tab -> "Hardware Acceleration" Tab set to "None".
This makes a big difference, especially over LAN connections and even
with others VNC distributions.

Many times, a network admin will want to do a mass-install 
of VNC servers on their whole network, all using the same
password and port setting. For a Windows NT network, the
ideal utility for this is called "Fastpush" and you can get
it here:

    http://www.darkage.co.uk/

VNC passwords on Windows systems are a popular topic of confusion amongst 
VNC users. At times, you may try to change your password, but will find 
that your "old" one still works!

The most common pitfall is understanding the difference between the "Default" 
and "User" settings. The default settings should possibly be referred to as 
global settings. These are the settings inherited by VNC whenever it is 
started whether as a service or an application. 

However, VNC also allows for the assigment of unique VNC passwords for each
Windows user on a machine. These passwords are set by logging in as a windows
user, and setting the password in the user settings dialog box. 

A great explanation with a diagram is available at: 

http://www.floydsoft.com/vncauth.html 

Thanks to Floyd Russell for the contribution!

Another perspective from RP:
----------------------------

"I changed the password when I was logged in on the server machine, which 
is running W2K Professional.  Then I logged out. Now when I connect to it 
when no one is logged in, the old password works and the new one doesn't."

WinVNC keeps a separate set of settings for each user who is logged in, and
another set for when nobody is logged in.  (This is so that, e.g., when Mike
is at the machine, Tom can't take over and mess him up.)  You will need to 
change the Default password, which you access through the shortcut: 

   Start -> Programs -> VNC-> VNC Server -> Show Default Settings.

Another perspective from rich_at_nospam-darkage.co.uk
-----------------------------------------------------

As mentioned in a previous FAQ - Windows NT, 2000 and XP can have different
passwords for each users. If you want to remotely admin the PC with one 
single password you need to change this for the "default settings".

Solutions:

1) Drop into DOS and CD to the folder containing VNC (usually 
   program files \ orl \ vnc). Type winvnc -defaultsettings and press [enter]. 
   A GUI box will appear and you can now change the password for all users. 
   Now restart the VNC service (which will disconnect you if you're using it!)

2) Use REGEDIT and connect to the remote computer. Look for the key called: 
   HKLM\Software\ORL\Winvnc3\default. Change the encoded password to one from 
   a box that you know works (nb: you could delete any user account entries 
   that you don't want).

3) Use one of the vnc password tools and Xcmd / PsExec to change the password
   remotely.

4) Use the Fastpush script from www.darkage.co.uk :-)

Assuming that your users are on windows PCs, change the following 
registry value:

In HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3,
"DisableTrayIcon"=dword:00000001

This "registry hack" only works on some flavors of VNC servers,
but not all: TightVNC is supported, RealVNC is not. See here for 
the whole list of Flavors of VNC and VNC Add-on's.

Thanks to Nick Palmer for the contribution!

An alternative and more drastic measure to prevent the VNC
icon from appearing in the system tray is to modify the
a registry entry specific to Windows itself. Making a mistake
in here could prevent Windows from ever working correctly again, 
so please beware.

If VNC is running as a service, you can remove its service helper
key from the Windows registry. That is, via regedit, remove the 
"WinVNC" value which can be found in one of these:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
or
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
or
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Again, this is very risky. But it should work.

The third method of "hiding" the VNC tray icon requires some 
developers tools: using a resource editor, modify the WinVNC 
icon so that it will show the same icon both before and after 
a client is connected.

Thanks to Michael Roland for the contribution!

WindowsXP comes with a builtin "Internet Connection Firewall". It can 
sometimes get activated when you install other networking applications,
like a VPN client. When ICF is active, you won't be able to connect to
a VNC Server on your WinXP machine, though you will be able to start a
VNC Viewer on the WinXP machine to connect somewhere else.

Here's a link from Microsoft of how to turn it off:

http://www.microsoft.com/windowsxp/pro/using/howto/networking/icf.asp


If you don't have time or authority to go that route, have a look here:
How can I connect to a VNC Server that's behind an unconfigured firewall?

If you've installed the recently released "Service Pack 2" (SP2) for
Windows XP, you have automatically installed a new firewall on your
PC that might be blocking VNC connections. To create an "exception"
for VNC, follow these instructions:

   1. Click Start, click Run, type Wscui.cpl, and then click OK to open 
      Windows Firewall.
   2. Click the Exceptions tab, and de-select the "Don't Allow Exceptions"
      radio-button.
   3. Click Add Port to display the Add a Port dialog box.
   4. Enter port number "5900" or whatever port you've got VNC on that
      PC to listen on (port number = 5900 + "VNC Display Number").
   5. Select the TCP protocol.
   6. In the Name field, type "VNC".
   7. Click Change Scope to view or to set the scope for the port 
      exception, and then click OK.
   8. Click OK to close the Add a Port dialog box.
   
That should do it! More info here:

http://support.microsoft.com/default.aspx?kbid=875357#7

Another reason you might have difficulty connecting to a WinXP
machine is due to incomptability between the VNC Server and some 
special features of WinXP (see below for details). If you're 
having trouble connecting to a VNC Server running on WindowsXP, 
try one (or more) of these:

First, check that you haven't logged on as several different users
simultaneously. If you have (at any point since the machine booted), 
go to Task Manager->Users and check the "ID" of the Active session.  
If it's not zero then WinVNC won't work -- the "ID" of the Active 
session must be 0. Try connecting with VNC after you've rebooted
the WinXP machine.

Next, try disabling "Fast User Switching". WinXP uses Terminal Services
to implement Fast User Switching, and this Terminal Services isn't
compatible with the current versions of WinVNC.

Next, try disabling "Remote Desktop". That also uses Terminal Services,
and will be problematic as above.

Lastly, try disabling "Use the Welcome Screen". WinXP doesn't use
Terminal Services for the Welcome Screen, but some VNC users have
indicated that it helped them connect. Your mileage may vary.

At a high-level, here's what's going on: VNC can only remote a WinXP
console session when the session is "Active".  And the console in 
Windows XP is treated rather like a Terminal Services Client that by 
default is connected to the special "session zero".  Session zero is 
where all services run, so it's the one that the VNC service remotes. 
If you disconnect "session zero" somehow, say by using fast user 
switching or Remote Desktop, then it becomes unavailable via VNC. 
Thanks to "Wez" at RealVNC for the explanation!
               

In order for someone to connect to your VNC Server across the
Internet, they'll need a way to find you. The Internet has two
ways of doing this: first, most familiar, it uses "domain names", 
like "www.google.com" or "aol.com". When you type in an address
like that, the Internet relies on something called a Domain Name
Server (DNS) to translate that name into an actual IP Address
(see below). You too can get your own domain name, for free, with 
many "Dynamic DNS Providers". http://www.no-ip.com seems very 
popular with VNC users: just install their client on your VNC 
Server PC (Windows or Linux) and you're good to go.

The second more "direct" way of connecting with someone is to use
a numerical IP address. The trick is finding it out: with most dial
up or PPPoE DSL connections, your ISP address changes every time
you connect. To find out your current IP address "automatically",
just open a web-browser to http://www.whatismyipaddress.com. Then 
just tell that number to someone trying to connect with you, and 
you'll soon be connected.

When you setup your Windows VNC server, there are options regarding
"polling" such as "Poll Full Screen" or "Poll Foreground Window".
These options control the manner and rate in which the VNC Server 
sends screen updates to the Viewer, but it's not immediately clear 
what each of the options actually mean. Here are some good 
explanations taken from the VNC mailing list.

From Adam Pavelec [apavelec@benefit-services.com] :

"For VNC 'Update Handling', you can choose to receive full 
screen updates (which is very bandwidth intensive), or you
can choose to receive updates to the foreground application 
window (the window that's in 'focus' -- this i the default 
option in RealVNC), or yo can choose to receive updates for 
/only/ what's underneat hthe cursor.  AFAIK, 'Poll Console 
Windows Only' is especially useful for terminal session and
command/DOS prompt use."

From William Hooper [whooper@freeshell.org] :

Basically WinVNC (note the Unix servers are different) needs 
to "look" at the screen to send it over the network.  The "poll"
options tell WinVNC where to look:

Poll Full Screen       = "Look" at the full screen for changes
Poll Foreground Window = "Look" at the forground (selected) window 
                          for changes, etc.

Illtud Daniel [illtud.daniel@llgc.org.uk] :

Since Windows doesn't 'know' about VNC it won't tell VNC 
when something on the screen changes (unless you're using 
the UltraVNC video driver version). VNC has to poll something
(the videobuffer?) to see if there are any changes to transmit
to the client.

Polling is generally inefficent (since most of the time nothing
changes) and you have a tradeoff between polling frequency (doing
it all the time takes clock cycles) and responsiveness (if you
only poll every second, you're going to have quite a lag), buu
polling is often the only way to accomplish monitoring.

After password or remote registry changes to WinVNC you may want to restart 
the service.

Solution:

1) Create a batch file with the commands:

@echo off
Net stop winvnc
net start winvnc
"c:\program files\orl\winvnc" -servicehelper

Please note that the winvnc service name and path may be different under 
different VNC flavours (check your Services applet for more info).

2) Copy the batch file to the target workstation.

3) Use VNC and execute the batch file (this will drop your current session).
Alternatively use Xcmd or PsExec to run the file in a remote DOS window (NT, 
2000 and XP only).

Please note you should test this method before attempting it on a live system.

This error is very common when you are using the Web-Browser 
VNC Viewer client to connect to a VNC Server which is situated
behind a firewall/router.

There's not much you can do to fix it on the Viewer side of
the connection, except perhaps by trying to connect with the 
standalone VNC Viewer, rather than via a web-browser. To fix
the VNC Server side of the connection, see this FAQ:

How should I setup my firewall to work with VNC?

In Windows (NT/2000/XP), you can "lock" the desktop which requires a user 
to enter a password before they can use it. In such situations, it's 
common that the PC will accept VNC connections, but they won't work: you 
supply a password, and the session immediately closes.

To work around this, setup VNC to run as a "Service" on the PC. It's one
of the options you'll see in the "Start -> Programs -> VNC" program group.

Sometimes even if you have it running as a service, the connection will
immediately close or you'll get a "connection refused" message. To fix
this, you may have to either stop and restart the VNC service, or uninstall 
and then reinstall VNC. Typically one of these two approaches will fix 
the problem.                                                               

Thanks to John Aldrich (JAldrich-at-covista-dot-com) and Sean Echevarria
(Sean-dot-contact-at-creepingfog-dot-com) for the info!

There is a known incomptability between VNC and a special feature of 
the newest Windows flavors (eg, WinXP or Win2003 server) known as 
"Terminal Services" (aka, TS). At a high-level, here's what's going on: 
VNC can only remote a Windows console session when the session is 
"Active". And the console session in a TS-enabled Windows platform is 
treated rather like a Terminal Services Client that by default is 
connected to the special "session zero" -- session zero is where all 
services run, so it's the one that the VNC service remotes. If you 
"disconnect" this "session zero" somehow, say by using fast user 
switching or Remote Desktop, then it becomes unavailable via VNC. 

This doesn't mean you absolutely cannot run Remote Desktop and VNC at
the same time; some VNC users have reported that it works in their
environment just fine. As long as your use of Windows' Terminal Services
doesn't disconnect "session zero", VNC will work. The problem with this
guideline is that there is no good way to insure how Terminal Services
treats "session zero" every time for every user.

If you're having trouble connecting to a VNC Server running on Windows
XP or 2003, try one (or more) of the suggestions here:
Why won't VNC work on my new WindowsXP machine?

Thanks to "Wez" at RealVNC for the explanation!
               

A hallmark of VNC is that it is practically operating system independant:
you can find Servers and Viewers for almost any OS.

Another great asset of VNC is that it is open-source. When the original
AT&T development effort appeared to stagnate (circa 2000-2001), many 
independant developers took up the challenge and created offshoots: new
"flavors" of VNC, optimized in some way different from the original AT&T 
version.

Recently, the AT&T team re-launched themselves as the RealVNC team, and
are again actively developing and supporting the "original" VNC platform.
They do great work, but so do many of the offshoot maintainers. A quick
summary of all known offshoots is here.

Also listed here are some popular 3rd party "VNC Add-On's" that might make 
your VNC experience that much easier, or that much more secure.

List of Known VNC Flavors

Popular 3rd-party VNC Add-on's

Here's a list of known VNC flavors:

Original AT&T VNC

RealVNC

UltraVNC

TightVNC

EchoVNC

Windows-only:
eSVNC
ZVNC
LapLinkVNC
xVNC
Cayote VNC

MacOS:
OSXvnc
OS9vnc
ChromiVNC
VNCThing
CoTVNC

Linux and Other:

DirectVNC
Windows CE VNC server
PalmVNC 2.0
VNCViewer for PocketPC
SmartVNC for Microsoft Smartphone OS
SSHVnc
tkvnc
TridiaVNC

This is the original VNC application, used as a starting point for other variations. It is still hosted here, though the available download is kept current with what's available from RealVNC.

Generally speaking, all other flavors of VNC are compared against this one, to determine if those flavors are "fully compatible" or not.

EchoVNC is a full-featured version of VNC based on UltraVNC
with echoWare integration. 

With EchoVNC on both sides of a connection, two VNC users 
can connect to each other regardless of firewall or router 
configuration. VNC becomes "firewall friendly" -- no more 
port-forwarding!

EchoVNC uses the same EchoWare software that Kaboodle
uses. It is free, Windows-only, fully compatible with all flavors 
of VNC, and of course open-source. You can find it here:

            http://echovnc.sf.net

Note: EchoVNC is a product of Echogent Systems, Inc., which 
      hosts this VNC FAQ-O-Matic website.

eSVNC, or "Easy VNC" is a relative newcomer, but is very popular due to its great featureset. It is based on TightVNC 1.2.2, supports file-transfers, Server-Side Scaling (SSS), and includes some great speed enhancements. You can find it here. It's available only for Windows and, except for the special features mentioned above, is fully compatable with RealVNC.

The eSVNC developer has recently transitioned his efforts over to UltraVNC. So it is unclear if eSVNC is still being actively developped.

ZVNC is an experimental derivitave of two open source projects: VNC and 
ZeBeDee, a utility to set up encrypted, compressed tunneling between two 
hosts. It is possible to use ZeBeDee with VNC without using ZVNC, but 
doing so requires additional configuration of both client and server, and
inherently is less effecient and more prone to error than using VNC alone. 

ZVNC integrates encryption and compression into VNC, while remaining compatible
with both ordinary VNC and with configurations where VNC and ZeBeDee were used 
in combination.  Perhaps surprisingly, the compression component of the
combination is a significant improvement over VNC alone. 

Download the Binary distribution here, Windows only: 

               http://home.attbi.com/~davedyer/znc/zvnc.html

LapLinkVNC is a version of VNC which has integrated SSL support into 
the Windows VNC server and the Java Applet viewer.

The binary is available here:

https://www.mylaplink.com/html/s/public/client/laplinkVNC.exe

The source is linked from here:

http://www.laplink.com/products/lle/rc.asp

Note:  It will run standalone, however, it will generate a self-signed
certificate for the SSL session unless you provide it with a real
certificate.  The self-signed certificates will generate warnings
from your browser and the applet viewer requires a check box to be
checked in order to accept them. Just point a web-browser to
"https://servername:5800" and it connects.

xVNC is a Windows application that combines a remote-installer and a VNC
system all in one. With it, you can remotely install VNC onto a target 
machine and immediately connect to it. xVNC is, by default, deinstalled when 
you disconnect. Access is restricted, of course, to domain administrators.
If you're looking for a quick, unobtrusive way to VNC into to a Windows 
computer that doesn't have VNC installed, this is it.

Windows-only, open-source. You can get a copy here:

http://xvnc.sourceforge.net/

From the release notes:

This is mostly a bug fixed, performance improved, WinVNC version 3.3.6.
There are no major feature changes, and only one minor feature change.  As a
concession to useability, code for keeping the local client viewer open and
automatically resized upon changing the remote server screen resolution was
migrated from eSVNC/UltraVNC into this code.  Otherwise, the entire feature
set of WinVNC version 3.3.6 has remained unchanged.  I would have liked to
include TightVNC's local cursor handling, but that would have broken the VNC
viewers on other platforms.

Windows only, open-source. You can get it here:

binaries: http://www.coyoterd.com/WinVNC-336-patched-exe.zip
source: http://www.coyoterd.com/WinVNC-336-patched-src.zip

OSXvnc is, simply, a full-featured VNC server for Mac OS X. 

It's open-source and MacOS X only. You can get a copy here:

http://www.redstonesoftware.com/vnc/

OS9vnc is a full-featured VNC server for Mac OS9, based on
based on ChromiVNC from Jonathan Morton, and brought to you 
by the same people behind OSXvnc.

It's open-source and MacOS 9.x only. You can get a copy here:

http://www.redstonesoftware.com/vnc/

ChromiVNC is an implementation of a VNC Server which runs on Macintosh. 
It works well with the VNCThing VNC Viewer.

You can get it here: http://www.chromatix.uklinux.net/vnc/index.html

If you'd like the Drag Manager to work with this flavor of VNC, 
be sure to install vncpatches68k:

http://amcg.th.ic.ac.uk/~adrian/vnc/

These patches are needed by ChromicVNC on both 68k and PPC if 
you want the Drag  Manager to work.

Thanks to Lex Ein for the info!

VNCThing is a really good Viewer for the MacOS (8.x,9.x,OS-X).
It's fully compatable with the RealVNC server, it's free, and
it's open-source. You can get it here:

           http://www.webthing.net/vncthing/

"Chicken of the VNC", or CoTVNC, is simply a VNC Viewer for MacOS X. 
It includes speed optimizations, customizeable CPU throttling for the
frontmost and other connections, a manual Refresh command, and 
Tight encoding. It's a good compliment to OSXvnc, a MacOS X 
VNC Server.

It's open-source and MacOS-X only. You can get a copy here:

http://sourceforge.net/projects/cotvnc/

DirectVNC is a variant of a VNC Viewer specifically for Linux systems. 
Unlike other VNC flavors for Linux, DirectVNC takes advantage of the 
"linux framebuffer device", via the DirectFB library. This means that 
the VNC Viewer no longer needs to have a full-fledged X-server installed. 
Instead, the Viewer device can be running the relatively tiny DirectFB 
library: http://www.directfb.org, making DirectVNC suitable for 
deployment on small-footprint think-clients and embedded Linux platforms 
such as LEAF: http://leaf.sourceforge.net.

You can download a copy of DirectVNC here: 

            http://www.adam-lilienthal.de/directvnc/

This is a "bare bones" VNC server for Windows CE. Currently only 
uncompressed encodings are supported. It has been ported from the 
Original AT&T WinVNC version 3.3.3.r9 as part of a feasibility 
research project.

Open-source, find it here: http://sourceforge.net/projects/wincevncsvr/

PalmVNC is a VNC Viewer the Palm OS platform. It should work with
every standard VNC Server.

You can get it here: http://palmvnc2.free.fr/

From its website:

I have compiled the VNC client for the PocketPC by adapting the WinCE 2.x 
source. This is my first attempt to make the user interface PocketPC friendly, 
so it may still have some issues. This download is completely free, and is
available in ARM/Xscale, MIPS, and SH3 binaries. Please note this ONLY works 
on PocketPC devices. To install, copy the correct vncview.exe for your cpu 
type to the device. To uninstall, delete the vncview.exe on the device. 
Note: The Intel Xscale PXA250 (ARM) processor is supported. 

You can get it here: http://www.cs.utah.edu/~midgley/wince/vnc.html

SmartVNC is a VNC Viewer for Microsoft's Smartphone OS.

You can get it here: http://www.centacto.com/smartvnc.php

SSHVnc is a VNC viewer, written in Java, that combines the TightVNC
Viewer with an SSH client. With this app, you can login to your
target PC's SSH server and VNC Server at the same time, thereby
saving yourself one step in securing the VNC connection.

More info available here: http://3sp.com/products/sshtools/sshvnc/sshvnc-features.php

Thanks to gregb at ifost.org.au for the pointer:

There is a pure Tcl/Tk viewer as part of tcllib:

http://cvs.sourceforge.net/viewcvs.py/tcllib/tclapps/apps/tkvnc/tkvnc.tcl

It is convenient if you want to have a VNC viewer embedded inside another
application which supports TCL scripting.

Here's a list of some popular 3rd-party VNC Add-on's:

Fastpush is a Windows-specific script that can be used to remotely 
install WinVNC onto a large number of computers. These target
computers must be running NT, 2000 or XP, and you need admin rights 
to do this, but if you're looking for the best way to install VNC
into your whole LAN, this is it.

You can get a free copy here: http://www.darkage.co.uk/

With this tool you can manage your VNC connections.
The features are:

- - BuiltIn Viewer with support for Tight Encoding
- - Network Scanner to find VNC Servers on you LAN
- - Monitor your computers - so you can see whether a 
    host is online or not.

VNC Admin Console runs on all Windows Plattforms and is 
totally free for personal use.

You can download it on http://www.mast-computer.de

From the website:

"VNCon is an easy to use remote administration tool which allows you to 
connect, view and take control of any computers running VNC (Virtual Network
Computing) on your network. The list of computers can be obtained using 
various methods, either probing your domain, scan a set of ip ranges, or 
entering each computers details manually."

VNCon is Windows-only and not open-source. The IP scan for VNC is purported
to be very fast and very flexible. You can get a copy here: 

http://vncon.chronetal.co.uk/

VNC Commander provides a multi-connection manager with a 
builtin VNC viewer. Windows only, freeware:

http://www.amsoftwaredesign.com/vnccommander.asp

From the project's maintainer:

----------------------

VNC Manager is an easy to use remote administration tool which allows you to connect, 
view and take control of any computers running VNC or Windows Terminal Servers. It 
provides an easy to use intuitive GUI interface and unique features that can significantly 
improve the user productivity of network administrators. The list of features includes but 
is not limited to :

 - Latest RealVNC 4.0 and TightVNC 1.3 distributions are fully supported.
 - Thumbnail View allows multiple computers to be monitored on-screen at once.
 - VNC Manager has built-in support for HTTP and SOCKS5 proxies.
 - IP address and Windows domain/workgroup scan. Allows scan for active VNC servers.
 - Server Status scan. Checks from VNC server status. Can be started manually or set to update 
    server status via time interval.
 - VNC deployment wizard. Allows remote installation of TightVNC and RealVNC based servers.
 - External Tools. Allows to start an external application.
 - Can connect to Windows Terminal Server with a nicely integrated full featured built in viewer.
 - Start/Stop/Restart the remote Windows service.
 - Network administrator can reboot or shutdown remote computer.
 - "Reset Remote VNC Server Password" wizard. Allows you to mass reset password on a remote
    VNC servers.
 - Capture and save screenshot of remote VNC server screen.
 - VNC and RDP viewer window stretching.
 - Automatic search folders provide a quick filter for connected VNC and RDP sessions.
 - Send messages to other computers running Windows NT/2000/XP.
 - Default session. Allows to set default setting for newly registered servers.
 - Default password. You can specify a default password to connect with, or a specific one for 
    each connection.
 - Active sessions can be viewed in the separate windows or in Tab view panels.
 - VNC Manager does not require VNC Viewer to be installed. It uses an ActiveX VNC Viewer 
    control developed by SmartCode Solutions.
 - VNC Manager can send Wake-on-LAN "magic packet".

--------------

It's Windows-only and not open-source. You can get it here:

     http://www.s-code.com

From Steve Bostedor:

VNCScan was the first scanning and management application for VNC.  Since
version 1 was released in 1997, TGCS has been committed to innovating new
features that save you time and frustration.  This is a $30 shareware
application with full commercial support.  The free Microsoft DotNet framework
and MDAC 2.7 are required.

With VNCScan, you can:

* Scan up to a class A address space
* Check the status of a single computer without a rescan
* Scan multiple ranges per group of computers
* group scan ranges into logical structures
* Remotely deploy VNC to NT/2L/XP desktops with FastPush script
* Configure the FastPush script with a GUI
* Start and stop the remote VNC service
* Reboot the remote computer
* Ping the remote computer
* Export computers to HTML
* Check the version of VNC on enabled clients
* Find who is logged into enabled computers
* Connect to Windows file shares on remote computers
* Move computers (drag and drop) between groups
* Manually add computers to groups
* Keep track of status of computers with visual effects

You can get a copy here: http://www.vncscan.com

This program uses VNC to create a dual-monitor effect. So if you have two 
or more computers on your desk and you are tired of having several keyboards 
and mice around to control them, this is the program for you. While running 
this program, you can move the mouse pointer beyond the right or left edge 
of your primary display and the pointer will appear on the other computer 
screen. If you have ever used x2x or a computer with two graphics cards, you 
get the idea.

It's open-source and available for both Windows and Unix.

Windows: http://fredrik.hubbe.net/win2vnc.html
Unix: http://fredrik.hubbe.net/x2vnc.html

Kaboodle is a LAN Management and LAN-to-LAN connectivity tool that
builds upon VNC's capabilities. With Kaboodle, you can:

* quickly and continously discover all VNC Servers on your LAN
* remotely install VNC onto PC's that aren't yet running it
* securely tunnel your VNC connections
* securely transfer files 
* setup a LAN-to-LAN connection, and then access all of the VNC
  Servers on your partner's LAN

Kaboodle is free, open-source, and Windows-only. Get it here:

                http://www.kaboodle.org

Note: Kaboodle is a product of Echogent Systems, Inc., which hosts
      this FAQ-O-Matic website for VNC.

VNC is a client-server networking system, and their operation will interact with Internet firewalls which have come into widespread use.

This section of the FAQ site is dedicated to VNC's interaction with firewalls and other elements of network security.

What do I need to know about routers?

What TCP ports does VNC use?

What UDP ports does VNC use?

How should I setup my firewall to work with VNC?

How do I configure my WinXP firewall to work with VNC?

What about my "software-based", or "personal" firewall?

How can I tell if my firewall is setup correctly?

How can I get a VNC Viewer to connect through a firewall I don't control?

How can I connect to a VNC Server that's behind an unconfigured firewall?

Can I use SSH with VNC to bypass a firewall?

Why does VNC suddenly stop responding due to ZoneAlarm?

What's the *Easiest* solution to VNC and firewalls/routers?

Routers are essential to the operation of the Internet and to the
networks that connect to them. For most Internet activity, like
web-browsing and emailing, you don't need to worry about them at
all. But for a remote-control application like VNC, it's important
to have a basic understanding of what they do.

A router (doesn't matter whether it's a "software based" router like 
the ICS program for Windows, or a "hardware based" router like a
LinkSys or NetGear box) simply acts as a "translator" between one
network and another. These two networks (e.g., a LAN and the Internet)
can be distinguished by the IP address range each side uses. When a 
device on one side of the router needs to exchange data with a device 
on the other side of the router, the router automatically performs a 
real-time translation back-and-forth between two IP address. 

So if you have a PC on a LAN, think of it as having both an "internal" 
IP address as well as an "external" one that your router conceals from
you. When data moves around just within your LAN, it uses just the 
internal IP addresses. But if you want someone from across the Internet 
to exchange data with one of your PC's (e.g., you want to let someone 
connect a VNC Viewer to one of your VNC Servers), they need to contact 
you using your "external" IP address, not your internal one.

There are whole ranges of IP address that are specified to be "internal 
only"; the 192.168.x.y range is the most common example. Many routers 
simply translate one external IP address to several internal IP addresses, 
so that many PC's can now share one Internet connection. In general, this 
is called "NAT"; in Windows it's called "ICS"; in Linux it often goes
by "IP Masquerading".

And while it's pretty easy to see what your internal IP address is (in
VNC, just put your mouse cursor over the VNC Server icon in the service
tray and it'll show you), figuring out your external one can be tricky.
Not only does your router translate that external IP address before you 
ever see it, but that external IP address technically "belongs" to your
ISP, and they could change it on you every 15 minutes if they wanted to. 

As many new VNC users experience, all of this makes it difficult to connect
to a VNC Server running on a PC that's behind a router. But...given the 
security risks of connecting a Windows PC directly to the Internet...this
"inconvenience" of a router is actually a pretty good feature. Mercifully,
connecting "out" from behind a router is fairly transparent -- once the
router is working, all Internet activity that's initiated from "behind" 
the router (e.g., web-browsing, checking email, etc.) should simply work.

To allow someone to connect to your VNC server that's behind a router, the
most direct way is to adjust the router's "port forwarding" settings. Every
router (software, hardware, doesn't matter), allows in some way to "forward"
or "map" a connection from the external side "across" the router into the
protected internal side. That is, you explicitly tell the router that any
connections arriving on (say) TCP-port 5900 on the external side should be 
forwarded to the PC on the inside at IP address 192.168.0.1.

Once you've setup this "port forwarding" for VNC (it uses TCP port 5900 for 
the data connection), you can test it out. Startup your VNC Server, and 
open a web-browser on that PC, and connect it to:

http://www.GoToMyVNC.com

That scan will show you what your external IP address is at that instant, 
and if it can connect, then a VNC Viewer can connect as well.

By default, a VNC server will listen for connections from a VNC viewer on TCP port "5900+N", where N is the "Display Number" (usually just zero). So a VNC server setup for Display-0 will listen on TCP-5900, Display-1 is TCP-5901, etc.

Additionally, the VNC server will listen for connections from a web-browser on TCP port "5800+N", where N is as above. If you point a web-browser to this port, the VNC server will automatically provide a Java VNC viewer that runs right in your web-browser. This Java Viewer will then exchange data with the VNC Server on the same ports a normal VNC Viewer would use: "5900+N".

Lastly, if you start a "server-initiated connection" to a Listen-mode Viewer (this is a pretty advanced mode), the connection will be to TCP port "5500+N" on the Viewer.

If you've administrative control over your firewall/router that 
protects your collection of VNC servers, setting up the firewall 
so that any or all of your VNC servers are accessible from the 
outside is fairly straightforward.

Suppose, for example, you have 5 PC's, all of which are running VNC 
servers, and you want to be able to access them from the "outside".
You'll need to make 5 "port forwarding" entries:

1. External TCP port 5900 to your first PC's port 5900
2. External TCP port 5901 to your second PC's port 5900
3. External TCP port 5902 to your third PC's port 5900
4. External TCP port 5903 to your fourth PC's port 5900
5. External TCP port 5904 to your fifth PC's port 5900

Then if you point a VNC viewer to your external IP address, "Display 0" 
will reach your first PC, "Display 1" will reach your second, etc.
Keep in mind the relationship: "Display N" = "TCP port 5900+N".

If you wish to connect with the web-browser client, you'll need to
make three additional adjustments. First, apply similar port-forwarding
rules for TCP ports 5800-5804 (ie, 5800 to your first PC, 5801 to
your second PC, etc). Secondly, change the "destination" TCP port
on all of the entries to be the same as the "arrival" TCP port (so
instead of 5902 to 5900, make it 5902 to 5902). Lastly, change each
of your VNC Servers to listen to the correct "Display Number" (eg,
for the PC being forwarded 5902, have it listen to "Display 2").
If this is not setup correctly, you'll get a "java.net:NoRouteTohost" 
error when you try to connect.

        One user's experience in getting this all to work is described
here: How to get VNC to work behind a router

If your WinXP PC is running "Service Pack 2" (SP2) you probably
have a built-in firewall active. You'll need to deactivate it in
order for your PC to accept VNC connections. Details here:

Why won't VNC work on my new WindowsXP machine?

A "personal firewall" is simply a software application which
runs on the PC that it's protecting. Similar to a hardware
firewall, its job is to block incoming connections to the
services running on your PC. This, of course, includes
blocking VNC connections.

The next few paragraphs describe some popular software-based
firewall applications, and details how to get VNC to work
with them.

WindowsXP comes with a builtin "Internet Connection Firewall". It can 
sometimes get activated when you install other networking applications,
like a VPN client. When ICF is active, you won't be able to connect to
a VNC Server on your WinXP machine, though you will be able to start a
VNC Viewer on the WinXP machine to connect somewhere else.

Here's a link from Microsoft of how to turn it off:

http://www.microsoft.com/windowsxp/pro/using/howto/networking/icf.asp

Another popular "personal firewall" product is Norton Internet
Security, or "NIS". It too will prevent VNC Viewers from
connecting to the VNC Server it is protecting.

Unlike other personal firewalls, just telling NIS to allow connections
to port 5800 and 5900 will not enable VNC. According to Symantec's own
Technical Support:

"The problem with VNC connections is caused by information filtering on 
port 80 by Norton Internet Security (NIS). To solve this problem, 
temporarily remove port 80 from the list of ports scanned by the firewall.
Removing port 80 will cause ad blocking and privacy controls to function
improperly. After you are finished using the Internet-based application,
add port 80 back to the list of ports filtered by NIS.

To remove port 80:

1. Open NIS.
2. Click Options > Norton Internet Security > Firewall tab.
3. Under the HTTP List, click 80 > Remove > OK.

To add port 80:

1. Open NIS.
2. Click Options > Norton Internet Security > Firewall tab.
3. Under the HTTP List, click Add.
4. In the dialog box type 80.
5. Click OK to close all open windows.

If you need further assistance, please do not hesitate to contact us."
  - NIS Technical Support

It can be frustrating to debug a firewall setup while you're
*behind* that firewall. With some firewall/routers, even 
if you have the firewall's port-forwarding for VNC setup 
correctly, you may not be able to connect a Viewer to your 
Server, using the "real world" external IP address that you 
just (tried to) enable. This will result in the cryptic but
popular "error 10061" if you try it.

Fortunately, there's an easy solution. Just open a web-browser
on your PC that's the VNC Server you want to test, and point
it to http://www.GoToMyVNC.com, and run that scan. If
this scan can detect your VNC Server, then your firewall is
setup correctly.

Talk about a FAQ! Something very much like this appears at least once 
a week on the VNC mailing list:

"I'm at a work on my office PC. It's connected to a LAN that's behind
a firewall and a web proxy that I know nothing about. The IT guys
setup my web browser and email so that they work. But, I have a VNC 
server running at home, and when I start a VNC Viewer and type in my
VNC Server address, I get "connection failed" errors. How can I 
connect to it?"

The usual first response to this is more instructional than helpful:
if the IT guys at your workplace don't allow VNC Viewers to work behind
their firewall, they might have a really good reason. If you accomplish 
any "tricks" to bypass their security, you might just find yourself in
hot water with your employer. So ask permission first.

Once you have permission, the easiest way is do it like this: setup a
SSH tunnel between your work PC and your home PC. Many SSH clients are
HTTP-proxy aware, including the very popular PuTTY SSH client. Follow
these instructions for setting up an SSH tunnel with PuTTY, just be 
sure to add the correct "Proxy" information into the "Connection"
settings of PuTTY:

Using PuTTY's SSH on Windows

The above example presumes that the VNC Server is running on Linux, but
it of course works perfectly well if you're running on Windows too. Once 
you've got this setup correctly, your VNC Viewer traffic will pass right 
through your workplace firewall and proxy, just like your Web browser 
traffic does.

This FAQ is almost as popular as:
How can I get a VNC Viewer to connect through a firewall I don't control?

Here's the usual situation: someone that you offer tech-support for
(a school, a parent, a prison inmate) is on a LAN that's behind a
firewall they'd love to setup correctly, but email still confuses
them, and you're not about to ask them to "port forward TCP 5900".
But you still want to connect to their PC with VNC to help remotely
administer their system.

This is exactly what the VNC Server "Add Client" command is meant for.
With this command, the world is turned upside-down: the VNC Server 
initiates a connection to an awaiting VNC Viewer (ie, a Viewer setup
to be in "Listen Mode"). Once connected, the person on the Viewer
side is immediately connected, just like a "normal" VNC session (only
without the password challenge).

The "add client" connection from the Server to the Viewer uses TCP 
port 5500 instead of port 5900 like a "normal" connection does. This
almost means that everything you know about SSH tunnelling can also
be applied to "Add Client" connections. Groovy.

One more thought about listen-mode connections: it requires that someone
or something at the VNC Server side of the connection initiate the session.

So suppose you have a PC at work, behind a corporate firewall that you do
not control. You can setup a VNC Viewer in Listen-Mode at your home, and
then use software such as "Windows Scheduler", to run something like this 
every minute/hour/day:

"c:\...\RealVnc\WinVNC -connect my.home.ip.address::5500" 

In this way, your work-PC will attempt to connect on a regular basis to
your home-PC, giving you VNC control over a PC behind a firewall.

For detailed SSH setup help, see:
How to setup an encrypted tunnel (eg, SSH) for my VNC connection

Thanks to Adrian Umpleby (a.umpleby at imperial.ac.uk) for this suggestion:

As discussed elsewhere in this FAQ-o-Matic, SSH can be used to securely
tunnel a VNC connection. So if you can run an SSH client on your VNC Server,
you can setup a tunnel that bypasses the firewall protecting your server.

The key is to use a "remote port forward", or "reverse tunnel", initiated
beforehand from an SSH client running on the target VNC Server. You'll need 
to connect that SSH client to an external machine which is running an SSH 
server. This SSH server should be any machine that can easily be reached
by the VNC Viewer machine (it can even be the VNC Viewer machine itself).

Once the tunnel is created, you simply point your VNC Viewer to the tunnel
endpoint you created on your SSH Server, and the data will find it's way
back through the SSH tunnel to the SSH client, and so into the VNC Server.

For example: suppose your VNC Server is setup to listen to "Display 1", and
it has an SSH client installed. Suppose it's also setup to "AllowLoopback" 
connections. From your VNC Server, startup the SSH client with the command:

ssh -l username -R 5901:127.0.0.1:5901 SSH-server-address

Note especially the "-R" switch for "Remote Port Forward". This is instead 
of the more common "-L" switch for "Local Port Forward" used in SSH tunneling.

Once that connection is established (you'll of course be prompted for
username's password on the SSH-server), startup a VNC Viewer and connect it
to Display 1 on the SSH-server: "SSH-server-address:1". That will find its
way thru the tunnel to the VNC Server.

As you can see, it's not for the faint of heart. But it works.
             

ZoneAlarm is a type of firewall called a "personal firewall". That is, it's
a piece of software which runs on the PC that it's protecting. 

ZoneAlarm has a feature which intercepts all VNC keyboard and mouse inputs 
whenever a ZA window is active.  This can be caused by an alert box popping 
up on the VNC Server, or by a user on the VNC Server activating the ZA 
control panel.  Once this happens, VNC behaves as if it is in 'view only' 
mode -- the user on the VNC Viewer can see the windows on the VNC Server, 
but can no longer control them.  

If and when someone closes the ZA windows on the VNC Server machine, control
will be returned to the VNC Viewer.  Until then, no amount of reconnects 
will regain remote control of the server.

This 'feature' of ZoneAlamr can be turned off in ZoneAlarm as follows:

- Open ZA control window
- Click the 'Firewall' tab
- Click the 'Advanced' button near the bottom of the tab window
- In the 'Advanced Settings' window, turn on the option titled 'Disable 
  Keyboard and Mouse Protection'.
- Click 'OK'.

ZoneAlarm has other advice for VNC users here:

http://www.zonelabs.com/store/content/support/zapProgramsFAQ.jsp

Forgive the slight self-promotion here. :)

If you use EchoVNC on both your VNC Viewer side 
and VNC Server side, you can connect one to the other
across the Internet without any firewall or router
adjustments whatsoever.

No, really. Have a look here:

http://www.echovnc.com

While the largest numbers of VNC users are likely using it with
Windows, VNC is an ideal remote-desktop application for *nix
(ie, Linux or other Unix flavor) environments too.

This category details some special VNC setups germaine to these
unix systems.

How to setup a Linux VNC Server with KDE or Gnome

How to setup VNC to work with Inetd on *nix

How can I get VNC to start automatically at boot time?

Another approach to getting VNC to start at Boot

Setting up seperate X sessions for multiple users

The default desktop for the VNC Server is "TWM", though most people are used to KDE or Gnome instead. Here is how to change it:

1. Edit ~/.vnc/xstartup
2. For KDE, replace "twm &" with "startkde &"
3. For Gnome, replace "twm &" with "exec gnome-session &"
4. Kill any existing VNC servers with "vncserver -kill :xxx" where xxx is the display number.
5. Start a new server.

Setting up VNC via Inetd
========================

Intro:
=====
The idea here is to setup a *nix server (this example uses
SuSE 8.1 Linux with the KDE windows manager, but the concepts 
hold for other flavors of *nix) so that a VNC Server is 
automatically started when a VNC Viewer connection attempt 
is detected. Once this works, you can use a VNC Viewer to open
a fully-functional window to the target system, starting with 
a normal login prompt.


Installing the software
=======================
VNC:
---
The version of VNC shipped with SuSE is a rather conservative version,
and although it works, better versions are available on the iternet.
So, get/use the RPM packages from one of those in the usual way... 

NOTE: You must uninstall the default SuSE VNC version before installing 
the newer one!

AutoCutSel:
----------
There is an additional program called "autocutsel" that allows cut 'n
paste to work between a windows vncviewer and a unix vncserver.  This
program needs to be copied to the directory /usr/local/bin.  To use the
program, you must start it by hand, with the following command:
"autocutsel &".  This starts the program, and sends it to the
background.


Configuring SuSE
================

/etc/services
-------------
Edit the file /etc/services
The file is ordered by port number.  So the following lines should 
be inserted at the appropiate place:

vnc640          5950/tcp       # tiny
vnc800          5951/tcp       # small
vnc1024         5952/tcp       # normal
vnc1280         5953/tcp       # large
vnc1600         5954/tcp       # X-Large

/etc/inetd.conf
---------------
Edit the file /etc/inetd.conf
Almost at the end of the file (before the "# End." line) add the
following lines:(Note: Each of the following line start with "vnc" 
and ends with a "geometry" parameter, but due to email 
restrictions the lines have been split in 2!  SO you must put 
the lines back together!)

vnc640 stream tcp nowait nobody /usr/bin/Xvnc Xvnc -inetd -query
127.0.0.1 -once -depth 16 -geometry 640x480
vnc800 stream tcp nowait nobody /usr/bin/Xvnc Xvnc -inetd -query
127.0.0.1 -once -depth 16 -geometry 800x600
vnc1024 stream tcp nowait nobody /usr/bin/Xvnc Xvnc -inetd -query
127.0.0.1 -once -depth 16 -geometry 1024x768
vnc1280 stream tcp nowait nobody /usr/bin/Xvnc Xvnc -inetd -query
127.0.0.1 -once -depth 16 -geometry 1280x1024
vnc1600 stream tcp nowait nobody /usr/bin/Xvnc Xvnc -inetd -query
127.0.0.1 -once -depth 16 -geometry 1600x1280

NOTE: The above presumes you've installed Xvnc into the /usr/bin
directory. If it's installed somewhere else (ie, type "which Xvnc"
to find out), then change the above lines accordingly...

Now you can restart the inetd deamon with the command:
"/etc/init.d/inetd restart" (without the "" marks, of course)

Note: I used to set the geometry to "screen size -- window frame size",
to allow you to have a window that takes up your entire screen, and does
not have a scrolling bar.  The newer versions of VNC now have a full
screen mode that allow you to use the entire screen, (without frames)
which works better than my method.  So the above geometry figures 
implement the newer method...


Yast2 parameter modifications
-----------------------------
In Yast2-.>System->Sysconfig Editor 
change DISPLAYMANAGER_REMOTE_ACCESS to yes
change DISPLAYMANAGER_STARTS_XSERVER to no  <--- no GUI on console
change KDM_SHUTDOWN to root
change KDM_GREETSTRING to "Westrick & Associates" <-- (your co. name)
then click "save"


Using the new configuration
===========================
In order to use the new configuration you need to first re-enter 
"init level 5". Do this by executing the following 2 commands as root:
init 3
init 5

Remote Root Login
=================
By default remote login as user root is not allowed.  In general 
this is a good security feature.  But in my case where the 
server is not protected from within, and only ssh is allowed from
without, this is both a needless precaution and a bothersome feature.
To allow remote root logins, save the following line in a file called
/etc/rc.config.
ROOT_LOGIN_REMOTE=yes


Testing your modifications:
==========================
1) Try connecting with vncviewer to server:50 to server:54 to see if all
is well, 
2) look at the console on server to see if it is nolonger graphical, 
3) and finally in the login screen try "shutdown" (It should require the
roots password!).  

4) Additionally, start autocutsel and test cut 'n paste across vnc!


Thanks to Jerry Westrick <jerry@westrick.com> for the post!

(this example is taken from a Solaris environment)

Here's how to setup the usual startup/stop script approach used by other
Solaris programs to get VNC to start at boot time.

First become root.  Then create a file called /etc/init.d/rc.vnc with the
following content (modified appropriately, see below):

---------------start file on next line--------------------
#!/bin/sh
#
# Startup/Stop script for vncservers for some users.
#

case "$1" in

'start')
   /bin/su - bob -c "/usr/local/bin/vncserver :1"
   /bin/su - sally -c "/usr/local/bin/vncserver :2"
   /bin/su - jim -c "/usr/local/bin/vncserver :3"
   ;;

'stop')
   /bin/su - bob -c "/usr/local/bin/vncserver -kill :1"
   /bin/su - sally -c "/usr/local/bin/vncserver -kill :2"
   /bin/su - jim -c "/usr/local/bin/vncserver -kill :3"
   ;;

*)
   echo "Usage: /etc/init.d/rc.vnc { start | stop }"
   ;;

esac
---------------end file on previous line--------------------

The names bob, sally and jim are usernames.  Modify accordingly.  The
corresponding numbers :1, :2, :3 for VNC may also need to be changed.

Make sure that /etc/init.d/rc.vnc has the correct ownership/permissions:

# chown root:other /etc/init.d/rc.vnc
# chmod 744 /etc/init.d/rc.vnc

Next create symbolic links to that file as follows:

# cd /etc/rc0.d
# ln -s ../init.d/rc.vnc K40rc.vnc
# cd /etc/rc2.d
# ln -s ../init.d/rc.vnc S99rc.vnc

That should do it.  I've been doing it this way for years and it works
great for me.  I'd rather not add things to inetd.conf when I don't have
to.

Thanks to Mike Miller for the Contribution!

Answers in this category:

TightVNC and Redhat use a method similar to Mike Miller's.  
One advantage to this setup is that users are kept in a seperate file.

Please note: this script needs to be set executable or it won't work:

% chmod +x /etc/init.d/vncserver

To create a symbolic link for it to run at startup, try:

% chkconfig --level 5 vncserver add

Thanks to David Pascoe (dp at ii.net) for the info!

Contents of /etc/init.d/vncserver:

#!/bin/bash
#
# chkconfig: - 91 35
# description: Starts and stops vncserver. \
#              used to provide remote X administration services.

# Source function library.
. /etc/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

VNCSERVERS=""
[ -f /etc/sysconfig/vncservers ] && . /etc/sysconfig/vncservers

prog=$"VNC server"

start() {
    echo -n $"Starting $prog: "
    ulimit -S -c 0 >/dev/null 2>&1
    RETVAL=0
    for display in ${VNCSERVERS}
    do
        echo -n "${display} "
        unset BASH_ENV ENV
        initlog $INITLOG_ARGS -c \
            "su ${display##*:} -l -c \"cd ~${display##*:} && [ -f .vnc/passwd ] && vncserver :${display%%:*}\""
        RETVAL=$?
        [ "$RETVAL" -ne 0 ] && break
    done
    [ "$RETVAL" -eq 0 ] && success $"vncserver startup" || \
        failure $"vncserver start"
    echo
    [ "$RETVAL" -eq 0 ] && touch /var/lock/subsys/vncserver
}

stop() {
    echo -n $"Shutting down $prog: "
    for display in ${VNCSERVERS}
    do
        echo -n "${display} "
        unset BASH_ENV ENV
        initlog $INITLOG_ARGS -c \
            "su ${display##*:} -c \"vncserver -kill :${display%%:*}\" >/dev/null 2>&1"
    done
    RETVAL=$?
    [ "$RETVAL" -eq 0 ] && success $"vncserver shutdown" || \
        failure $"vncserver shutdown"
    echo
    [ "$RETVAL" -eq 0 ] && rm -f /var/lock/subsys/vncserver
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|reload)
        stop
        sleep 1
        start
        ;;
  condrestart)
        if [ -f /var/lock/subsys/vncserver ]; then
            stop
            start
        fi
        ;;
  status)
        status Xvnc
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|condrestart|status}"
        exit 1
esac

--------------------
Contents of /etc/sysconfig/vncservers:

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the line below to start a VNC server on display :1
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.  
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see
# URL:http://www.uk.research.att.com/vnc/sshvnc.html.

# VNCSERVERS="1:myusername"
VNCSERVERS="1:bob 2:sally 3:jim"

A great article on this, written from a RedHat Linux perspective, is here:

http://www.sourcecodecorner.com/articles/vnc/linux.asp#vncserver.inetd

You've installed VNC and tried to connect, but it didn't work. Nuts.

These contributions describe some general things to try.

Can you "ping" the VNC Server from the Viewer machine?
Are the Viewer and Server on the same LAN?
Are you sure the VNC Server is running?
Can you get to the VNC password prompt?
Is the VNC Server restricting connections?
If all else fails...

Since VNC connections travel over the same IP networks that any other
sort of Internet connection does, it's a good idea to verify that the
network connection between you Viewer and Server is working. That's
what the "ping" command is good for. In Windows, open up a DOS Command
line and type:

      ping [ip.adddress.of.Server]  (eg, "ping 192.168.0.10")

...and see if it works correctly. If you can't get a ping connection
to work, it's unlikely that you'll be able to get a VNC connection to
work.

Life is much easier to debug if the VNC Viewer and VNC Server
are on the same LAN. If they are not, there's probably a firewall
protecting one or both of the systems. See this category of FAQs
for some advice: VNC and Firewalls

Sometimes, despite the best of intentions, it's hard to tell if 
the VNC server is running at all. Here are some ways to check
to see if it is:

1. On Windows, look for a VNC icon in the Taskbar tray. Position
   your mouse cursor over the icon, and it should report what IP
   address the VNC Server is running on.

2. On Windows, try running the "fport" utility. This will report
   all of the running servers and what port they are listening to.
   If you see VNC listening to port "590#" then you know it's
   accepting connections on VNC Viewer Display "#". So, if you see
   5905, then the Server is ready to handle "Display 5".

3. On Linux, check with lsof to see what's running (run as root):
   linux-box# lsof -i -n -P | grep -v 127.0.0.1
   See #2 above for what it means when you find something.

4. Lastly, try this: from another PC on the same LAN as the VNC
   server, open a telnet client and connect to the VNC ports:
   "telnet ip.address.of.server 5900". If you see a response which
   looks like "RFB 003.003" then the VNC Server is working.

Perhaps the easiest way to check if a VNC Server is running is
via the http://www.gotomyvnc.com service scan. Give it a try:
just open a web-browser on your VNC server and see if it works.

If you start a VNC connection from your Viewer and get as far 
as getting to a VNC password prompt, you're 90-percent of the 
way there. Usually the problem at this point is simply not
entering the right password. Which sounds ridiculous...until
you consider that a Windows VNC Server may have *two* passwords
set on it! See this category for an explanation of that strange
situation: Changing a VNC password on a Windows PC

A VNC Server can pretty easily be setup to accept connections only 
from specific IP addresses. If you're trying to connect from a 
different IP adddress you'll have trouble -- you're supposed to.

On a Windows VNC Server look for VNC registry keys such as:

HKEY_LOCAL_MACHINE\Software\ORL\WinVNC3\AuthHosts
or
HKEY_LOCAL_MACHINE\Software\ORL\WinVNC3\LoopbackOnly

See http://www.realvnc.com/winvnc.html#4 for details.

On a Linux VNC Server, check for entries in the "hosts.deny" file
or in the packet-filter scripts.

If all else fails, collect your answers to the other suggestions
in this category, and post your question to the VNC Mailing List.
You can subscribe here:

http://www.realvnc.com/mailman/listinfo/vnc-list

Please note...you'll look a little ridiculous if you ask a question
on that list that's already covered on this site. Not that it's not
your perogative to look ridiculous if you want to, of course, I'm
just saying...

How to setup an encrypted tunnel (eg, SSH) for my VNC connection

How to install VNC on Win2K

How to get VNC to work behind a router

On its own, the data exchange between a VNC Viewer and a VNC Server is in
"plaintext", so that anyone who can monitor (aka, "sniff") your network traffic
can see what you're seeing.

Fortunately, there are several standalone utilities which can be used to setup
encrypted tunnels between the VNC Viewer and Server. By telling VNC to use these
tunnels, instead of using a direct connection, your VNC data is now as secure as
any other data in the tunnel.

Using SSH or OpenSSH
Using PuTTY's SSH on Windows
Using Zebedee
Using Stunnel
Using Kaboodle
Using EchoVNC

Thanks to Barry Zubel, barry@zubel.co.uk, for this great answer to "what's all
this about sniffing, anyhow?".

------------------------------------------------------------------------------

For those of you interested in this 'ip sniffing, tunnelling and SSH'
stuff, here is a brief description. I'll try to give analogies
as-and-where I can.

For the normal, insecure, end-user (of which most of us in reality are),
the chances that your VNC connection will be 'sniffed' is pretty small.
Sniffing is basically a fond term given to the inspection of TCP-IP
packets as they cross over the internet.

We all know that the Internet is an interconnected network of networks.
Imagine, if you will, that it is actually the same as a country-wide
postal service.  Each TCP-IP packet is routed to-and-from the
destination by passing through various routers/networks.  Liken this to
your 'postcard' (TCP-IP Packet) being sent to a far destination has to
pass through your local mailbox (router), then the sorting office
(another router), then across the country by some means (another
router), and then through a remote sorting office (you should be
starting to get the idea), and then to the destination.

'Sniffing' your packet is the same as the postie at the other end
reading the back of your postcard before he delivers it. (In actual
fact, it could be a postal worker in ANY part of the chain).

To get around this problem, some geeky people (geeky being used fondly -
I regard myself as a geek!) out there developed something called SSH.
SSH is a method of 'end-to-end' encryption, which still passes over the
internet, but the information is scrambled so that it is illegible to
all but you and the destination. This would be the same as writing the
postcard in some secret code that only you or the destination
understand.

Now to the 'tunnel' part.  Once you have initiated an 'SSH connection',
it can be used to 'tunnel' lots of different types of information to the
host, in a secure way.  There are lots of different ways to achieve this
which I will not go into here, suffice to say that once this 'tunnel' is
operative, you can send any sort of data up-and-down it.

This is a difficult thing to think of an analogy for. Just believe me
that this 'tunnel' is pretty secure, and is not susceptible to 'sniffing'.

Fortunately, the original VNC developers created some great pages 
describing this task in detail. You can see it here:

http://www.uk.research.att.com/vnc/sshvnc.html

The essence of that How-To is this: to open an SSH tunnel from 
your machine to a VNC server, you need two things:

1. An SSH client on the VNC Viewer side of the connection
2. An SSH server on the VNC Server side of the connection.

Note that the the SSH client machine does not have to be the same 
as the VNC Viewer machine; likewise, the SSH server machine does 
not have to be the same as the VNC Server!

Start the tunnel from the SSH client side like this:

ssh -l username -L clientport:host:hostport SSH-server-address

After this tunnel connects, any data that goes into "clientport"
on the SSH client will go into the tunnel and then emerge from 
the SSH-server destined for port "hostport" on "host".

For example, suppose your SSH client is not the same as your VNC
Viewer, but the SSH Server is the same as the VNC Server. Also,
suppose your VNC Server was listening on "Display 2". The command 
to setup a tunnel for this case is:

ssh -l username -L 5902:127.0.0.1:5902 SSH-server-address

Now if you point a VNC Viewer to Display 2 on the SSH client, you 
will connect to the VNC Server. Note: since the SSH Server and
VNC Server on the same machine, you will need to enable the
"AllowLoopback" setting on your VNC Server.

Another great OpenSSH setup tutorial specific to WinNT can be found here:

http://www.ece.utexas.edu/~luo/winvnc_ssh.html

Thanks to Peter Coulter (peter at coulter.ndo.co.uk) for the info!

From John Aldrich:

I'd like to propose that you either host or link to  
http://www.benjamin.weiss.name/putty-tunnel.html

This is an EXCELLENT tutorial on how to configure PuTTY for SSH 
tunneling VNC. I just couldn't understand how to tunnel SSH until 
I saw this....

(thanks to John for the contribution!)

>>> This content is stolen^H^H^H borrowed directly from the Zebedee pages at 
http://www.winton.org.uk/zebedee/manual.html (just scroll down to the
"Use with VNC" down in "Examples"). <<<


One of the reasons behind writing Zebedee was to use it over dial-up lines 
with VNC. VNC is a free system to provide remote display capabilities using 
a “remote frame-buffer” concept. You can use it to display Windows desktops
remotely or, with an “Xvnc” server to access an “X desktop” from any VNC 
client machine, or even a Java-enabled browser! 

The supplied sample server configuration file server.zbd has sample target
statements (commented out by default) that are configured to allow redirection 
of ports 5900-5999 which will allow tunnelling of VNC sessions. This file can be
used on both UNIX and Windows but note that on Windows you must set the
“AllowLoopback” flag in the registry in order for tunnelling to work. Saving the
following snippet (without any leading spaces) in file and then importing it into
regedit will do the trick:

 REGEDIT4

 [HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3]
 "AllowLoopback"=dword:00000001

 [HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3\Default]
 "AllowLoopback"=dword:00000001

You will find a file with these contents in the Zebedee distribution by the name
vncloopback.reg. Having set these registry entries then the file vncviewer.zbd
can be used to invoke a VNC viewer tunnelled to the host named on the command
line. Here are the contents of the file vncviewer.zbd:

------start on next line---------------------------------------
 #
 # Zebedee configuration file to start up a tunnelled VNC session
 #
 # Usage: zebedee -f vncviewer.zbd remote-host:vnc-port
 #

 verbosity 1         # Basic messages only

 server false        # It’s a client
 detached true       # Detach from terminal

 message "Starting VNC viewer"

 # On Windows systems you might use the following:

 command ’"c:\Program Files\ORL\VNC\vncviewer.exe" localhost:%d’

 # On UNIX systems you might use the following:

 # command ’vncviewer localhost:%d’

 compression 6       # Request normal Zlib compression
--------end------------------------------------------------------

So using this file as follows:

 zebedee -f vncviewer.zbd somehost:5901

will start a VNC viewer tunnelled to the VNC server on somehost port 5901 
(the server you would usually refer to in VNC-parlance as “somehost:1”).

VNC also supports a Java viewer. If the server is running on port 59xx then 
the viewer can be downloaded via port 58xx. However, it appears that the Java
viewer communicates the main VNC port number to the client. So, to tunnel traffic
when using the Java viewer you must make sure that the local and remote
ports use the same numbers. So, for example, to tunnel traffic to a VNC server
using port 5901 you should do something like:

 zebedee 5801,5901:remotehost:5801,5901

This will be problematic if you already have a VNC server running locally on 
port 5901, but you can usually arrange local and remote VNC servers so that 
there is no clash.

There is one last point worth mentioning. If you are using compression with VNC
it is worth experimenting a bit with the VNC protocol encoding. I have found that
“raw” encoding often compresses best and sometimes gives better performance with
Zebedee over slow links. But, as they say, your mileage may vary!

Here's a great article which essentially covers everything about
setting up VNC to work well with Stunnel in a Windows environment:

http://www.securityfocus.com/infocus/1677

Stunnel is a program that allows you to encrypt arbitrary TCP connections 
inside SSL (Secure Sockets Layer), and is available on both Unix and Windows.
Stunnel enhances the security of non-SSL aware servers and protocols (like 
VNC), by providng good transport encryption for the data.

The following text is lifted from http://www.stunnel.org/examples/vnc.html

Definitions: 

Server    The machine on which you'll run a VNC server. You'll be viewing 
          this machine's desktop somewhere else. 

Client    The machine at which you wish to sit, launch a VNC client, and 
          view the remote (server) desktop. 


server$ stunnel -d 7777 -r 5901         # recieve from 7777, route decrypted
                                        # packets to local vncserver

server$ vncserver :1                    # start vncserver on first
                                        # screen (port 5901)

client$ stunnel -d 5901 -r server:7777  # tunnel vnc to server

client$ vncviewer localhost:1           # connect to local stunnel process

Thanks to MikeS for his details on using Stunnel between Windows machines:
--------------------------------------------------------------------------

Below is what I have setup using Stunnel 4.04 on Windows

The machine that is running the server only needs to map the port
used by the stunnel (in this example 7777) to the VNC port 5900.

The client machine maps local port to VNC servers thru the stunnel port
(again port 7777 in this example). I have is setup to use 127.0.0.1 or
127.0.0.1:5900 to go to one server, and 127.0.0.1:5901 to go to a totally
different server. 

All the files are just downloaded, and it seems to work fine. I don't know 
how to create the stunnel.pem files, so just have it using the one from the 
site.

[Server STUNNEL.CONF FILE - MAPS STUNNEL PORT to VNC PORT]

 client = no
 cert = stunnel.pem

 [vnc]
 accept = 7777
 connect = 5900

[Client STUNNEL.CONF File - Setup to be able to work with 2 VNC servers]

 client = yes
 cert = stunnel.pem

 [vnc]
 accept = 5900
 connect = xxx.xxx.xxx.xxx:7777
 [vnc2]
 accept = 5901
 connect = 192.168.0.8:7777

[Files in Directory from Stunnel.org]

LIBEAY32 DLL     1,379,459  12-31-02 11:54a libeay32.dll
LIBSSL32 DLL       476,329  12-31-02 11:54a libssl32.dll
OPENSSL  EXE     1,089,536  12-31-02 11:54a openssl.exe
STUNNEL  EXE        59,904  01-12-03  4:54p stunnel.exe
STUNNEL  PEM         1,690  02-28-03 12:24a stunnel.pem

Kaboodle is arguably the easiest VNC-securifier because it
automatically wraps your VNC connections into a secure tunnel
without asking you for any IP addresses or TCP port details.

With Kaboodle, you can also connect two LANs together, and
then connect to *all* of the VNC Servers on the far side, 
using the one connection. In this sense, it's sort of a "VNC
Proxy".

You can learn more here:  http://www.Kaboodle.org

Note: Kaboodle is a product of Echogent Systems, Inc., which hosts
      this FAQ-O-Matic website for VNC.

As described elsewhere in these FAQ's, EchoVNC allows
two VNC users to connect with each other regardless of
firewall or router configurations on either side.

In addition to making VNC "firewall friendly", EchoVNC can
be used to securely encrypt the VNC data connections. To
activate this feature, simply place the "libeay32.dll" file from
the OpenSSL package into the EchoVNC installation directory.
That will activate end-to-end 128-bit AES encryption of the 
VNC data.

FLOYD RUSSELL'S GENERIC WIN2K VNC CONFIG PROCEDURE

Floyd Russell posted this to the VNC-List as a procedure he figured out 
for installing VNC on Win2K over a Win2K Terminal Services connection.
Interestingly, it seems to be the perfect answer for installing VNC on 
Win2K under any conditions:

 1. Install VNC
 2. Install VNC Service
 3. Start->Programs->VNC->Run WinVNC(AppMode)
 4. Enter your password, this is for the current user.
 5. Start->Programs->VNC->Administrative Tools->Show Default Settings
 6. Enter your password, this is for the local machine
 7. Close WinVNC
 8. Start WinVNC Service
 
 You may need to start the service helper if you want to modify settings 
 of the winvnc instance running. This problem is due to the way Terminal
 Services operates, since you are working in a virtual desktop.

Thanks to Dave Gayman, dgayman@rcn.com, for this great summary of "getting
VNC to work" (ie, making a VNC server behind a NAT'ing router accessible from
the Internet) behind a router on his home network:

------------------------------------------------------------------------------

Subject: How I, a newbie, got VNC to work across the Web with SOHO
firewall on cable modem

In this list there regularly pops up a cry for help:  "I can't reach my home
computer using VNC via the Web" -- that is, with the Java-enabled browser.

Reading answers in the archives here and from many a Web search gave me
only partial clues here and there, because I don't understand what a NAT
is, what tunneling is, or what is meant by IP address, gateways, dynamic
DNS or other terms casually flung about.  Of course, I should not be trying
to do anything along this line, but there you are:  I wanted to work my
home computer when I was on the road.

The solution to my problem turned out to be multi-fold.  (My problem was
this:  I could reach my primary home computer via browser anywhere on any
of my home-based local-area network machines.  However, I could NOT reach
my primary home computer when using a browser on any machine outside my
home LAN.)

Unlayering the problem like a cosmic onion resulted in the following:

1.  The Java viewer in VNC -- no surprise -- needs Java.  Microsoft has
stopped including Java in Internet Explorer because someone yapped at them
and they took their baseball bat and went home.

So, if you're using a late-model IE, you probably have to download Java
from Sun.  Sun has finally shielded us from having to know what "Java
virtual machine" means by automating the process at
http://www.java.com/en/index.jsp

2.  My SMC Barricade router/hub/firewall whatever-the-heck-it-is, which I
threw into my cable modem setup to save me from nasty people and then later
turned into a LAN by adding other computers to it, had to be told that VNC
is OK to let through.

For the Barricade, this is done by going into the configuration utility,
clicking on "Virtual Server" (no idea what that means) and indicating
"Service Ports" of 5800 and 5900 for the IP address of the primary home
computer.  The latter is easily found by hovering your mouse over the VNC
icon in the little tray at the bottom of the screen.  Owing to confusing
chatter in various places, I also added Service Ports 5801 and 5901, but I
have no idea why.

3.  The browser running the Java viewer has to be told the IP address of
the SMC Barricade, NOT THE IP ADDRESS OF YOUR HOME COMPUTER as all the VNC
docs tell you.

As a way of torturing you, this turns out to be ABSOLUTELY NOT the same as
the IP address that the SMC Barricade tells you it is, if your cable ISP,
like mine, assigns you a dynamic IP address -- that is, one that can change
at the whim of the ISP provider.  I don't know how the ISP does this, and I
don't care.  I found mine through a helpful guy at my ISP's phone-based
technical support.

4.  The solution to reaching this dynamic IP is, of course, "dynamic
DNS."  I think this is a named (or numbered) Web address -- an address you
choose -- that maps itself to your actual IP address, even when the latter
changes. The practical result is that on any computer anywhere, you can
enter an unchanging (non-dynamic) URL in the address line of your browser
and still talk to yourself, regardless of where you have gone as the result
of your ISP futzing with your IP address (probably called 'dynamizing' it).

The free dynamic DNS service from No-IP works for me (No-IP Free at
http://www.no-ip.com/index.php).  There are others that you can pay for and
probably these have advantages.  I was not able to discern what they are.

5.  This whole thing, I'm told, is unsafe because nasty people can "sniff
your packets."  I hope this does not mean what it appears to mean
(something akin to what those ill-trained pet dogs do to your
trousers).  To keep baddies from sniffing, apparently, you have to "tunnel"
via "SSL."  If and when I understand what that means in the IBM-clone
world, I'll be back with an update.

Point 1 took me several hours to find out.
Point 2 took me 3 days to work out
Point 3 took an additional day
Point 4 took half a day
Point 5 is still unresolved and I'm still just a dog watching television on
this one. (ed: maybe this will help: 
How to setup an encrypted tunnel (eg, SSH) for my VNC connection)


Dave

If you have a VNC question, don't post it here as it may go unanswered for a few days.
Instead, ask those here.

Just click here to post. Try to give your contribution a good Title so it's easy to spot.

New Contributions Folder

If you have a VNC question, don't post it here as it may go unanswered for a few days. Post those here instead: http://www.realvnc.com/mailman/listinfo/vnc-list

Here's the List of New FAQ Contributions:

First New Item
Second New Item
3rd Item
New Item
VNCViewer for MacOSX available at http://homepage.mac.com/kedoin/VNC/VNCViewer/
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item
New Item

This is just a test of the whole system.

Hey, it works!

This is just a test to see if Validation is working still.