There is a remote Windows server on a private network which I can connect to via Remote Desktop Connection. I would like to be able to make TCP/IP connections from my computer to other computers on that server's network.

Remote Desktop Connection makes it possible to share printers, drives, and other local resources through the connection. Is there any way to "tunnel" a TCP/IP connection via RDC?

I'd like something similar to the port-forwarding provided by SSH. I don't see any way to do this via RDC, but I'm hoping the capability is there and I just don't know about it.

5 Answers 5


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


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)

  • 2
    Yeah, looks like I'll need to install an SSH server. Unfortunately, that will require action from MIS to open the port in the firewall, so it may take a few days/weeks. Commented Apr 13, 2010 at 18:49
  • 1
    My client PC is behind a few layers of firewalls. Don't know if I can connect from the server back to the client. (The world was so much easier when all ports were open.) Commented Apr 13, 2010 at 19:38
  • 1
    Imagine a case where there is no communication viable from the server to the client even with 443 tcp, the only thing that we have RDP Commented Jan 29, 2018 at 20:41

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 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.


It's possible to tunnel TCP through RDP using a File Tunnel.

Host A

ft.exe --tcp-listen --write "C:\Temp\1.dat" --read "C:\Temp\2.dat"

Run an RDP client and ensure local drives are shared as shown here.

Connect to Host B.

Host B

ft.exe --read "\\tsclient\c\Temp\1.dat" --tcp-connect --write "\\tsclient\c\Temp\2.dat"

Now on Host A, you can connect to and it will be forwarded to

Disclaimer: I wrote it, feedback welcome!


I think you can use local port forwarding to RDP:

A -> B -> C

A is Windows or Mac, B is Linux and C is Windows. If you want to RDP to C from A and C is not directly reachable from A then on A

ssh username@B -L 7777:C:3389

Open RD client, then point use the username and password of C. I tried this from Mac but should work for Windows.

  • 1
    The converse of the question?
    – mckenzm
    Commented Jul 23, 2023 at 6:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .