[Next]  [Previous] [Contents]

----------------------------------------------------------------------------

4. The solution

4.1 Principle

The firewall-piercing program, fwprc, will use a "tty proxy", cotty, that
opens two pseudo-tty devices, launches some command on each of those
devices' slaves, and stubbornly copies every character that one outputs to
the tty that serves as input of the other command. One command will be
telnet connection to remote site, and the other will be the local pppd. pppd
can then open and control the telnet session with a chat script as usual.

4.2 fwprc

I wrote a very well self-documented script to pierce firewalls, fwprc,
available from my site http://www.tunes.org/~fare/files/fwprc/, together
with cotty (which is required by fwprc 0.2 and later). At the time of my
writing these lines, latest versions are fwprc 0.3a and cotty 0.3a.

The name "fwprc" is voluntarily made unreadable and unpronounceable, so that
it will confuse the incompetent paranoid sysadm who might be the cause of
the firewall that annoys you (of course, there can be legitimate firewalls,
too, and even indispensible ones; security is all a matter of correct
configuration). If you must read it aloud, choose the worst way you can
imagine.

CONTEST! CONTEST! Send me a .au audio file with a digital audio recording of
how you pronounce "fwprc". The worst entry will win a free upgrade and his
name on the fwprc 1.0 page!

I tested the program in several settings, by configuring it through resource
files. But of course, by Murphy's law, it will break for you. Feel free to
contribute enhancements that will make life easier to other people who'll
configure it after you.

4.3 .fwprcrc

fwprc can be customized through a file .fwprcrc meant to be the same on both
sides of the firewall. Having several alternate configurations to choose
from is sure possible (for instance, I do it), and is left as an exercise to
the reader.

To begin with, copy the appropriate section of fwprc (the previous to last)
into a file named .fwprcrc in your home directory. Then replace variable
values with stuff that fits your configuration. Finally, copy to the other
host, and test.

Default behavior is to use pppd locally, and slirp remotely. To modify that,
you can redefine the appropriate function in your .fwprcrc with such a line
as:

     remote_IP_emu () { remote_pppd }

Note that SLiRP is safer than pppd, and easier to have access to, since it
does not require being root on the remote machine. Anoter safe feature is
that it will drop packets not directly coming from the connected machine
(which feature becomes a misfeature if you attempt to route a subnetwork
onto it with masquerading). The basic functionality in SLiRP works quite
well, but I've found advertised pluses (like run-time controllability) to be
deficient; of course, since it is free software, feel free to hack the
source so as to actually implement whichever feature you need.

----------------------------------------------------------------------------
[Next]  [Previous] [Contents]
