Port forwarding & Remote desktop connection (updated)

Overview

In the company I am working as a developer we have relatively flexible rules how to organize working time (some workdays we can work from home assuming we are online and easily accessible by other team members). On the other side there are strict IT rules and firewall settings complicating the remote access.
The e-mail access and even the remote desktop access is officially possible just via a web portal provided that you withstand a tedious login process and unbearable refresh rate (not speaking of an odd interference with skype).
Thus we faced a challenge how to overcome the strict firewall settings and open up a direct (and swift) remote desktop access. Finally we succeeded, and in this post I am going to share the method with you, having possibly similar problems.

Info sources

[Secure remote access of a private network]
[Port forwarding for Remote Desktop]
[Unix man pages: ssh(1)]
[Concurrent Remote Desktop Sessions in Windows XP SP2]
[Speed up SSH X11 forwarding]
[SSH port forwarding]

Configuration

At home I have a PC workstation with Windows XP and laptop with Linux Ubuntu 8.04, both computers behind the Linksys router WRT54GL with DD-WRT firmware version 2.4.
In the office I have a PC workstation with Windows XP behind a firewall. The firewall is administered by the IT department (residing abroad) and developers have no way of configuring it.
The office firewall is configured that there are no incoming ports open and there are just a few outgoing: 80 (http), 119 (nntp), 1863 (msnp) and maybe few others I do not know of.
The goal is to find a way how to enable Remote desktop connection across the Internet in both directions.
We decided to use SSH port forwarding feature. Since the port 22 standardly used for SSH access is not forwarded on the firewall even for outgoing connections we had to use another port - 119 was our choice.
In following text I use port 119, actually it is specific to this specific scenario, given there is another firewall configuration, port selection has to be done correspondingly.

Homeward connection

This direction is a simpler one, since there are at least some ports open on the firewall for outgoing connections.
We have the following:

Home internet connection with public IP address

as an alternative you can use a dynamic DNS service (like dynDNS or similar) but also need a port forwarding for at least port 119 activated by your ISP

Home router with SSH access activated, but configured to listen on port 119
- In case you have no router you can have SSH service/daemon (configured for port 119) running directly on your computer
Home PC with OS Windows (XP Professional version, the Home version has a limited remote access) - Terminal services listening standardly on port 3389
Home Laptop with OS Linux (Ubuntu Hardy 8.04) - VNC server screen 1 listening on port 5901
Office PC with OS Windows XP (not sure if the Professional version is necessary for the Terminal Serveces client) with VNC viewer installed.

Steps to establish the remote desktop connection:

Launch SSH client configured with following command line:
ssh.exe -L 3391:workstation:3389 -L 5951:laptop:5901 -i .ssh\id_rsa <user>@<home-ip> -p 119
... which means:
- Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
- Forwarding local port 3391 to port 3389 of remote host "workstation"
- Forwarding local port 5951 to port 5901 of remote host "laptop"
In order to connect to the Windows machine launch the Terminal services client:
mstsc.exe /v:localhost:3391
In order to connect to the Linux machine launch the VNC viewer:
vncviewer.exe localhost:5951

And that's it. Following schema demonstrates the whole situation:

This was a simpler direction (according to the firewall configuration). The more complicated one follows...

Connection towards Office

This direction is a more intricate one, simply because we are trying to go "against" the firewall, it is configured to disallow any incoming connection. So if we cannot connect to the office computer (sitting behind the firewall) what about turning over the problem to the previous (already solved) one? We could possibly be contacted by our office computer instead of trying contact it ourself.
But we still need some way to initiate the whole connection process. After all must be at least some how to pass through the firewall. If there is such facility, we could use it as our trigger (Surely there is such a facility - a good old e-mail ;-).
Now we have the following:

Office PC with OS Windows XP (XP Professional version, the Home version has a limited remote access) - Terminal services listening standardly on port 3389 and Outlook client running with a custom e-mail rule starting the connection (we can define a rule for specific sender address, subject or body containing some "magic" string etc).
- Obviously any other e-mail client (with e-mail rules) can be used. Or it is possible to use another utility running as an OS service - this way it would be possible to contact the computer even when no user was previously logged in.
We still need an internet connection with public IP address or at least 119 incomming port forwarding (remember, even when we are connecting to the office - actually our ofice is contacting us ;)
Home router with SSH access activated, but configured to listen on port 119. Also we need to have the Office Workstation's rsa key added to the list of router's Authorized keys.
Home PC with OS Windows XP (not sure if the Professional version is necessary for the Terminal Serveces client). We can send the initiating e-mail by hand or prepare a script automating the whole connection process (I am using a python script since it can be used on Linux machine as well).
Home Laptop with OS Linux (Ubuntu Hardy 8.04) - can be used as a Terminal services client as well.

