Tunneling a TCP/IP Connection through Remote Desktop Connection

If you are running rdesktop on the client-side (instead of the native Windows client), you can use rdp2tcp.
It allows you to manage TCP ports forwarding through a RDP connection.

I dont think you can tunnel over RDP, however if you were to rdp to the server and then initiate a ssh tunnel back to your client your machines would be connected by ssh. You can forward both remote and local ports so you could do it so that it was all in reverse

EDIT

If you install a ssh server on your client pc and set it to accept ssh connections on port 443 then you can connect to the ssh server (your client) from your server (using ssh client connection) and you wont need to open any ports (443 should be open for https)

I didn't find anything better than rdp2tcp to use with a Windows Server that allowed no admin access or interface-to-interface network routing. You will need to do the OOP patch on your rdesktop to get this to work (go to the last pages to find the one corresponding to a recent version of rdesktop). I used the MinGW compiler to compile the Windows end of the tunnel.

The documentation is also excellent and concise.

What might seem like a minor point: If you use an 'addin' name with '-' in it, rdesktop fails to parse the command line correctly. This might have been a bashism that required proper escaping, but I'm not sure.

Note that as far as I can understand, this isn't a 'true' TCP tunnel that 'sees' the TCP Protocol data units as that wouldn't be possible without admin privileges on the Windows side. It's more like a socks proxy with an endpoint that is pre-configured (not very consequential though). It also features an actual socks proxy if you fancy that.

I easily managed an interactive SSH session with it, but it didn't hold up for SSH file transfers (gave 'virtual channel disconnected' in the rdesktop console (rdp2tcp runs as its child process with stdout/stdin dup2'ed/piped by rdesktop, but with no change to stderr)). There was a constant in the source called RDP2TCP_PING_TIMEOUT which looked like a keepalive timeout for holding up the tunnel. Assuming some sort of throttling in the intermediate network, increasing this from 5s to 900s seemed to have done the trick, and it held up for transfers of upto 100MB (took around 15 minutes on that particular network).

Beyond that, though, rdp2tcp was found to receive a SIGPIPE, which it claimed to have received because of a break in the rdesktop pipe, although I couldn't find any evidence of that happening from either the rdesktop code, or the output of 'lsof' which showed no change in the number of pipes for rdesktop before and after the SIGPIPE trigger.

If this happens, you will need to restart rdesktop, and possibly the Windows side of the tunnel too. You can use rsync and resume file transfers, and maybe you can automate the whole recovery process.

All this was assuming Linux as your client. I haven't tried the patched rdesktop on Windows due to some unrelated trouble I had with Cygwin/X. I guess It ought to work.

Also, my experience was with SSH, but huge file transfers by any other means are likely to hit the same issues.