
Redir v.2.2.1

Redir is a port redirector.  It's functionally basically consists of
the ability to listen for TCP connections on a given port, and, when
it recieves a connection, to then connect to a given destination
address/port, and pass data between them.  It finds most of its
applications in traversing firewalls, but, of course, there are other
uses.  Consult the man page, or run with no options for usage information.

Please check the Makefile to see if you need to make any changes to
get it to compile correctly on your particular unix flavor.

If you would like to remove support for some extended options (for the
sake of speed, code size, whatever), change the EXTRA_CFLAGS line in
the makefile.  The following are supported:

 -DNO_SHAPER (doesn't compile in traffic shaping code)
 -DNO_FTP (doesn't compile in FTP redirection support)


Please submit patches/comments, etc to: Sam Creasey (sammy@oh.verio.com).

-----

I'm thinking of eventually doing a version which never forks, but does one
big-honking-select-loop, which probably wouldn't be much of a bother,
and would save a good chunk of ram, but then an FD limit becomes quite
a real possibility.  perhaps an #ifdef selecting the old or new code
would help this...  though, really, this is a known problem with a lot
of proxies, and it doesn't seem to hurt too bad.  depends on the
MAX_FDS (or whatever that define is.  FD_MAX?) on your machine.

Wow.  The authorship/maintnence for this thing has REALLY gotten mangled.  
Credits should, logically, go to the following people:

Nigel Metheringham <Nigel.Metheringham@ThePLAnet.net>
	For taking the code I wrote and making it into a more stable 
	sensible, and usable package.  
Sam Creasey <sammy@oh.verio.com>
	Original author, but this package would be vastly inferior without 
	Nigel's modifications.
Thomas Osterried <thomas@x-berg.in-berlin.de>
	Added the --bind-addr patch.

22 June, 1999 - Sam Creasey <sammy@oh.verio.com>

Bug reports/patches/comments/etc please now to <sammy@oh.verio.com>

Current versions can be found at http://oh.verio.com/~sammy/hacks

redir is distributed under the terms of the GNU Public Licence,
version 2 or later, which was distributed with this source archive in
the file COPYING.

the files in the getopt/ directory are taken from GNU source code
distributed under the same license.  These particular files were
copied from the GNU package gawk-3.0.3, because it happened to be
sitting on my drive at the time.

=======================================================================

Redir v.0.7

redir is a tcp port redirector for unix.
It can run under inetd or stand alone (in which case it handles
multiple connections).  Its 8 bit clean, not limited to line
mode, is small and light.

If you want access control run it under xinetd, or inetd with tcp
wrappers.  Or you could use the tcp wrapper library to extend it and
do fancy access control - if so please let me know.

redir is released under GPL.

	Nigel Metheringham
	Nigel.Metheringham@ThePLAnet.net
	30 June, 1996

=======================================================================

[Original readme from version 0.5]

If you liked daemon, you'll LOVE redir!

Redir, the fully functional (but only in line mode) port redirector for 
unix!  (yeah!  WOOOO!).  Basically, it's like tredir.   But hacked from 
daemon.  And poorly written.   But, hey, it dodges firewalls, and THAT's 
the important part.  I think.  Oh, fuck it.  Look, it's useful.   Good 
for dynamic IP, too.   Trust me, it is.

usage: redir [remote-host] listen_port connect_port

The syntax is a little clumsy, but it works. 

compile with make redir or gcc redir.c -o redir

comments/bugs/flames to sammy@freenet.akron.oh.us

(please, write if you use the program!)




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 which will redirect all
connections to certain hosts, on certain ports, to a port on the
firewall machine.

An convienent 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 toredirect 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@oh.verio.com.

-- Sam Creasey (11/2/98)

   
