Marcin Marszałkowski <[hidden email]> wrote
> I have freeradius 3.0.20 with tls cache enabled (fast reauthentication) running in docker container , sql backend.
> Everything has been working fine until recently new device (laptop) was added to network.
> Laptop connects properly to specified network but when roaming it gets answer Access-Accept without any AVP, thus it is assigned to native, trunk network.
Is it possible that this is the first device that you have used on you network that
actually does fast reauthentication? Many devices won't unless you tell them
If that's the case you're not saving the necessary authorization attributes into
the cache or pulling them back out. This is a bit complicated to do, as some of
them may be determined inside the inner tunnel.
eapol_test can be used to test fast reauthentication, you just have to do a bit of
mangling of the output to find the attributes that the server is sending during
a fast-reauthentication versus the ones it gets on the first authentication:
eapol_test -t 4 -c <conf file with username, password, etc> -r 1 -a IP_OF_FREERADIUS -p PORT_OF_FREERADIUS -s SHARED_SECRET -M<FAKE_MAC_ADDRESS_CSID> -N4:x:0x<FAKE_NAS_IP_IN_HEX> -N30:s:<FAKE_CALLED_STATION_ADDRESS> | perl -ne '$m = 1 if m/Triggering EAP reauthentication/; $m = 0 if m/MSCHAP/; print if $m;' | grep -A1 'Attribute 81 (Tunnel-Private-Group-Id)'
>> Is it possible that this is the first device that you have used on you network that
>> actually does fast reauthentication? Many devices won't unless you tell them
> I don’t think so, tlscache folder was already populated with files as below:
> And so on…
The cache populates during the initial authentication... you don't need a resumption
to happen to get a cache file.