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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
