[LARTC] load balancing causes authentication problems?

[LARTC] load balancing causes authentication problems?

[Spencer]

[-- Attachment #1.1: Type: text/plain, Size: 1398 bytes --]

We are currently using iproute2 to perform a round robin type load balancing. 
ip route add default proto static scope global 
                    nexthop via XXX.XXX.XXX.XXX dev eth0 weight 1
                    nexthop via XXX.XXX.XXX.XXX dev eth1 weight 1
                    nexthop via XXX.XXX.XXX.XXX dev eth2 weight 1

From my understanding this is destination based load balancing.  And it has worked fine 99% of the time. The problem we are running into is for web sites that have a separate authentication server.  For example a user authenticates on an authentication server through eth0.  After authentication the user is redirected to the application server, however since the application server is a different destination the user can now be routed out through eth1 or eth2.  In the case that the user is routed out through either eth1 or eth2 the application server now sees a different ip address than the one used to authenticate and thus denies the user access.
    It is also possible that I'm way off base and this is not at all what is happening and is not the reason for users getting denied access after authenticating, but that's what it looks like to me.  I was wondering if anyone else had seen a similar problem and had a possible solution.  I didn't see anything in the archives right off but I wasn't sure exactly what to search for either.

Thanks
Spencer 

[-- Attachment #1.2: Type: text/html, Size: 2647 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] load balancing causes authentication problems?

[gypsy]

> Spencer wrote:
> 
> We are currently using iproute2 to perform a round robin type load
> balancing.
> ip route add default proto static scope global
>                     nexthop via XXX.XXX.XXX.XXX dev eth0 weight 1
>                     nexthop via XXX.XXX.XXX.XXX dev eth1 weight 1
>                     nexthop via XXX.XXX.XXX.XXX dev eth2 weight 1
>
> From my understanding this is destination based load balancing.  And
> it has worked fine 99% of the time. The problem we are running into is
> for web sites that have a separate authentication server.  For example
> a user authenticates on an authentication server through eth0.  After
> authentication the user is redirected to the application server,
> however since the application server is a different destination the
> user can now be routed out through eth1 or eth2.  In the case that the
> user is routed out through either eth1 or eth2 the application server
> now sees a different ip address than the one used to authenticate and
> thus denies the user access.
>     It is also possible that I'm way off base and this is not at all
> what is happening and is not the reason for users getting denied
> access after authenticating, but that's what it looks like to me.  I
> was wondering if anyone else had seen a similar problem and had a
> possible solution.  I didn't see anything in the archives right off
> but I wasn't sure exactly what to search for either.
> 
> Thanks
> Spencer

I've never seen this happen, so I can't comment except to say that your
explanation sounds plausible to me.

The "normal" cure is to
install Julian's routing patch
http://www.ssi.bg/~ja/

and use connmark
http://selab.edu.ms/twiki/bin/view/Networking/MultihomedLinuxNetworking

You may also want to investigate the KeepState stuff in nano.txt (on
Julian's site).

HTH (but no guarantees...),
gypsy
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc