-Even though I rewrote most everything but the disclaimers,
-I'm indebted to
-Because system administrators and users have different
-constraints and proficiencies,
-it so happens that a user may find himself behind a firewall,
+This is document with a moral. And the moral is:
+
-Of course, if your sysadm has setup a firewall,
+Of course, if your sysadm has setup a firewall
s/he might have a good reason,
and you may have signed an agreement to not circumvent it.
On the other hand, the fact that you can use
@@ -212,18 +240,12 @@ use the addresses below:
-The goal is to connect the input and output of a local IP emulator
-to the output and input respectively of a remote IP emulator.
+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.
-Only the communication channels with which IP emulators interact
-are either direct devices (in the usual case of pppd),
-or the "current tty".
-The previous case obviously does not happen with telnet sessions.
-The latter is tricky, because when you launch the local emulator
-from the command line, the "current tty" is linked to the command-line user,
-not to a remote session;
-also, should we open a new session (local or remote) on a new terminal,
-we must synchronize the launching and connection of IP emulators on both sides,
-least one session's garbage output is going to be executed
-as commands on the other session, which would recursively produce more garbage.
+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).
-To get the best ease of use,
-the local IP emulator has to provide IP to kernel networking,
-hence be pppd.
-However, pppd is dumb enough to only accept having data
-through /dev or through the current tty;
-it must be a tty, not a pair of pipe
+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 session's tty;
-but for the local pppd, this sucks,
-as it can't launch the telnet session to connect to;
-hence, there must some kind of wrapper around it.
+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.
-Telnet behaves almost correctly with a pair of pipe,
+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,
+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,
+(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.
-[Note: if I find the sucker
-(probably a MULTICS guy,
+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!]
+I strangle him!
+
+</FLAME>
Let's assume that your site administrator allows
-transparent TCP connections to some port,
+transparent TCP connections to some port on some remote machine,
(be it the standard SSH port 22, or an alternate destination port,
like the HTTP port 80 or whatever),
or that you somehow managed to get some port in one side of the firewall
to get redirected to a port on the other side
-(using httptunnel or mailtunnel or whatever).
+(using httptunnel, mailtunnel, icmptunnel,
+some tunnel over telnet, or whatelse).
+
Then, you can run an sshd on the remote port,
and connect to it with an ssh on the local port.
-On both sides of the ssh connection, you run IP emulators (pppd),
+On both sides of the ssh connection,
+you run IP emulators (pppd),
and there you have your VPN, Virtual Public Network,
-that circumvents the stupid firewall limitations.
-
+that circumvents the stupid firewall limitations,
+with the added bonus of being encrypted for privacy
+(beware: the firewall administrator still knows the other end of the tunnel,
+and whatever authentication information you might have sent before to run
+ssh).
+
The exact same technology can be used to build a VPN, Virtual Private Network,
whereby you securely join physical sites into a one logical network
without sacrificing security with respect to the transport network
@@ -328,6 +397,18 @@ between the sites.
+Below is a sample session to integrate in a shell script
+(it assumes sh/bash syntax; YMMV).
+
+Be sure to edit this into a script
+with the right values for your needs.
+Use option -p for ssh to try another port than port 22
+(but then, be sure to run sshd on same port).
+You can use slirp on the remote end,
+if you are not root there, or simply want to screen your
+local network from outbound connections.
+
+Automatic reconnection is left as an exercise to the reader.
-Default behavior is to use pppd locally, and slirp remotely.
+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:
Note that SLiRP is safer than pppd,
and easier to have access to,
-since it does not require being root on the remote machine.
-Another 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).
+since it does not require being root on the remote machine,
+and needn't additional firewall configuration to prevent
+connections from the outside world into the firewalled network.
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,
+but I haven't managed to get some advertised pluses to work
+(like run-time controllability).
+Of course, since it is free software,
feel free to hack the source
-so as to actually implement whichever feature you need.
+so as to actually implement or fix whichever feature you need.
+The