Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
    
There are ways for punching holes into stateful firewall's rulesets - especially with UDP. But an easier solution would go through some kind of mediatory server where both connecting parties would be "clients" from the protocol's view. I also keep wondering about the rationale of this project - there are dozens of readily available products which should meet the bill - buying them would certainly be cheaper than re-inventing the wheel. –  the-wabbit Jul 13 '11 at 12:27
    
+1 and accept; thanks for pointing me in. –  daemon_x Jul 13 '11 at 14:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.