Thank you for your response.
On 20 Mar 2019, at 16:05, Alan DeKok <aland@deployingradius.com> wrote:
FreeRADIUS Version 3.0.15
You probably want to upgrade...
We do want to upgrade but are currently limited to the version supplied by the OS-vendor.
(7) ldap: Performing search in "cn=default,ou=profiles,ou=radius,o=config" with filter "(objectclass=nivoRadiusProfile)", scope "base" (7) ldap: Waiting for search result... (7) ldap: Processing profile attributes (7) ldap: Tunnel-Medium-Type := IEEE-802 (7) ldap: Tunnel-Private-Group-Id := 100 (7) ldap: Tunnel-Type := VLAN (7) ldap: Processing user attributes
These are attributes which should go into the *final* Access-Accept, and not in any intermediate challenge packet.
I will have to take a closer look at the reply, it is only necessary in the final packet as you mention. Thanks for spotting this.
(9) Sent Access-Accept Id 9 from 127.0.0.1:1812 to 127.0.0.1:45195 length 0 (9) MS-MPPE-Recv-Key = 0x23263892d14c397f30d373067ad29f8c673a19bd0fa42a3e3b74f89cf3fa1f58 (9) MS-MPPE-Send-Key = 0x199553d51fbc32a32a4fcd3edec9f0f0a59836cca6798cd552a9baae611e7899 (9) EAP-Message = 0x03090004 (9) Message-Authenticator = 0x00000000000000000000000000000000
And the final Access-Accept doesn't contain any VLAN information. Is this what you want?
For simplicity, you might set "use_tunneled_reply", which gets you the VLAN information in the final Access-Accept.
My apologies, I have that set to 'yes' in the eap configuration on our production server. This was somehow turned off on the test server where this log was generated, I now have enabled it again.
The short fix is something like this, in the inner tunnel:
if (!session-state:Tunnel-Type ) { ldap update session-state { Tunnel-Type := &reply:Tunnel-Type } }
That will make it run "ldap" only once.
I have added this in the inner server configuration (I might have done a similar thing before) It's probably me, but it does not work unfortunately. In the debug log it clearly states: (8) server eduroam-inner { (8) session-state: No cached attributes (8) # Executing section authorize from file /etc/raddb/sites-enabled/nivo-eduroam-inner (8) authorize { so somehow the session-state is not persisted in the inner server (it is persisted in the outer server, where I cache attributes in the TLS session cache). What am I doing wrong? Cheers, Mark