MS Terminal Services (RDP) using mstsc.exe over SSH tunnels

[pierze]

I'm seeing some weird RDP behavior and I'm wondering if anyone can give me some insight. I've used RDP for years over PuTTY tunnels as a poor-mans-vpn so I can get back to my computers at home. This is done by creating local port forwards in Putty, opening a connection to my SSH server inside my intranet, and then using "mstsc.exe" to connect to "localhost:4567" (4567 is forwarded to my Windows desktop at home). This works beautifully.

Now I'm tasked with doing things "backwards" - I want a remote person to SSH into my server and create a "remote forward" from some port, say 5678, back to their localhost. This way I can use RDP to connect to my local intranet server like "mstsc.exe 5678" and I'll be able to login to the notebook that's somewhere else on the Internet.

Stuff works up until the very last bit - I can create the remote tunnel back in to my network no problem, and I can pass data from my server to that tunnel. In fact, I can connect to the Remote Desktop service, get the password box, and enter my credentials. However, where the screen would normally flicker for a second and then show me the remote computer's desktop, instead it just hangs forever. I know I have the right password, because entering the wrong one gives me a clear "wrong pass" type error. I also know the remote computer's terminal services work, because I can connect directly by moving it from my neighbors house back into my LAN and then I can direct connect fine.

Is there some magical switch in RDP that I need to allow localhost connections? I've even tried creating a loopback adapter statically configured to 10.0.0.1 and I create my forward back to that instead of to "localhost", but I still get the same behavior...

[cluberti]

In general, I think it's a problem with the protocol not really being able to work that way, especially if you're allowing drives, printers, clipboard, etc redirection. The RPC endpoints necessary to set these things up generally work fine when both ends of the connection are built to the remote machine, and I've mostly seen this type of fail when you don't first connect directly to the remote host (as in the local ssh endpoint scenario you see). RPC just doesn't work very well this way, although it appears specifically that the auth channels are working.

You might want to try it without any redirection of any kind, just to see if it's that.

[pierze]

In general, I think it's a problem with the protocol not really being able to work that way, especially if you're allowing drives, printers, clipboard, etc redirection. The RPC endpoints necessary to set these things up generally work fine when both ends of the connection are built to the remote machine, and I've mostly seen this type of fail when you don't first connect directly to the remote host (as in the local ssh endpoint scenario you see). RPC just doesn't work very well this way, although it appears specifically that the auth channels are working.

You might want to try it without any redirection of any kind, just to see if it's that.

I'm not quite sure what you mean by "without any redirection" so I tried two different things - if I missed your point let me know what I'll gladly test other ways.

(1) I tried connecting directly to the host on my LAN without a tunnel. This works great, with or without printer sharing/clipboard/etc.

(2) I also tried connecting to my tunnel specifically with Local Resources => Local devices and resources => "Printers" and "Clipboard" both un-checked. I also changed "Remote computer sound" to "Leave at remote computer". Unfortunately this failed in the exact same was as before, so I don't think it is the culprit.

Any other ideas?

[cluberti]

Without using a network sniffer, probably not .

[pierze]

Without using a network sniffer, probably not .

Sure thing - what file format would you like to see? I've tried sniffing traffic and it actually works great to see packets fly by on TCP3389 when the connection is direct (working), but when I do the tunneled (not working) version I literally see zero packets. This is strange, given the fact that the auth is happening just fine - doesn't that require some TCP3389 packets? Or am I missing something like the fact that the auth mechanism actually runs over UDP3389 or something?

[cluberti]

Actually, you will see 3389 and then at least two other RPC channel traffic (port will be dynamic). *cap is fine for the format.

[pierze]

Actually, you will see 3389 and then at least two other RPC channel traffic (port will be dynamic). *cap is fine for the format.

I'm not quite sure what you're statement here means: are you just referring to the fact that 3389 is, strictly speaking, the remote connections listening port? I understand that with TCP the outgoing port is, of course, dynamic. I'm confused because I don't see what there are "at least two"? I have been using msrdp over local SSH tunnels to punch through firewalls for almost a decade now and I've never had to forward anything other than TCP3389... anyway, if it is meaningful feel free to elaborate so I can understand you - perhaps it will lead to the solution to my problem!

Also, I'll upload two capture files (it will take 3 posts to do it given their size). The first capture file, attached to this post, is the broken connection attempt: I've SSHed from the XP host to the Linux host and opened a remote port forward with "-R 7565:localhost:3389". Then I used the Vista machine to effectively run "mstsc.exe 192.168.0.9:7565". This produces almost no detectable traffic on the XP machine - almost as though nothing is going through. There must be something going through, though, since on the Vista machine I get the password login box.

MSRDP Server IP (XP Pro): 192.168.0.104

SSH Server IP (Linux): 192.168.0.9

RDP Client (Vista Ultimate 64bit): 192.168.0.13

lan_backward_tunnel_ip_addr_192.168.0.9_only.rar

[pierze]

This is part 1 of 2 of the second Wireshark capture. This capture is all traffic between 192.168.0.13 and 192.168.0.104 during a successful and direct MSRDP session between the two hosts. I figure this data might be useful in comparison with the previous attachment.

lan_direct_rdp_tcp3389_only.part1.rar

[pierze]

File part 2 of 2

lan_direct_rdp_tcp3389_only.part2.rar