How to develop a Client/Server/Host Remote Desktop Solution that can tunnel through Firewalls and NAT

Question

Hi Everybody, Im starting a college in which i hope to develop (most of at least) a Java & JSP based remote desktop application that replicates Logmein's architecture. I would appreciate some ideas on how to implement this from a network & software perspective.

The following diagram is a good representation - http://blog.donet.com/wp-content/uploads/2009/09/logmein-architecture.png

So far ive decided to use a web based applet for clients to access host machines, the applet will authenticate users via JSP/Tomcat Gateway Server connected to a MYSQL Database.

Host machines will have Software installed constantly pushing host pc ip/network details & current state to the gateway.

Main problems that I cant get my head around is how to punch through NAT & Firewalls. Networking ideas I've found so far include SSH tunnelling and VPN Tunnelling. But it looks like they are usually blocked by corporate/government firewalls unless specifically requested which would make the entire project pointless.

I Tried JRDesktop, a great piece of software but it failed to beat my college & Work place firewalls / NAT setup whereas logmein can get through no problem.

Any Ideas/ Suggestions would be greatly appreciated! :)

Answer 1

Hi thanks for taking a look, the idea of the software is so that novice users can just install the software on the selected host machine and it its ready to be accessed from any Java supporting browser. I would like to achieve the ease of a Plug & Play remote access solution that requires no network changes.

I know this is possible as logmein & Teamviewer require no network firewall modification and if my application requires the Network Administrator to open ports and enable port forwarding then the its no better then VNC or RDP.

The software installed on the host machine will obviously need to be validated againsta an account, visible on the taskbar and display a notification when a remote access session has started to prevent it being used as a malicious tool. Im hoping to make the project opensource if i can get it started but i need ideas on where to break ground.

Regards, Nick

Answer 2

Usually a firewall (out-of-the-box) allows outgoing connections to be initiated. You could have your gateway see if either the client or host is open for connections, i.e. has allowed incoming connections to specific ports, and let that one open a listening socket. Then, via the gateway, let the other party get some connection details (ip and port) and connect.

Now I have used LogMeIn and as far as I know, you need to have one side "connectable" or your connection will fail, so it seems they are using the above method of establishing a connection. In LogMeIn you can specify a port that other clients can connect to (found in your preferences). Since the incoming port is known, you can configure your firewall or router to forward and allow that port to receive incoming connections. LogMeIn adds a virtual network card, i.e. it's not in your hardware, but the computer thinks it's there. The application knows which ip addresses (or buddies) you are connected to, and the virtual card or application actually redirects the traffic sent to those addresses over the socket that it self is connected via. This also lets you set up specific rules for that network card in your firewall.

Answer 3

It is an art getting two computers each behind a firewall to talk together, and frankly I think that getting it to work well in all possible scenarios is a bit too complicated for you to tackle alone this early in your career.

What you might do, and which will most likely work reasonably well for a start, is to use an Instant Messenger protocol for each client to communicate with a central server which then connects the two clients who need to talk. This will work well over most firewalls allowing outgoing connections.

The actual remote desktop data packets going back and forth then "just" needs to be payloads in instant messenger messages.