This can be done - it requires running two netcat processes, one to connect B to C, the other to wait for a connection from A on B.
It's somewhat insecure - nc on B will accept a connection from anyone, but you'll still need your user credentials on B to connect, and you might need to supply them as
DOMAIN\username rather than just
(Where A, B, C are the ip addresses or hostnames that will resolve)
ssh into B and then:
nc -4v C 3389 0<fb | nc -lk4v 3389 1>fb
I'm currently trying to do this where B and C are on a separate, non-routed private lan, but B is also accessible remotely via VPN from A. (ie, VPN puts me into a separate LAN that B is also on, via a second NIC).
Then, when this is sitting there running, it will probably say something like:
Connection to C 3389 port [tcp/udp] succeeded!
From A, you then run remote desktop connection, but point it at B (with credentials for C). When you connect, you'll see another line in your terminal:
Connection from A <some big port number> received!
At this point you will likely see a certificate error complaining that "The identity of the remote computer cannot be verified..." because the host names don't match -- proceed anyway.
This method seems to have issues -- after you disconnect, you have to go kill the nc process with a CTRL-C and restart it for a new connection, and this seems to take a couple of restarts before it works again -- if you get stuck waiting for 'configuring remote session' then you need to kill it and restart it again. This seems to always happen after you restart it after a session.
For some reason, this seemed to be working better when i was running it with a tmux on B -- this is good practise, as if the ssh connection from A to B gets broken, tmux will keep the two netcats running.
Recall you can get back into the same tmux session by ssh back in, then running