The scheme we will follow is always the same. First we set up a tunnel chain from source:localport to target:targetport. Then, we open connections to source:localport and actually we are connected to target:target port. Example : accessing to mail via IMAP

Configuration of all these tools is not detailed. Documentation web pages, man pages and --help are your friends if needed ! A lot of other tools are equivalent. The goal of this document is neither to list nor to compare them (netcat ~= ucspi-tcpclient for example). Note that ucspi-tcpserver is preferred to netcat in listening mode because it allows multiple connections.

NB : In this HOWTO :

we do not adress the issue of the encryption of the tunnel (except for obvious SSH tunnels !)

others solutions include the ability of some SSH servers of acting as a SOCKS server or the GNU netcat tool.

Thus, there are potentially 4*2*2*2 = 32 different cases. Actually, there are less cases described in this document since some are redundant. Note that we are able to use any protocol via an http proxy thanks to the connect method of protocol http.

If you can not access to wanted target:targetport one needs an assistant machine. An assistant is a machine on the other side of the proxy, where you have an account (ideally where you are root), and from where you have access to target:port.

But sometimes SSH port 22 is not allowed by the proxy. Then, the best thing to do is to launch a SSH server which listen on an accessible port from the proxy (for example port 443 via a HTTP proxy). In short, you should modify one line of sshd.conf or of the (x)inetd configuration file. Then it is exactly the same methods as previous section, but usual SSH port (22) is replaced by the allowed port.

For this case, you need to have at least two allowed port by the proxy (telnetport - 23 and allowedport). One for the setting the tunnel via telnet, the other for the tunnel (unlike SSH tunnels which are encapsulated onto the same port).