Hi!   We are experiencing the same problem, and we were able to reproduce it using the following  environment:  Auth method: EAP-MSCHAPv2 against file with clear text passwords.  NAS: Nokia vSR 7750  FreeRADIUS 3.0.21  3 clients tested:   - Linux (StrongSwan client): works OK  - MacOS (native client): partial OK. Works only if “local-id” is set with the username.  - Windows 10 (native client): KO     We check in logs that we receive the local IP address from the Windows and Mac clients as the user-name attribute. During MSCHAPv2 challenge, the user-name provided to the identity backend is the local IP address, thus making the authentication fail, as it doesn’t receive the actual username.    Digging a little further in the issue, we see that clients do not send the actual username because they do not receive the Identity request from RADIUS server. Likewise, FreeRadius doesn’t send the Identity Request because it didn’t receive an EAP start message. This behaviour is documented in the “handled" return code in the Processing/authorize section of the EAP module documentation ( https://networkradius.com/doc/current/raddb/mods-available/eap.html)  Here the relevant log in our environment:  Ready to process requests  (3) Received Access-Request Id 7 from 85.57.4.42:64391 to 10.0.103.175:1812 length 145  (3)   User-Name = "192.168.1.19"  (3)   Acct-Session-Id = "85.51.29.253-87.217.240.140:4500-1589384382"  (3)   NAS-Port-Id = "tunnel-1.public:10"  (3)   NAS-Identifier = "secgw01"  (3)   EAP-Message = 0x020b0011013139322e3136382e312e3139  (3)   Message-Authenticator = 0x9f6ec0d3f5148c3a19ecc9580cc24d61  (3) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default  As discussed before in this thread, this behavior considers the EAP start as a MANDATORY, when the RFC 3579 says that: "the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start” (page 7).  In other NAS like StrongSwan server, we have found that this specific issue has forced StrongSwan to send the identity request to the client on behalf of the FreeRADIUS server. In our view, maybe this is something that shouldn’t be done, as the NAS is impersonating part of the RADIUS flow, right?    We have tried to shortcut this issue and we modified the source code with a quick & very dirty workaround in line 691 of eap.c file (https://github.com/FreeRADIUS/freeradius-server/blob/af8643bd8b7487fd687dee2...), making EAP messages containing certain length to enter the "if" statement, and thus making FreeRadius to act if it received the EAP START message:  if ((eap_msg->vp_length == 0) || (eap_msg->vp_length == 2) || (eap_msg->vp_length == 18) || (eap_msg->vp_length == 14)) {  Note here that we specified length of 18 and 14, as it was the two lengths that we were receiving from our two test clients. This obviously cannot be a general solution, as this length varies with the user-name field.  ** The first question here is: How should be in your opinion this made, and implement the MAY instead of MUST?    After “fixing” this issue, we have found also that there’s s paranoid check in this very same eap.c file (https://github.com/FreeRADIUS/freeradius-server/blob/af8643bd8b7487fd687dee2...) FreeRadius checks if sent user-name value matches identity. Unfortunately, it doesn´t, because Windows and Mac send local IP address as user-name and the actual username as the identity:  “Identity does not match User-Name, setting from EAP Identity” Again, we did the trick of deleting this check and continued forward.  ** Second question here: should this check be deleted, as there’re legitim use cases that do not comply with this? Should this be configurable via a configuration option?    Finally, we get to a dead end with the nt_password validation. FreeRADIUS is using the user-name field to look for the password, instead of using the identity field. So, authentication fails because rlm_mschap module doesn’t find the provided username (it’s a local IP address!), and thus validations fail, even when the right password is sent. We ended up in this file: https://github.com/FreeRADIUS/freeradius-server/blob/aeb8d49ba823ee69f8a032b...   **So third and last question is: which and where to change the provided parameters to mschap module in order to send the right ones (identity vs. user-name)?  We really appreciate your support on this. We have tried our best to provide as much detail as possible, even when we are not RADIUS experts, nor having knowledge on FreeRadius source code.  Best, Fer Alvarez