Transparent proxying support:

(With much thanks to Bernd Eckenfels, who has been maintaing redir for
debian, and pointed out to me that this could be done at all.)

Most semi-recent versions of the linux kernel have an option which can
be used with IP firewalls entitled "transparent proxying".  Basically,
it allows one to add rules with ipfwadm/ipchains which will redirect all
connections to certain hosts, on certain ports, to a port on the
firewall machine.

A convenient upshot of this feature is that, when it is enabled, a
program running as root may explicitly specify the outgoing address to
be used when making a connection to just about anything it pleases,
which allows us to, when redirecting a connection, make the connection
to the destination machine appear as if it were coming from the system
which connected to redir.  Also quite convenient is the fact that the
program doing this does not actually have to be run using transparent
proxy firewalling rules, it simply has to be compiled into the kernel.

The net effect of it all is the --transproxy flag, which will use this
to make connections "look right" in terms of their originating IP, as
long as redir is running on a linux system with this feature compiled
into its kernel.  (please don't ask me about kernel compiling issues,
unless you're sure you have this option turned on, your kernel is
otherwise installed/working correctly, and --transproxy isn't
operating)


Note the following side effects:

1) Use of --transproxy will cause the --bind-addr option to have no
   effect.  Not really a problem, as using them together wouldn't make
   any sense in the first place.

2) For redirection with --transproxy to work at all, the connection to
   redir must pass through the firewall.  The following example should
   illustrate this:

   Let's say that there's a firewall machine running with the internal
   IP 10.0.0.1, and a netmask of 255.0.0.0 (that is, inside network is
   considered to encompass the entire 10.0.0.0 network).  All machines
   inside the network are configured to use 10.0.0.1 as their gateway
   address. We want to redirect all connections to the firewall on port 
   2323 to port 23 on 10.0.0.2, and we'd like to use --transproxy, so we run:

   redir --transproxy 10.0.0.2 23 2323

   Case 1: Connection from the outside world.

   Let's say someone at address 111.111.111.111 telnets to port 2323,
   on the external ip address of the firewall machine.  Now, as all
   traffic from inside the firewall to 111.111.111.111 must always
   pass through the firewall, in any situation, this will work.

   Case 2: Connection from somewhere on the internal network.

   Now, someone at 10.0.0.3 wants to connect to the same service, but,
   rather than telnetting to port 23 on 10.0.0.2, they've telnetted to
   the port 2323 on 10.0.0.1 (or the external IP of the firewall,
   doesn't matter).  This won't work.  This is because when the
   destination machine (10.0.0.2) saw the connection appearing to come
   from 10.0.0.3, it then expects the real 10.0.0.3 to be talking to
   it, which is, in fact not the case.  By contrast, in case 1,
   10.0.0.2, regardless of the external address, expected these
   packets to come from the gateway host, which was, in fact, the
   case.  For this reason, internal hosts will be unable to make
   connections through a redir running with --transproxy enabled.

This cannot properly be fixed by redir itself, as far as I can tell,
except for using a workaround which would examine the system's routing
tables, and then disable the effects of --transproxy when a connection
is made from a host in the same routing block as redir's destination.
This doesn't sound particularly worthwhile, given that there's no need
for an internal machine to hit the redirector at all.  Patches will be
accepted from someone who bothers to do it, however.

Hopefully, you now have a clear understanding of how to use this
feature.  Questions can be directed to sammy@users.qual.net.

-- Sam Creasey (11/2/98)