On 11/22/07, Siju George <[EMAIL PROTECTED]> wrote:
> On Nov 22, 2007 12:48 PM, Rajkumar S <[EMAIL PROTECTED]> wrote:
> > On Nov 22, 2007 11:55 AM, Siju George <[EMAIL PROTECTED]> wrote:
> > I am afraid this will not be of any help. By default all packets
> > originating from the box goes via default gateway. Even if the source
> > ip is changed, it will get nated via the default gateway itself.
> >
With some clever pf settings, you can work around this problem and get
your local daemons go through non-default gateways. This is also done
without using ECMP.
I've got pftpx working this way and load balancing ftp across multiple WAN
connections on FreeBSD 6.1. Note that pftpx needed some patching to
ensure that the pf rules it generated include "route-to" for the data path.
Since squid does not insert pf rules, squid modifications are not necessary.
Here is the overview:
Step 1: run multiple instances of squid, one per WAN interface
Step 2: configure squid so that each instance is uses a WAN IP as source
for external connections. By default squid will bind to 0.0.0.0:0 when it
makes an outgoing connection, and the kernel decides to choose the interface
with the default gateway and so the problem. Override this functionality by
explicitly getting squid to use a specific WAN address.
Eg. Squid 1 will use $EXT_IF1_IP as source address.
Squid 2 will use $EXT_IF2_IP and so on.
ftp-proxy users see the -a flag.
Step 3: setup your pf.conf so that any packet using $EXT_IF1_IP
as source address will be forced through $EXT_IF1 to $EXT_IF1_GW.
Stick this on top of your pf.conf:
pass out quick on $EXT_IF1 route-to ($EXT_IF2 $EXT_GW2) \
inet from $EXT_IF2 to ! $EXT_IF2:network keep state
pass out quick on $EXT_IF2 route-to ($EXT_IF1 $EXT_GW1) \
inet from $EXTI_F1 to ! $EXT_IF1:network keep state
Step 4: set the "listen" address for each squid instance to only a loop
back alias (eg 127.0.0.2, 127.0.0.3).
Eg. Squid 1 will listen only on 127.0.0.2:3128
Squid 2 will listen only on $127.0.0.3:3128, and so on.
ftp-proxy users see the -b flag.
Step 5: use a rdr rule with round-robin to push your squid connections into
each instance.
rdr on $LAN proto tcp from any to any port 3128 -> \
{ 127.0.0.2, 127.0.0.3 } port 3128 round-robin
Once you've got all this going, pf will round-robin redirect every connection
to your independent squid instances. Since each squid instance is tied to
a specific WAN interface/gateway, you have achieved load balancing.
Note: if you use pf tables, anchors and some scripting, you can handle auto
fail-over of your WAN links.
Note2: I don't use squid, so I don't know about squid ftp load balancing. I
use pftpx/ftp-proxy.
Note3: if your daemon does not allow you to control the listen and source
IP addresses you can use FreeBSD jail.
> So I think equal-cost multi path routing should work in this case?
ECMP uses route caching, so if multiple users access YouTube,
at the same time, all connections will go through the same gateway.
> Does pfSense have any mechanism to solve this type of situation?
pfSense lacks many tricks. Last I checked, it even lacked pf tags, and
also did not reset the default route if the primary WAN link failed. This
makes the primary link a single point of failure as that named, squid, etc
will stop working and cause service outages.
I find the pfsense team obsessed with UI tweaks and themes instead of
focusing on core issues. But that's just my opinion, and perhaps they
cater to a different set of users.
> Load balancing ftp-proxy also suffers from the same problem as well as
> another problem.
There's a pftpx route-to hack floating around on pfsense CVS. Use it the
same way for ftp-proxy load balancing.
HTH,
- Raja
_______________________________________________
bsd-india mailing list
[email protected]
http://www.bsd-india.org/mailman/listinfo/bsd-india
