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.