Understanding a problem is the first half of the path to solving it.
If you want this hack to work for you, you'll have to get an idea of how it works, so that in case anything breaks, you know where to look for.
The first step toward understanding the problem is to give a name to relevant concepts.
As usual, we'll herein call "local" the client machine that decides to initiate the connection, as well as programs and files on that machine; conversely, we'll call "remote" what's on the other side of the connection, where a server runs that waits for connections.
The main problem with firewall piercing is to create a tunnel: a continuous connection from the local machine to a remote machine on the other side of the firewall, that allows for bidirectional exchange of information. Optionally, this connection should be a secure one. The secondary problem is to transform this connection into a full IP access for normal programs to use transparently.
For the main problem, we'll assume that either (1) you can establish normal TCP/IP connections from the local side of the firewall to some port on a remote machine where a sshd runs or can be set to run, or (2) you can somehow establish a telnet connection through a telnet proxy. In case you cannot, we give you pointers to other software that allows you to pierce a tunnel accross a firewall. Although we only give a secure solution in the first case, you can hack your own secure solution in the other cases, if you understand the principle (if you don't, someone, e.g. I, can do it for you in exchange for money).
For the secondary problem,
IP emulators (pppd or SLiRP)
are run on each side of the tunnel.
On the side that wants full IP access to the other side,
you'll want to run pppd.
On the other side, you want to run pppd
if you also want full IP access to the first side,
or SLiRP if you want to prevent any access.
Go to your usual pppd or SLiRP documentation for more information,
if you have specific needs not covered by the examples given below.
Although this is conceptually trivial, it nonetheless requires a few silly tricks, so as to work, since (a) in case you're using some kind of programmed interactive shell session to start the remote IP emulator on either side, you need to correctly synchronize the start of the IP emulator on the other side, so as not to send garbage into the shell session, and (b) IP emulators are designed to be run on a "tty" interface so you have to convert your tunnel's interface into a tty one.
Issue (a) is just your usual synchronization problem,
and doesn't even exist if you use ssh,
that transparently handles remote command launching.
Issue (b) requires the use of a simple external utility.
We wrote one, cotty just for that purpose.
<FLAME ON>
Among the silly problems caused by pppd maintainers' shortmindedness,
you can only run it through
either a device in /dev or the current tty.
You cannot run it through a pair of pipe
(which would be the obvious design).
This is fine for the remote pppd if any,
as it can use the telnet or ssh session's tty;
but for the local pppd, this conflicts with
the possible use of telnet as a way to establish a connection.
Indeed, telnet, too wants to be on a tty;
it behaves almost correctly with a pair of pipe,
except that it will still insist on doing ioctl's to the current tty,
with which it will interfere;
using telnet without a tty also causes race conditions,
so that the whole connection will fail on "slow" computers
(fwprc 0.1 worked perfectly on a P/MMX 233,
one time out of 6 on a 6x86-P200+, and never on a 486dx2/66).
All in all, when using telnet, you need cotty
to run as a daemon to copy output from one tty on which runs pppd
into another tty on which runs telnet, and conversely.
If I find the sucker (probably a MULTICS guy, though there must have been UNIX people stupid enough to copy the idea) who invented the principle of "tty" devices by which you read and write from a "same" pseudo-file, instead of having clean pairs of pipes, I strangle him!
</FLAME>