EAP proxing with client-balance
alex at digriz.org.uk
Sun Oct 11 01:10:34 CEST 2009
Alan DeKok <aland at deployingradius.com> wrote:
> Alexander Clouter wrote:
>> Does mean that client-balance, client-port-balance and keyed-balance do
>> not do as advertised on the tin though which I would want to grumble
>> about being a Bad Thing(tm).
> Err... that's not at all what I said. They work, and they have
> *nothing* to do with changes to the EAP module.
Sorry, they do not work as advertised.
You clearly state (in proxy.conf) that as EAP is stateful you need to
pick a sensible load-balancing algorithm. The config files tells me
'client-(port-)?balance' and intelligent use of 'keyed-balance' is a
Good Idea(tm) for EAP traffic; which makes sense to me with my network
monkey hat on.
If I look at realms.c what I actually find is that the code does this up
to the last three 'if' statements and then throws the baby out with the
bathwater; reverting the whole thing to back to effectively
>> It is a receiver side only fix mind you that does not stop FreeRADIUS
>> (or anything else) shifting packets to the wrong place. The fix is that
>> you need to remove any uncertainty about where the traffic goes and
>> having that load comparison and an explicit call to a random
>> shuffler royally breaks things by making things unpredictable.
> The only random code in the "find home server' function hasn't changed
> in nearly 2 1/2 years.
...also can be read as it took 2.5 years for any of us to notice. :) I
only noticed as I overhauled the mess that was my FreeRADIUS
installation and noticed there were options other than 'fail-over' and
'load-balance' to pick from.
>> I would argue you actually want to keep the src_ipaddr check to pick up
>> on upstream *broken* load balancers, unfortunately it's just currently
>> FreeRADIUS does have a broken load balancer.
> Could you be more specific?
F(client-ip_1) => x_1
F(client-ip_2) => x_2
When load balancing based on the client-ip:
'client-ip_1 == client-ip_2' therefore 'x_1 == x_2'
FreeRADIUS does not do this, which is why EAP proxying breaks. This is
akin to having two stateful firewalls and expecting TCP to function when
you have asymmetrical routing taking place.
I understand why those three 'if' statements are there and look like a
good idea, however it morphs the fancier load balancing algorithms to
just plain old boring 'load-balance' (the 'client' IP hashing is
As for keeping the 'src_ipaddr' check, I like it when tools I use in the
network tell me when other stuff on the network is broken. The last
thing I was is those tools to workaround buggy crap so I can make a
business case to get them thrown off, replaced or fixed by the vendor.
Having a warning telling me that a request was discarded as an upstream
load-balancer is shafted is a Good Thing(tm).
In this situation, without this enforcement, FreeRADIUS could (as MS IAS
currently does and no doubt others) work around the issue, but you would
get randomly failing EAP authentications when it turns out that for a
proxy configuration (hopefully clear enough) that is:
a --> m,n,o --> x,y
a - me
m,n,o - national proxies
x,y - @realm I'm proxying
The moment m,n or o start load-balacing, if I was to proxy to anything
other than the same upstream proxy, my packet might start off arriving
at 'x' and then suddenly go to 'y' when FreeRADIUS decides that
fr_rand() function whats to get excited and get me using another proxy
from the set [m,n,o]. Eeek!
I would rather it *always* fails...looking at the logs it is hard to
differentiate between the problem actually being with our RADIUS server or
whether the issue is between the users keyboard and chair.
>>  obviously you still want the max outstanding check there, but you
>> have to think of the case of (such as for us) where
>> 'outstanding_sessions' is zero ~100% of the time
> Maybe what you want is "pick the first live one, even if it's less
> used than the others".
Then I would want 'load-balance'; from reading what is in realms.c.
.sigmonster says: BOFH excuse #191:
Just type 'mv * /dev/null'.
More information about the Freeradius-Devel