Steps to establish the remote desktop connection:

From either workstation or laptop we send an initiating e-mail (containing a "magic" pattern)
Outlook client running on the Office Workstation receives the e-mail, recognizes the pattern and initiates the actual connection with Home router with following command line:
ssh.exe -R 3393:localhost:3389 -i .ssh\id_rsa <user>@<home-ip> -p 119
... which means:
- Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
- Use the specified identity file (private key) for RSA authentication (this can be used for all ssh sessions but in this case it is necessary - we cannot use the interactive password authentication method in this case ;)
- Forwarding port 3391 of the remote host (Home router) to local port 3389.
On either workstation or laptop we connect to the router with following command line:
ssh.exe -L 3391:localhost:3393 <user>@router
... which means:
- Connect to the router (via standard port 22) as a user <user>
- Forwarding local port 3391 to router's 3393 port
Establish the remote desktop connection to the Office Workstation.
- From Windows: MSTSC.EXE /v:localhost:3391
- From Linux: rdesktop localhost:3391 -u <user> -d <domain> -p -

Following schema demonstrates the whole sequence of events:

Note: not all steps are always necessary. The tunnel between Office Workstation and Home router can sometimes last for several days (while sometimes is spontaneously interrupted - it probably depends on a quality of Internet connection) and so it is not necessary to send the initiating e-mail anytime we want to connect to the office. So usually the first thing I do is to open the SSH connection to the router (step 3), determine whether there is the existing office connection (e.g. via ps command I look at the number of dropbear and sh instances) and if so proceed directly to the step 4.

Update - significant simplification

At the time I initially wrote this post I did not know why it was not possible to connect to the router's forwarded port from another host. That was why I created actually two tunnels (Office PC -> Router<- Home PC) when I was connecting remotely to the office.
After some time I have found some more info in this regard: Client side:

As a security precaution, modern versions of ssh forbid other computers on the internet from connecting to the forwarded port (...) unless you explicitly allow it with the "ssh -g" flag

Server side:

If the client is not configured to accept inbound SSH connections, this can be done with remote port forwarding on an outbound connection. (For OpenSSH, note that you may need to set "GatewayPorts yes" in "sshd_config" to achieve on the server what "ssh -g" would do on the client (allow any host to connect to the forwarded port).

Then I found some more info indicating that it does not work for DropBear even when properly configured (here and here):

The reason that the direct login to remote forwarded port doesn't work is - "dropbear binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports." To fix it, you can recompile dropbear for your router.

I did not want to rebuild dropbear for my router (I do not even have a build toolchain for it) so I kept trying. Finally I realized that when I explicitly use the actual hostname for my router (router in my configuration) instead of localhost (as used by default) on the remote port forwarding command line, it does the trick:
So - on the Office PC command line - instead of former:

ssh.exe -R 3393:localhost:3389 -i .ssh\id_rsa @ -p 119

Now I am using:

ssh.exe -R router:3389:localhost:3389 -i .ssh\id_rsa @ -p 119

... and after this change it is possible to connect to the tunnel not only from the router itself but from any other machine in the network.
I did not consider possible security implications, after all I am just a simple user in this regard, so it is up to you to decide which approach better fits your needs, please, don't blame me then.

Steps to establish the remote desktop connection:

From either workstation or laptop we send an initiating e-mail (containing a "magic" pattern)
Outlook client running on the Office Workstation receives the e-mail, recognizes the pattern and initiates the actual connection with Home router with following command line:
ssh.exe -R router:3389:localhost:3389 -i .ssh\id_rsa <user>@<home-ip> -p 119
... which means:
- Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
- Use the specified identity file (private key) for RSA authentication (this can be used for all ssh sessions but in this case it is necessary - we cannot use the interactive password authentication method in this case ;)
- Forwarding port 3389 of the remote host with hostname router" (Home router) to local port 3389.
On either workstation or laptop we establish the remote desktop connection to the Office Workstation as follows:
- From Windows:
```
MSTSC.EXE /v:router
```
- From Linux:
```
rdesktop router -u <user> -d <domain> -p -
```

Following schema demonstrates the whole sequence of events:

NX accelerated RDP

@TBD