Reverse RDP

RDP is the quickest form of graphical remote access for windows, not to mention native.  And the situation is that no ports can be forwarded to PC 1.  Thus I am attempting a reverse RDP session.  Please accept that this is my goal as I have already weighed other options.  

Why not create a VPN using Hamachi (free) which requires no port forwarding and then RDP in either direction through the VPN tunnel?
https://secure.logmein.com/products/hamachi/vpn.asp?lang=en

Have you considered that you might be over working the situation?

You can install the Gbridge software on all your computers to remotely access your desktop and files as well as to sync or backup folders. All this travels through your virtual encrypted network, so everything is totally secure.

Access files shared by Gbridge on your or your friends' computers, from within a Web browser.
Access the regular Windows shared folders/drives between your computers.
Use remote desktop over an encrypted connection to your or your friends' computers.
Use AutoSync to synchronize folders between your computers and/or friends.
Use EasyBackup to automatically have a directory(s) backed up to another computer.

Hi,

Sorry but I can not have software installed on PC 1 beyond that which is already installed... something like plink is OK because it's just one file that doesn't require installation or administrative rights.

My solution is 50% working (since you do get a remote desktop connection backwards through a firewall... it's just that authentication isn't working)... so if anyone has any further tips on how to finish this solution I'd be greatly appreciative.

This is starting to sound like a protected corporate network. Are you sure you have rights to do this? Experts-Exchange has very strict rules about us assisting people to violate company policies.
--Rob

Hi,

The condition that new software should not be installed is something I should have put in the original question.  It is a restriction that must be kept I'm afraid, this is not a corporate network - it isn't even a real scenario, it is just something I have seen done and would like to perfect.

I guess my point would be normally there is no need as you would have rights to install the appropriate software or redirect ports in a situation where you manage a network.

Hi,

I've asked the question, the question is the question, and I still mean it the way it was written... I'm sorry but thats just the way it is.

Hi lanboyo,

Sorry it's taken a while to get back to you...
I think we are thinking the same and have said the same ultimately...

You've said to run...
plink -N -R 3389:PC1_IP_ADDRESS:3389 user@linuxbox.com
instead of...
plink -N -R 3389:192.168.1.2:3389 user@linuxbox.com

When they are the same thing, the 192.168.1.2 is the internal address for PC1 as shown on ipconfig.

The -N argument is just in there so a shell doesn't start (as it's not needed)...

Netstat does show it's working (I know it's working however as I get the login box remember so traffic is going via pc2 just fine) with this output...

tcp6       0      0 :::3389                 :::*                    LISTEN     26451/sshd: root
tcp6       0      0 ::ffff:212.50.210.:3389 ::ffff:210.20.220:51894 ESTABLISHED26451/sshd: root

If I try to connect to PC1 from PC2 using rdesktop (mstsc for linux) then I get the same problem.

Any other ideas?

OK Get this!

This set up works...

PC 1 - PC that I want to connect to behind firewall on 192.168.1.2
PC 2 - Internet facing server with hostname linuxbox.com
PC 3 - PC that I want to connect from
PC 4 - PC that will relay also behind firewall on 192.168.1.3

So...
PC 4 runs...
plink -N -R 3389:192.168.1.2:3389 user@linuxbox.com

And PC 3 can access PC 1 by connecting to PC 2 (PC 4 relays between PC 2 and PC 1)

So I think this proves that the terminal service running on Windows doesn't like connections coming in from localhost (be it the IP of the box, the hostname, 127.0.0.1, 127.0.0.2, or localhost).  And ultimately I've read that the Remote Desktop Client also doesn't like connecting to localhost.

Evil M$ limitations basically.

So to get this down to just two PC's...

PC 1 - PC that I want to connect to behind firewall on 192.168.1.2
PC 2 - PC that I want to connect from with port 22 opened externally on IP 123.123.123.123

If PC 2 is a Linux box then it would just allow GatewayPorts in the SSHd config and allow PC 1 to connect to it, and the linux rdesktop command allows connections to localhost anyway.

If PC 2 is a Windows box then it would have to run a windows SSH daemon with the GatewayPorts configuration and probably have to have some kind of IP loopback installed so you can use the Remote Desktop Client to connect to the loopback so it doesn't look like it's connecting to localhost.

And on PC 1 where you're running plink, you'd also have to have some kind of loopback installed so that the terminal service doesn't think the connection is incoming from localhost.

Does anyone know a simple loop back like system similar to what I'm describing.  I've did try making a new entry in the hosts file but that's not enough.

OK...

Since I now understand the limitations involved in getting this to work (and it has now become a question more about loopback devices) I will close this question.

I'm awarding point to lanboyo for at least understanding my question and responding to it... rather than trying convince me to do something else which would defeat the objective.

Not a fix... later learned that neither the RDP client or the RDP server will make or receive connections from or to localhost... thus either 4 machines are required, or 2 machines both with loopbacks.

I am sure this is possible using Plink.  I Just connected to an XP Pro Service Pack 3 box...


[PC1 ip 2.2.2.2]----- {corporate firewall}--------{my firewall}------[linux box ip 1.1.1.1]-----[pc2 ip 1.1.1.2]



pc1 - plink  -L 4000:1.1.1.2:3389 user@linuxbox.com
pc1 rdp to 127.0.0.2:4000, would work.

 127.0.0.1 or localhost would not work, but 127.0.0.2 would. I get different errors from trying to rdp to myself on 127.0.0.1 and 127.0.0.2. Make sure there are no firewall rules that would block connections ORIGINATING on 127.0.0.1 (which is the only real localhost) .





