Remote Desktop + Tunneling on Windows

Question

Sorry for the long story, I tried to be crystal clear.

* A little background *

As part of a project we need to be able to access certain computers (hereafter called clients) using remote desktop (RDP) from a server with a valid IP address. These clients are behind NAT (e.g. behind a DSL Mode+Router), so they don't have a valid IP address, but the Modem+Router does. Assume that they are all running on Windows 7 Ultimate and there are no firewalls, antiviruses or anything that blocks traffic.

* So far *

The first and most logical thing that comes to mind is using port forwarding option on the modem. But, the real life scenario here is that these clients are running an application (which in written in C# and we've provided) and we need the application to do the port forwarding and not the modem, because after we deployed the system we won't know the router model, configuration, etc. In addition we won't have access to modem settings. So, assume that this option is not available.

* feasible option for us and of course, the problem! *

Moving on to the next option, which is using a reverse tunnel (aka remote port forwarding), we changed the app to create 2 socket. On is used to communicate with RDP server on the client, and the other to connect to the server (the one with the valid IP) to make a tunnel. On the server there is another app, which takes all the traffic from the client and sends it to the remote desktop client (via another socket) and vice versa. So the architecture looks something like :

|RDP SERVER|<->|Socket1|<->|Socket2|<->The Internet<->|Socket3|<->|Socket4|<->|RDP Client|
------------ Client side ----------                   ------------- Server Side ----------  

Socket 1 is on port 17001 of client and is communicating with Port 3389 of client (RDP Server)
Socket 2 is on Port 17002 of client and is communication with port 17002 of server
Socket 3 is on Port 17002 of server and is communicating with port 17002 of client
Socket 4 is on port 17002 of server and is communicating with Port 3389 of server (RDP client)

From that point on, whenever the user on server wants to make a remote desktop connection to the client behind the NAT, he will connect to socket 4 and all the traffic is redirected to socket 3, which in turn transfers the traffic to socket 2 and from socket 2 to socket 1 and the other way around.

The problem is, no matter how the client and server are connected, even when server and client are in the same network just beside each other, after RDP asks me the password for client, it does one of the following on a random basis : 1. sometimes it connects without a problem an I can interact with the computer 2. sometimes it stops there 3. sometimes it goes in and just before showing the client screen it dies.

I checked the connection, changed the modem, changed the client and server and it is still the same. I even tried an ssh server on client (freesshd) and used putty to remote port forward and it the result was strange errors on putty which resulted in connection to drop. I'm starting to pull my hair out! Any ideas what is going on?

Answer 1

First off, thank you folks for not answering my question! It helped me to figure out what was wrong.

I would like to share the solution here, so other folks looking around for an answer for similar problems may get an idea.

The Answer :

Believe it or not, it was related to debugging!!! Several days after posting this question, I found out that if I am not debugging the code, it works just fine. My problem was solved, so I didn't bother to think about the reason.

But, about three days ago, in the middle of writing a windows service that had to interact with user, I accidentally ran into some article which made me understand what was wrong.

I got deeper and deeper and found out that when you're starting a remote connection you're practically starting a new session. And guess what? Your debugger is attached to a process which runs in another windows session, so the video renderer is not assigned to the new session and all hell will break loose!

Of course, this is my understanding of the problem, but seems to reveal the mystery!