EAPTLS Stress test: 2.1.7

[Alan DeKok]

leopold wrote:
> Hi,
> We tried to stress test (EAPTLS) FreeRADIUS 2.1.7 which sits behind Load
> Balancer 

  That doesn't work.  Don't bother trying to "fix" FreeRADIUS.  Instead,
use a load balancer that is aware of EAP.  e.g. FreeRADIUS.

> Now we understand that if EAPTLS session started (we have 10
> Access-Challenge messages because of our certificate chain) against Radius_1
> and then continued to Radius_2 because load balancer reverted it there then
> EAPTLS handshake cannot succeed, but we expected that FreeRADIUS should drop
> packets and NOT RESPOND instead of sending Access-Reject when it cannot find
> STATE variable

  No.  Users that fail authentication get Access-Reject.  The
alternative is worse.

> By looking at the code we think eap_tls module returns RLM_MODULE_INVALID or
> RLM_MODULE_FAIL when it cannot find EAP session in the tree.

  Yes.  This is what it's supposed to do.

> What is proper configuration that we can do?

  Use a load balancer that is aware of EAP.  FreeRADIUS can do this.
See "keyed-balance" in proxy.conf.  You can load-balance over the client
IP && the User-Name.  This is often good enough to get most EAP sessions
working.

> Is something like this recommended?

  No.

  All it does is force the client to retransmit.  At which point,
there's a 50% chance that it will go to the SAME server, and *again* be
thrown away.  For an EAP session of 10 packets, the odds are 1/(2^10)
that *all* EAP packets will go to the right server.  So you'll have 1
out of 1000 authentications succeed.  The rest will be rejected, after
processing many, many, duplicates.

  Don't increase your load by a factor of 1000 for nothin.  Use a
load-balancer that is aware of EAP, *or* configure your load balancer to
 hash on source IP, and balance based on that.  It means that *most* EAP
sessions will go to the same RADIUS server.

  It's not perfect, but it's a lot better than having a 99.9% failure rate.

  Alan DeKok.