Confused about ssl caching

Sven Hartge sven at
Tue Jul 16 07:17:31 CEST 2019

Hello all!

I am using freeradius 3.0.17 (waiting on .19 is on the testbed right
now) and I am a bit confused about the ssl cache.

I am authentication users in WiFi against LDAP (as a database, i.e. the
correct way) and also assigning VLANs based on the UserClass, all
working fine:

if ( "%{toupper:%{control:GIFB-UserClass[*]}}" =~ /(M|P|A|R)/ ) {
        update reply {
                &Tunnel-Type = "VLAN"
                &Tunnel-Medium-Type = "IEEE-802"
                &Tunnel-Private-Group-id = "701"
                &Aruba-User-Vlan = 701
} else {
        update reply {
                &Tunnel-Type = "VLAN"
                &Tunnel-Medium-Type = "IEEE-802"
                &Tunnel-Private-Group-id = "700"
                &Aruba-User-Vlan = 700

GIFB-UserClass is a local attribute pulled from LDAP. This works fine,
no problems here.

Now: in tls-common it says:

#  The "Cached-Session-Policy" is the name of a
#  policy which should be applied to the cached
#  session.  This policy can be used to assign
#  VLANs, IP addresses, etc.  It serves as a useful
#  way to re-apply the policy from the original
#  Access-Accept to the subsequent Access-Accept
#  for the cached session.

Here is where my confusion starts and searching the web and the list
archive only increased it.

Do *I* need to do anything here to get the correct VLAN to the user on
session resumption or is it just *magic* and will work automagically?
Or do I need to add the Xeap.authenticate and Xeap.authorize policies

I'd like to understand the mechanism before playing with it.


More information about the Freeradius-Users mailing list