pierze

File part 2 of 2 lan_direct_rdp_tcp3389_only.part2.rar

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

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

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?

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?

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

1st Welcome to the forums. And at step 4. of your guide, did you see this on your screen: 5. nLite is free for personal use only, you cannot use it for any company or business purposes at this time. and did you click "I accept" or "I do not accept" ? At step 8, are you sure you selected "Make Iso" ? Step 15's picture is not really a step, it's the working state after you click "yes" to "Do you want to start the process". This leads you directly to picture "step 16", without interaction. I can't remember what happens when you don't select "Make ISO" at 8. but possibly what you describe. First, yes, I'm using this for personal use: the copy of Windows was bought at a corporate liquidation. Perhaps that's not legal? I believe this is just normal old Windows XP Professional (which has Remote Desktop, a feature I need) and Microsoft just added the "Corporate" because it was originally sold to a company. I can't find any information about legal or technical differences between Pro and Pro Corp online, but feel free to correct me ( http://en.wikipedia.org/wiki/Windows_XP_editions ). Second, I missed the "bootable iso" button, and duh, you have solved my problem! Thanks.

This could be a noob issue, but I'm having a hard time doing the final step of writing my lighted OS image to an actual (bootable) ISO file. A great example is this tutorial: http://forum.eeeuser.com/viewtopic.php?id=1923 , except that when I get to the equivalent of step #15 I just get a "finish" button, as opposed to the "next" button shown in that tutorial. I can't for the life of me figure out how to get to the equivalent of step #16, where I write all my content to an ISO. For the record, I'm using nLite 1.4.9.1 on a Vista Ultimate x64 host to customize a copy of Windows XP Pro Corporate, which I plan to write to an SD card for installation on a bunch of netbooks that can boot from their SD slot (they see it as a USB device, I think).