Let's assume that your site administrator allows
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
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
you run IP emulators (
and there you have your VPN, Virtual Public Network,
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
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 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.
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
nodetach option from
pppd might help).
#!/bin/sh REMOTE_ACCOUNTfirstname.lastname@example.org REMOTE_PPPD="pppd ipcp-accept-local ipcp-accept-remote" #REMOTE_PPPD="slirp ppp" LOCAL_PPPD="pppd silent 10.0.2.15:10.0.2.2" $LOCAL_PPPD pty "ssh -t $REMOTE_ACCOUNT $REMOTE_PPPD"
If you use
slirp instead of
just uncomment the relevant line.
Note that default options from
may break this script, so remove any unwanted option from there.
If your old or non-linux
pppd hasn't got the
cotty -d -- $LOCAL_PPPD -- ssh -t $REMOTE_ACCOUNT $REMOTE_PPPD.
For more customization, please read the documentation for the relevant program.
Note that 10.0.2.2 is the default setting for
which might or not fit your specific setup.
In any case, you should most likely be using some address in one
of the ranges reserved by RFC 1918 for private networks:
10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16.
The firewall-protected LAN might already be using some of them,
and avoiding clashes is your responsibility.