Based on my experience..
I never found an answer and I am still using NPS as a proxy server for machine EAP-PEAP. I had issues with the certificate trust chain and GoDaddy now has 2 intermediates. They changed things at one point from a single intermediate to 2. NPS sees the cert different than OpenSSL with the trust chain. I was going to move to internal RootCA and then I had found out that the rootCA is still doing SHA-1 and I didn't want to generate a cert and use something that needs to be updated.
All I can offer is what I had found from the inner-tunnel of authentication from freeradius. It never had anything to do with what the TLS size or MTU was of any features. If successful authentication happened from the inner-tunnel (mschapv2) then the Framed-MTU would be updated in the debugs.
If there was a timeout or an issue with the inner-tunnel then the Framed-MTU would not be updated. I am not aware of their settings for the inner-tunnel and cant comment on what module is responsible for returning that value.
I would probably recommend debugs on clearpass to find out where these clients had got to in the process of authentication. You will probably want to enable debugs on only the server for that region you are looking to process and you will need to be aware of when the TLS cert is accepted vs authentication is handed off to the inner tunnel for mschap. There is most likely a certificate not being accepted or something that is restricting authentication to be completed.
Debugs to enabled (Radius Server - Debug, Policy Server [AD/LDAP - debug]) You may also need the following from the Policy Sever Module for logging as well.. [Request Handeling - info], [Common Framework - Info]. Just make sure you disable them when finished as they can append to logging.
You should see something to inform you that you are passing to module rlm_mschap as this is the inner tunnel along the lines below. This example was from a user 802.1x and not machine 802.1x via EAP-PEAP. (username and domain were updated with generic).
We can see that MSCHAPv2 was successful, at this point you can look for the Framed-MTU in the debugs. You will see that the framed MTU changes post rlm_mschap vs before. Access tracker will only show you the final Framed-MTU of what was completed in the logic. DEBUG RadiusServer.Radius - modcall: leaving group svc_USER 802.1x]_inner_3007 (returns updated) for request 4560569
..INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Response from client
..DEBUG RadiusServer.Radius - Processing the authenticate section of radiusd.conf
INFO RadiusServer.Radius - rlm_mschap: MSCHAPv2 username used for challenge computation <USERNAME>
DEBUG RadiusServer.Radius - rlm_mschap: Using user account name <USERNAME> fetched from auth source
INFO RadiusServer.Radius - rlm_mschap: Using domain <DOMAIN> from objectSid attribute
DEBUG RadiusServer.Radius - rlm_mschap: Updating NetBIOS-Name to <DOMAIN>
DEBUG RadiusServer.Radius - rlm_mschap: socket directory of <DOMAIN> domain is /var/avenda/tips/samba/samba_<DOMAIN>/winbindd_privileged
INFO RadiusServer.Radius - rlm_mschap: authenticating user <USERNAME>, domain <DOMAIN>
INFO RadiusServer.Radius - rlm_mschap: user <USERNAME> authenticated successfully
DEBUG RadiusServer.Radius - rlm_mschap: MSCHAPv2 succeeded
Another side node... When looking at EAP-TLS for the certificate negotiation. It will be in a hash (not sure if its base64, or how its hashed / encrypted). It will not be in plan text, and instead will be more along the lines with the following... If you are doing a radius debug in the IAP you may see the actual cert being offered. I have always done debugs in AOS vs IAP, so I can only talk there.
Either way I was able to compare the section that said "EAP-MESSAGE" like below to when the cert was being offered and negotiated upon. After this is all checked out it will be passed to inner tunnel. EAP-Message = 0x0136040619410302010202021be715300d06092a86 ...
EAP-Message = 0x02031328476f20446164747920526f6f74204365727 ...
EAP-Message = 0x819a0e29c51ca8e95d1eb69e9e300a39cef18880fb4 ...
EAP-Message = 0x33293027a125a0238621687474703a2f2f63726c2e6 ...
EAP-Message = 0xafd5bf24fnb1c3d ...
You are welcome to PM me if you want to ask any additional questions. Based on what you are seeing with timeouts there is probably some sort of communication issue between the site and clearpass or there is a certificate issue similar to what I had seen on godaddy. I still have no resolution and hope to get back to this in a few months.
Sent: May 18, 2022 11:15 AM
From: Andy Jezierski
Subject: CPPM EAP Timeouts - Framed MTU value
Just curious if anyone has ever figured out what this issue is. I'm running across the same problem. Most devices connect just fine, but I have a handful of devices that always get a timeout and can never connect, other devices will connect at times and at other times will result in a timeout.
All windows 10 PCs, getting the same GPO pushed out, located in different locations, connecting to different ClearPass servers in different countries. PCs doing EAP-PEAP machine authentication. Recently upgraded to CPPM 6.10.5 to see if that would fix anything, but it has not. APs are a mixture of 305s & 315s managed by Central.
Successful authentications always show Radius:IETF:Framed-MTU 768 Requests that result in a Error Code: 9002 Timeout always show Radius:IETF:Framed-MTU 1100 or 1400 Clearpass set for default EAP-TLS size of 1024.
Sent: Sep 07, 2020 10:48 PM
From: Scott Doorey
Subject: CPPM EAP Timeouts - Framed MTU value
Thanks for your reply.
I have checked the difference between successful and failed attempts and this is where i've noticed that there is a difference.
Successful requests have a size of 768 and failed attempts 1100.
I have intermittent issues on the same AP with different clients.
The same client could work 3 times and then timeout on the same AP so i'm thinking its likely some kind of client side issue. trying to get to the bottom of why the two MTU sizes listed in the request would be different.