3. Understanding the problem

3.1. Giving names to things

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 "client" the machine that decides to initiate the connection, as well as programs and files on that machine. Conversely, we'll call "server" that waits for connections and accepts them, as well as programs and files on that machine. Firewall piercing is useful when the two machines are separated by a firewall, such that it is possible for the server to accept some kind of connections, whereas the client might or might not be able to accept any. A tunnel will be created between the two machines that allows full IP traffic despite the firewall.

Usually, when piercing firewalls, the client is the machine behind a firewall: it has limited access to the internet, but can somehow open some kind of connection to the server. The server is a machine with full internet access, that will serve as a proxy for the client to access all of the internet. In a VPN, the firewall the roles might be reversed, with the client being on the internet, and the server serving as a proxy for the client to access some private network.

3.2. The main problem

The main problem with firewall piercing is to create a tunnel: a continuous connection from the client machine to a server 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 client side of the firewall to some port on a server 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 will 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).

3.3. The secondary problem

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 server's 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 server's 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 (no more true in recent Linux versions), 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 server's pppd if any, as it can use the telnet or ssh session's tty; but for the client's 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>