Name: Alfred Chang
Course: CSE523/524
Professor: Tzi-cker Chiueh
CSE 524 Project Report
Secure Remote Access to Home Desktop
1
Introduction
The goal is to be able to access a home desktop behind a firewall from a remote
machine while putting the least possible burden on the client and providing as much
functionality as possible. Multiple clients must be able to access the same desktop and
share control, and the actual scheduling of control is left up to the users. I have come up
with a solution that requires port forwarding on only two ports, and allows any desktop
with a standard Virtual Network Computing (VNC) Server running to be accessible. The
client is a web-based applet served from a gateway host behind the firewall and
configured with a standard a HTML form and an Active Server Page. My solution allows
a client on behind a firewall to access a remote desktop behind a different firewall, even
if both test firewalls use Network Address Translation (NAT).
Web Based Client
The client used is a Java applet that allows any user with a Java enabled browser
to use the remote desktop functionality. This is preferred over a standalone client, as it
does not require any installation on the client host. The client can be accessed by first
contacting the web server running on the gateway host, and requesting vnc.html which
contains a form that allows the setting of the window size and internal IP address of the
host to be controlled remotely. The form has an ASP page as its target which will process
the form and serve a Java applet client with the proper settings. Options can be set within
the applet for shared desktop view (multiple remote users on the same desktop). The user
then types in the password for the remote desktop and clicks connect. The passwords are
set individually on each of the home desktops within the VNC Server. The password is
secure since it is never transmitted over the network but rather used as a key in the Data
Encryption Standard (DES) algorithm to generate a series of challenges and responses
between the server and client. The applet itself is a modified version of the VNC applet
called Firewall VNC Client found at http://www.xs4all.nl/~harmwal/vnc/readme.html.
The client side browser must have JRE 1.4.2 or greater.
Gateway Server
A standard VNC applet would served from the remote desktop that it will be used
to contact. It is limited to this desktop as a result of Java applet security restrictions, thus
one applet cannot be used to access multiple remote desktops. The problem is that we
need to access various desktops within a fire-walled network (including Network Address
Translation based networks), but we have only one point of entry (at the firewall). Since
we want to limit the number of ports opened and forwarded on the firewall, we need a
server that will act as a medium for communication between a client applet and the
remote desktop it wishes to access. This server is called the gateway server.
The gateway server has a web server (IIS) running that serves the Java client
applet and form. The Java applet is only allowed to connect to the gateway server itself,
and so it requires an agent to relay its traffic to the destination remote desktop as well as
2
traffic from the remote desktop back to the client. This service is provided by
TCPReflector. TCPReflector is a separate server that the client applet establishes a
connection with. TCPReflector then establishes a connection with the desired remote
desktop and relays TCP traffic between applet and desktop. The applet clients cannot
make remote desktop connections to the gateway server itself using this method.
The port that TCPReflector listens on is set on the command line when it is
invoked. Only two ports are forwarded from the firewall to the gateway server, one for
the web server, and one for the TCPReflector server. In the case of the TCPReflector
server, external port 5902 (default external port value) is forwarded to whatever port
TCPReflector is listening on, on the gateway server. TCPReflector is a modified version
of the TCP relay server found at http://locutus.kingwoodcable.com/jfd/java/tcp/tcp.html.
VNC Based Solution
VNC software is maintained at www.RealVNC.com and is open source and
available free under the GNU General Public License. There are versions for Windows
9x/2000/NT/XP, Linux, Solaris 2.5, MacOS X and other platforms. VNC Server must be
installed on the desktop to be accessed, and the password is set within the server. The
view on the VNC Server must be set to 2 (corresponds to port 5902). VNC is chosen
because it is widely supported, cross-platform, and open source. Since it has a Java applet
client, it can be used by virtually any type of machine including personal desktop
assistants (PDA).
Making a Connection
3
The client user contacts external IP address of the network on which the remote
desktop is located using any web browser. The client user downloads an html page with a
form that allows specification of the internal IP address or host name of the host to be
contacted and the window size that the VNC applet will use.
An ASP processes the form and loads the applet. The pages and the applet are
served from the gateway server via port forwarding from the external IP address. The
user clicks options and selects “Yes” under the “Share Desktop” option if multiple users
will access the same desktop. The user then types in the password of the remote desktop
(has been set on the remote desktop itself within the VNC Server) and clicks “OK”.
The applet connects via the external IP address and port forwarding to the
TCPReflector instance on the gateway server. TCPReflector takes the remote desktop IP
address and sets up a relayed connection between the applet and the remote desktop. All
packets go through the TCPReflector in order to reach their destination regardless of
whether it is applet to remote desktop or the reverse. The client is validated by the remote
desktop server using a series of challenges based on DES encryption where the password
4
is used as a key. This validation is secure, and the password is not transmitted over the
network. However, future communication between client and remote desktop after
authorization is completed is unencrypted plaintext. Upon successful validation by the
VNC server, the remote desktop window appears within the browser, allowing the user to
operate the remote desktop.
5
The figure above illustrates the architecture of the system. The purple and green
lines illustrate the two connections that make up the full remote desktop connection
between Client1 and RemoteDesktop1. The blue and orange lines do the same for Client2
and RemoteDesktop2.
Performance
Average Initial Setup Latency (seconds)
The average number of seconds from when the client user clicked OK in the
applet to connect and when the remote desktop screen became available was measured.
This is done for when there are already 0, 1, 2, and 3 established connections.
0 connections - .62 seconds
1 connection - .74 seconds
2 connections - .80 seconds
6
3 connections - 1.13 seconds
There appears to be an obvious increase in wait time for setup as the number of
concurrent connections increases.
Average Throughput (bytes/second)
The average number of bytes per second transferred between client and remote
desktop server was measured for different numbers of simultaneous open client
connections. Each connection is on a different remote desktop.
1 connection
Client to Server - 388 bytes/second
Server to Client - 4495 bytes/second
2 connections
Client to Server - 130 bytes/second
Server to Client - 7383 bytes/second
3 connections
Client to Server - 182 bytes/second
Server to Client - 6100 bytes/second
There does not seem to be a clear correlation between number of concurrent connections
and the average throughput. This seems to indicate that average throughput is more
dictated by the type of activity the user is performing on the remote desktop rather than
the number of simultaneous connections.
Related Work
Microsoft NetMeeting remote desktop technology comes pre-installed on
Windows operating systems and can be embedded into web pages requiring minimal
configuration by the client (the user only needs to set it to allow all incoming calls).
However, a user must go through a setup process before using NetMeeting. Microsoft
appears to be phasing out NetMeeting and as a result documentation and support is
scarce. Future versions of Windows will probably not come bundled with NetMeeting,
and NetMeeting development appears to be no longer on going. NetMeeting is a
Microsoft product and neither open source nor cross platform compatible, and PDA’s
appear to be unsupported.
Windows Remote Desktop Connection (Terminal Services) is another remote
desktop technology that is included on Windows NT-based systems. A client user
wishing to access a desktop behind a firewall must first establish a Virtual Private
Network (VPN) connection in order to do so. Remote Desktop Connection is limited to
7
Windows NT-based systems and cannot be used to access machines running on Linux
and certain versions of Windows (Me and 98). Remote Desktop Connection does have
client support for Windows 98/Me, PDA support, and a web-client.
There a number of commercial web-based remote desktop services, such as
GoToMyPC, which charge a fee for desktop connectivity. Although such solutions can
connect hosts behind separate firewalls, all data must go through the companies’ servers,
and the usage fees can be significant.
The remote desktop solution described in this paper can also be applied to any
client/server applications that need to be accessed from behind separate firewalls, with
some modification to TCPReflector and the applicable client. Peer-to-peer technology
such as Voice over IP and network based games can also use a modified version of
TCPReflector to access peers behind firewalls and NAT-based networks which would
have been previously inaccessible.
Conclusions
The described solution allows a user to connect to a remote desktop behind a
firewall from any location (even behind a different firewall), and can handle connections
between separate NAT-based networks. No software needs to be downloaded or installed
on the client side. The client only requires a web browser that can run Java applets (JRE
1.4.2 or greater). On the remote desktop side, only a standard VNC Server needs to be
running with a password and view set. Only two ports need to be forwarded on the
firewall to the gateway server, and minimal configuration needs to be done.
Authorization of client by the remote desktop server is done securely, using DES, and the
password is never transmitted over the network.
System Setup
The firewall must be configured to forward an external port (such as 5902) to a port on
the gateway server (such as 9888). The firewall also must be configured to forward
another external port (such as 8082) to the gateway server (8082) for the web server
residing on it. If the external port to be forwarded for TCPReflector needs to be a port
other than 5902, this must be set on the firewall and changed in view.asp. However, the
setting on the VNC Servers residing on remote desktops must always be 5902 (view 2).
TCPReflector classes reside in the vncref folder. Reflect.bat can be run from the
command line with parameter –port (portnumber) where portnumber is the port that
outside connections are being forwarded to on the gateway server. For example, “reflect
–port 9888”. Use –echo on the command line for traffic information (number of bytes
sent from server to client or vice versa and at a certain date and time) to be printed.
8
Place vncviewer.jar, vnc.html and view.asp (all located in vncviewer folder) in the
wwwroot folder of the IIS installation on the gateway server and configure IIS to serve
on the aforementioned port (8082). This implies that the gateway server should be a
Windows machine, however view.asp is simple enough that it can easily be changed to
work with a different type of server.
Download and install RealVNC Server on the remote desktops that need to be accessed.
Set view number to 2 (set port number to 5902 on newer versions of VNC Server) and set
a password. Run the RealVNC Server.
System setup is complete. Contact the web server at http://externalIP:8082/vnc.html to
start a remote desktop connection. The web browser must have JRE 1.4.2 or greater
installed.
9