FR 2.1.8 Issue - Unjustified(?) Access-Rejects.
alex at digriz.org.uk
Tue Jan 12 15:49:38 CET 2010
Stefan Winter <stefan.winter at restena.lu> wrote:
>>> Is this likely to be a configuration error (no changes were made to the
>>> 2.1.7 config), or a bug?
>> Try increasing the size of the cache. Try ensuring that there is
>> always a User-Name in the inner tunnel. This user name is cached, and
>> is checked on session resumption.
> How does this work together with anonymous outer ids? I.e. if outer
> User-Name = anon at foo.bar and the inner User-Name is stefan at foo.bar, then
> the cache contains a session for stefan at foo.bar
> On session resumption, there is no inner tunnel exchange, there's a
> packet User-Name = anon at foo.bar and an EAP-Message with SSL magic (but
> no inner User-Name)... So how does FreeRADIUS know what to look up in
> the cache? Or am I missing something here?
You get the inner-tunnel to return in the reply packet the inner
User-Name (you probably are doing this already to fixup your accounting
packets properly) and it's that reply response which is cached by the
session-resumption cache thingy mcwhatsit.
Works rather nicely here. It's a minor ballache with load-balancers and
overlapping 'eduroam' domains mind you...but that is a non-trivially
solved problem and something I can live with as it rarely crops up.
 you need to share the SSL session cache between your different
FreeRADIUS boxen, the support for that is not in OpenSSL yet if
I remember correctly (or was it FreeRADIUS). This would be done
with some file that could probably be NFS shared or something or
other with locking safely enough
.sigmonster says: How come only your friends step on your new white sneakers?
More information about the Freeradius-Users