This also works ffor me, two XP Pro, Service pack 3 boxes.

pc1: plink -R 4000:2.2.2.2:3389 user@linuxbox.com
pc3: plink -L 4000:127.0.0.1:4000 user@linuxbox.com

And then put in 127.0.0.2:4000 in the RDP window on pc3

linux box pc2 is listening on 127.0.0.1:4000, and forwards this along to pc1 thru the initial ssh.

On my linux box, there is no external port opened for the plink command. If pc3 didn't do it's ssh, the linux box wouldn't allow the connection to 1.1.1.1 be forwarded to pc1...

The command netstat -tan | grep LISTENING

Has this line only. (as concerns the discussion :-) )

tcp        0      0 127.0.0.1:4000          0.0.0.0:*               LISTEN

Since this is within the linux box and not externally available, it can not be connected to by pc 1. There is a command option (-g) in openssh that will malke a local connection listen on 0.0.0.0, but I don't see this in plink.


Well anyway, thanks for the points and good luck.

Hey lanboyo,

For your first bit, I understand what your saying (took me a while lol)... but the Linux server isn't on the same network as the target PC... it's in a data centre and the target PC is a desktop... so it can't route it like that so simply... but at least I understand -L a bit better now.

For the second bit (after you said... "This also works ffor me, two XP Pro, Service pack 3 boxes.") could you clarify which machines are pc1,2,3 etc in a nice diagram?  I think your on to something with using plink at both ends but I'm still not quite understanding it completely.

I was using your box numbers. Essentially the box you want to run the remote desktop TO runs

pc1: plink -R 4000:2.2.2.2:3389 user@linuxbox.com

Where 2.2.2.2 is the external ethernet interface IP address of the box. 127.0.0.2 may or may not work as well.

The PC that you want to run the remote desktom FROM runs

plink -L 4000:127.0.0.1:4000 user@linuxbox.com


And then the you try to connect to remote desktop on 127.0.0.2:4000

This should forward the connection to the linux box ( -L 4000:127.0.0.1:4000 ) where it should then go into the other ssh connection ( -R 4000:2.2.2.2:3389 ) and end up on the remote pc as a connection to the ethernet interface on port 3389.

Can you clarify "the external ethernet interface IP address of the box"... if by this you mean the internet facing IP with the traffic forwarded through the NAT... then doesn't this just defeat the entire point?

However if you mean the IP assigned to the IP then it doesn't work, nor does 127.0.0.2.

Can you tell me if your idea is just that, an idea... or have you practically put it to use and tested it?

Right OK going over it again... I think I get it, it's just another wording of the original idea.

The desktop their connecting TO isn't on the same network as the linux box, so I don't think this can be done.
Because your telling the linux box to target the IP of the desktop you want to connect TO and since there is a firewall between them... your back with the original problem.

The -R direcive tells the remote box (the linux box) to listen on a tcp port and to tunnel connections to the ssh source thru the ssh session, making them connect.from the ssh source to the ip or host and port specified withe rest of the command. The linux box does not need to know where the destination of the tunneled connections. Is, the ssh source has to handle that part. The -L directive is the opposite, it makes the remote box handle connecting to the specified host:port .

My example works no matter where the linux box is, either network or a third network altogether, as long as both plink connections can reach the same linux box.  

Your example as I understand it is this...

         2.2.2.2                                 123.123.123.123                                 1.1.1.1
TSS --> PC1 --> Firewall <-- Internet <-- PC2 --> Internet --> Firewall --> PC3 --> TSC
      3389  4000                                  4000  4000                                  4000  4000

TSS listens on PC1 for connections on port 3389
PC1 tunnels anything incoming to PC2 on 4000 to its own IP on port 3389
via... plink -R 4000:2.2.2.2:3389 user@pc2
PC2 accepts anything incoming on port 4000 to be connected to on port 4000
via... sshd_config have this "GatewayPorts yes" line in
PC3 takes anything incoming on 4000 on PC2 and sends it to 127.0.0.1 on port 4000
via... plink -L 4000:127.0.0.1:4000 user@pc2
TSC makes a connection on PC3 to 127.0.0.2 on port 4000

Previously you have renumbered PC3 to PC2, and also previously you've put PC2 and PC3 on the same subnet, thus I was thinking that you had PC1 and PC2 confused and thus my confusion!!!

So anyway PC3 runs mstsc.exe and connects to 127.0.0.2:4000 and you get... absolutely nothing... can't make a connection.
But connect to 127.0.0.1:4000 and you get the login prompt but logging in freezes it (which is as far as I had already got before posting this question -- only I didn't need 2 plink commands).

I still believe TSS refuses to accept connections appearing to come FROM localhost, just as TSC hates to (but at least can be twisted to) make connections TO localhost.

Have you tested your solution all the way?  i.e. has it successfully logged in?

I am oddly obsessed with this issue. I think that you would prefer not to have the gateway ports enabled, this makes pc2 listen on 0.0.0.0:4000, this enables anyone in the world to connect to pc1 by going to 123.123.123.123:4000 . The two plinks make it so the connection is made on 127.0.0.1:4000 of pc2.

However I think the fact that you initially see the the login means that the port forwarding is working....

maybe try a smaller screen resolution with

MSTSC /v:127.0.0.1:4000  /w:800 /h:600