EAP proxing with client-balance
aland at deployingradius.com
Sun Oct 11 22:00:09 CEST 2009
Alexander Clouter wrote:
> 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
Well... it does look that way.
> 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.
It's not quite the same. The proxies are like stateful firewalls, but
*only* per-packet. If you have a proxy chain like:
NAS ---> Proxy 1 ----> home
\--> Proxy 2 ---/
Then EAP from the NAS to the home server should work, even if 50% of
the packets go through proxy 1, and 50% go through proxy 2. That's because:
a) each request && reply takes the same path
b) there is no inter-request state in the proxies
(unlike your stateful FW TCP example)
> 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
Then the last line should be:
if (!load-balanced) break
// otherwise, pick a random one
i.e. rely on the key / hash to even the load over the servers, instead
of relying on the random values.
> 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.
You're braver than most.
> Having a warning telling me that a request was discarded as an upstream
> load-balancer is shafted is a Good Thing(tm).
A warning, maybe. But it looks like there's no reason do discard the
> 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!
Yup. The proxies should make load-balance decisions based on realms, too.
> 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.
Making the logs more descriptive is good.
More information about the Freeradius-Devel