EAP proxing with client-balance

[Alan DeKok]

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.