EAPTLS Stress test: 2.1.7
aland at deployingradius.com
Wed Sep 30 21:56:17 CEST 2009
> We tried to stress test (EAPTLS) FreeRADIUS 2.1.7 which sits behind Load
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
> Is something like this recommended?
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.
More information about the Freeradius-Users