On 11 February 2016 at 09:44, Jonathan Gazeley < Jonathan.Gazeley@bristol.ac.uk> wrote:
We've upgraded our FreeRADIUS 2.2.x servers to FreeRADIUS 3.0.11 because it was about time. Since then, we're having a subtle problem with session resumption where in some cases, FreeRADIUS returns two Access-Accept packets, each with differing VLAN information which breaks the client. The double reply only occurs when EAP sessions have been resumed, but not with every resumed session. ... I hope today to capture enough debug information to be able to submit a detailed report to this list.
Further to my colleague Jonathans email from last week, we've now managed to reproduce this issue reliably, using eapol_test. Output of "radiusd -X" covering server startup and a failed test auth can be found here https://www.wireless.bris.ac.uk/software-archive/fr3-debug-20160215.txt as it was too big to attach to this message. our eapol_test.conf contains: --- eapol_version=1 fast_reauth=1 network={ key_mgmt=WPA-EAP eap=PEAP identity="iser-linauth@bris.ac.uk" anonymous_identity="anonymous@bris.ac.uk" password="REDACTED" ca_cert="/usr/lib64/nagios/plugins/wpa_supplicant/uob-net-ca.pem" phase2="auth=MSCHAPV2" priority=10 } --- Our config uses Reply:User-Name to determine which vlan a user should go in, and on a full (non-resumed) authentication, this works fine. However, It appears that on a resumed session, the Reply:User-Name is blank after the session details are pulled out of the cache - which is why our VLAN selection logic fails to perform as expected. Eg: [Lines 4472 - 4475] (13) if (reply:User-Name =~ /(^[[:alpha:]]+[[:digit:]]+v@|^[[:alnum:]]+-[[:alnum:]]+@)/) { (13) ERROR: Failed retrieving values required to evaluate condition (13) elsif (reply:User-Name =~ /(uob\\\\?)?([a-z0-9\\-\\.]+)(@bris(tol)?\\.ac\\.uk)/){ (13) ERROR: Failed retrieving values required to evaluate condition I'm hesitant to speculate about what's going on, but it looks to me like the cache is being populated with the wrong value for Reply:Stripped-User-Name - instead of being a stripped version of the Reply:User-Name (from the inner) it's based on the anonymous outer identity. [Lines 4315-4317] (12) eap_peap: Adding cached attributes from session bae26d00e8f00847e2e781985039e5f978cd8856e804b3c7ac6ce276e084f7d9 (12) eap_peap: reply:User-Name := "iser-linauth@bristol.ac.uk" (12) eap_peap: reply:Stripped-User-Name = "anonymous" I can confirm that turning off eap caching makes the symptoms problem go away, although obviously there are implications to doing that. Can anyone tell us what's going on, and how we can fix it? -Paul -- ---------------------------------------------------------------------- Paul Seward, Senior Systems Administrator, University of Bristol Paul.Seward@bristol.ac.uk +44 (0)117 39 41148 GPG Key ID: E24DA8A2 GPG Fingerprint: 7210 4E4A B5FC 7D9C 39F8 5C3C 6759 3937 E24D A8A2