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 'load-balance'.
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 obliterated).
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 packet.
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. Alan DeKok.