Yes, that’s a bit of a mouthful, I know. Bare with me. After Logmein delivered a huge blow to occasional remote access users everywhere, I’ve been thinking about the state of Remote Control tools. I’m not saying this to list all the different options there are, and gosh there are many; but to look at what has made Logmein and a similar tool, Teamviewer, become so powerful.

The one common ingredient with Logmein and Teamviewer is the ability to punch through firewalls and effectively remove the need for time-wasting port configuration. Logmein does go further by providing online status and other “Pro” features, but the big and valuable feature of these two utilities is in firewall traversal. If you’re a VNC, or Remote Desktop or Radmin user, you’re likely familiar with the two-step process of opening a port, creating a gateway server and connecting. This keeps your need to open the network to a minimum while allowing access to all systems internally. Why don’t we have an open-source equivalent to this kind of tool?

How does TeamViewer do it? I found an interesting passage on stackexchange.com that describes Teamviewer’s process of getting past most of the currently in-use firewalls:

In order to pin hole your machine (viewer) has a TCP connection back to the main TeamViewer server. The target machine (client) also has a TCP connection to the main TeamViewer Server. When you hit connect your machine tells the main server its intention. The main server then gives you the IP address of the client machine. Your machine then begins firing UDP packets at the client. The client is signaled that you intend to connect and is given your IP. The client also starts firing UDP packets at you.

This causes both firewalls (yours and the clients) to allow the traffic, thus “punching holes” in the firewall.

That’s impressive, but the need for a central server is a real problem. With clever tools like BitTorrent Sync showing that server-less operations (to a degree) are possible; I think now would be a great time to create a true peer to peer remote access tool. We’re really on the frontier of tools that disrespect protocol boundaries while enabling features we may never have thought of. Examples of machines that, when turned on, immediately become aware of their surroundings and users are going to be more common sooner than you think.

This new tool would have lofty goals with no central Internet server interaction. Perhaps the creation of a key on the computer to be controlled includes the IP address (local and external), the port number to punch through and other basic details. Passing that to a support person allows for the same process of firing packets at the server. If nothing is available on the other end, the client will know pretty quickly.

Of course, there will be a place for cloud-based databases of machines (that allow for quick connections), but you might just as well keep a text file or outline of that information. I’ve even developed a basic system for keeping track of connections that I’ll get around to re-releasing some time.

I wonder why VNC, with its source available in places, hasn’t been repurposed to provide that one feature and released with a current subset of tools already in the application. Not only would this kind of tool change the face of remote support, but it would also deliver a real blow to companies like Logmein that think they have a lock on this stuff.

Update: I received a message from Miles suggesting that we do have a tool I’ve described and I should check out Gitso. If you aren’t familiar with the project, Gitso is a frontend for reverse VNC connections. With this tool, you set yourself up as a support “server” and have users run Gisto, type in a simple address and connect to you. Awesome, right?

Gisto is an amazing tool, but it doesn’t fulfill what I had in mind. Gitso is a “prompted” tool and a good one at that. What I had in mind involves no prompting from the user. I expect to run this tool on the user end to set it up as a background service. Another snag is that Gitso requires control over the “Supporter’s” router forwarding. They describe forwarding like this:

In order to give support through Gitso, you need to be able to have access to the firewall/router of the subnet you’re on. If you don’t have access to that, you unfortunately won’t be able to use Gitso.

That’s a major drawback since I might support users in places I don’t have control over the router (like coffee shops) or places where it would be undesirable to change the router configuration (at another customer site). We need to move past any and all router configuration steps if a tool is to be at the level of a Teamviewer or Logmein.