[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Load Balancing ...... maybe this one
 Date:  Sun, 23 May 2004 19:51:10 -0700 (PDT)
On Sun, 23 May 2004, Imre Ispanovits wrote:
> On Sat, 22 May 2004 22:34:31 -0500
> David Rodgers <david dot rodgers at kdsi dot net> wrote:
> 
> > Though that kind of connection load balancing would be cool now that
> > you mention it to though and you could configure an optional interface
> > as a second wan port!
> 
> How is it possible to configure OPT interface to WAN? I tried it without
> success :( The GUI doesn't help in this ( no default route etc.) How is
> it possible, could you give some advice? I'm really interested in this.

For the most part it's *not* possible.  The configuration is limited to a
direct connection with a static IP, which isn't adequate for a large
percentage of ISPs, even just for simple first-hop testing, let alone real
Internet access.

The default route issue is more complicated, since in general multiple
default gateways aren't desirable or useful (though they're not strictly
prohibited).  There are simple solutions like gateway priorities that take
care of this for the lesser goal of providing fallback, but don't really
meet the requirements for outbound load balancing.

On Sat, 22 May 2004, David Rodgers wrote:
> To: Fred Wright <fw at well dot com>
> 
> > If the data passes through the program, even unmodified, it's a proxy.  
> > The page you linked to calls it a proxy.  Even in concept, this requires
> > converting the data from packets to a stream and back to packets.  Doing
> > this entirely in the kernel wouldn't be cheap, and doing it in userland
> > adds context-switching overhead and additional copying.  Applying this to
> > most traffic on a modest-performing machine that's also the firewall and
> > NAT router could create a bottleneck.
> 
> This is the one that I was actually trying. It appears to just bounce
> (read as port forwarding) a connection rather than answer and proxy
> http://sourceforge.net/projects/pythondirector/ At least that's what the
> docs I was reading suggested.
> 
> For all intents and purposes it looks like it's just doing intelligent
> port forwarding based on a couple of different algorithyms.

I'm pretty sure that if you looked into it in more detail you'd find that
it really is acting as a conduit for the data.  This is "port
forwarding" in the same sense that SSH does "port forwarding".  AFAIK
there's no API allowing it to:

1) Intercept new connections without actually providing a listener, while
blocking the normal "nobody home" response.

2) Make entries in the kernel tables causing the remaining packets to be
suitably NATted and forwarded.

> The problem is that adding python and associated stuff would end up
> being way to much

Oh, *that* "python"?  Yuck.  If the program has to pass all the data it
should at least be written in C. :-)

					Fred Wright