Remote desktop protocol implementation

Question

I'm trying to find the best network solution for my own remote desktop application only for Windows (XP above) and I have the following requirements:

1. First of all, the application should work, let's say, with default OS network configuration, with no further proxy (or anything else) configuration needed
2. It must be firewall aware (also with some basic configuration)
3. It should work over NAT (both communicating sides might be behind NAT)

What concept would you suggest me ? How would you develop (from the network point of view) remote desktop application ? What protocol and port might be the best ?

I'm pretty sure the HTTP on port 80 probably meets the conditions above, but I feel it's not efficient for remote desktop applications. For my implementation would be the best to use my own protocol based on TCP (ideally behind some secured layer), but I think this won't pass through the firewall.

As the best candidate looks for me SSH, but I guess it will be blocked by many firewalls by default, or am I wrong ?

Sorry for this lame (and a little bit subjective) question, I'm really not familiar with the network stuff.
I'm using Synapse library for the implementation.

Answer 1

HTTP on 80 doesn't meet your constraints. In fact, nothing does: the default OS configuration is fully locked down with no holes punched in the NAT for port forwarding. You might be able to use uPnP control to open the appropriate port on the router, but that assumes your program runs at a level where you're able to do this.

If you're doing a drop-in replacement for Remote Desktop (which seems not to be the case, but I'll mention it anyway) you'd still have the same issues. Remote Desktop usually has an exception added to the local Windows Firewall policy when it's enabled, and a hole manually entered into the router.

Oh, and a corporate NAT will certainly have to be manually configured to allow your program. There's no way around that if both sides are corporate NATs.

Picking 3389 gives you some chance of piggybacking on openings that might be made in firewalls for Remote Desktop, but of course those openings are made because Remote Desktop is usually running there.

Picking any port assigned to a particular service is a Bad Thing™ since a) people will expect to find the service there and b) it might actually be there already.

Which brings me to my last point: why not use Remote Desktop? It's a pretty full-featured protocol and it might be easiest to avoid reinventing the wheel here.