Creating a simple tunnel

Creating a simple tunnel

At the beginning let’s assume that SSH connections are not blocked, but we can receive e-mails only from our local office account. This means that ports 25 and 110 (SMTP and POP) are open only for our local network. But what if we want to be able to receive mail from external servers (EXT_POP_SVR) and send it using external accounts as well (EXT_SMTP_SVR)? Here is where the tunnels enter the stage. We just need to add a parameter while connecting to the REMOTE_HOST via SSH. So, we’re digging the tunnel from our work machine to home with the following command:

worker@LOCAL_HOST:~$ ssh user@IP_NUMBER \\
-L 10025:EXT_SMTP_SVR:25 -L 10110:EXT_POP_SVR:110

Let’s try to decode this. The option -L can be read as “listen on local host”. After a space bar we put the port on which SSH has to listen (in our case respectively 10025 and 10110, but it’s just an example; we can choose different ones but in order to tunnel ports with numbers lower than 1024 we need root privileges). After first colon we point where our REMOTE_HOST should forward the connection. After second colon we state on which port the final server/computer awaits our connection. I emphasize that just after the first colon we give an address relative to REMOTE_HOST. If we want to connect via tunnel with REMOTE_HOST on port 25 (and not further than there) we should use something like:

worker@LOCAL_HOST:~$ ssh user@IP_NUMBER -L 10025:localhost:25

The relation between REMOTE_HOST and… REMOTE_HOST is the following: this is the very same host ;), so it’s localhost for itself.

Let’s get back to our tunnels. We can now configure an e-mail client to connect to an external server. As we’ve mentioned earlier, our LOCAL_HOST listening on port 10025 is now “EXT_SMTP_SVR server listening on port 25”. By analogy, we can say that localhost:10110 is an EXT_POP_SVR:110. In our e-mail client we shall set an incoming server to localhost and port to 10110 - SSH will carry on further communication. Naturally, localhost set on LOCAL_HOST will point to itself. And again by analogy outgoing server should be set to localhost and port to 10025.

In this quite simple (I hope!) way we can bypass not very complex restrictions only. But our network administrator is not sleeping so…

Note that you don’t have to use your IP_NUMBER all the time. If you want to use REMOTE_HOST by its name you need to put a line like this

IP_NUMBER REMOTE_HOST

to your /etc/hosts file (on the machine at work), so that your work machine translates the REMOTE_HOST to IP_NUMBER on the fly. You don’t need to do this only if the REMOTE_HOST is a domain name (or if you’re fine with using your IP_NUMBER all the time). In this text we use IP_NUMBER nevertheless.

Let’s swing into a higher gear

Our present situation has changed. It seems that somebody in our work abuses usage of WWW. Access via HTTP has been cut to the minimum allowed by the boss. Right now we are not interested in how it has been done. Port 22 is still open, but we can’t say the same about port 80 (responsible for HTTP communication). Now when we know how the tunnels work, this is not a big problem for us.

It seems impossible but even the Google search has been blocked. So, to solve this unfortunate situation, we sit down and log onto our REMOTE_HOST like that:

worker@LOCAL_HOST:~$ ssh user@IP_NUMBER \\
-L 10080:www.google.com:80

Just a few clicks in Firefox: Edit -> Preferences -> Connection Settings -> Manual proxy configuration. Here we can put in the HTTP proxy server field: localhost and 10080 for port. If there has been some other values in those fields, we shall write them down. We may need to use them later on. I’ll call those extra settings PROXY_SVR and PROXY_PORT.

Now, we can type http://www.google.com in the address bar and… hip hip hooray – the WWW is wide open again. Don’t be so happy though. Try http://www.altavista.com. And what you’ve got – Google search again. Well, what else can we expect if we’re forwarding all traffic to www.google.com via SSH! To visit AltaVista we should reconnect again with:

worker@LOCAL_HOST:~$ ssh user@IP_NUMBER \\
-L 10080:www.altavista.com:80

This is rather a pretty non-effective way to work with the Internet, don’t you think?