OK, so the presumed workaround did not actually work around the problem. 😞
I would suggest you use wireshark (or similar) to check the actual size of the RADIUS communication packets, because your test with ping and the Framed-MTU value suggest that the MTU size is not the problem.
If the VPN MTU is the problem, you should be able to see RADIUS packets on the interface leading to the VPN, but not on the other end exiting the VPN. There might even be ICMP Packet Too Big message visible in a packet trace. If the MTU is the problem, no larger packet at all can cross the VPN. You can verify the actual VPN MTU using "ping -f -l SIZE" (on Windows). The generated IP packet will be 28 bytes bigger than SIZE, you can see this in wireshark.
If a packet from RADIUS server to the AP containing part of a certificate is lost, this authentication session can only succeed if the re-transmit timer and count of the RADIUS client match the RADIUS server settings for re-transmits. If a re-transmitted packet arrives after the time allowed by the server, the server will answer with an Access-Reject.
Extreme Control accepts an answer inside a 5s window after sending a packet. If it takes the client longer to request a re-transmit for a lost packet from the server, the authentication session will fail (Access-Reject). This problem exists only with bigger RADIUS messages needing more than one packet (e.g. a certificate), because in most other cases the RADIUS server will treat the re-transmit request as a completely new session.
Anyway, if the problem really is an MTU problem because of the VPN, you might be able to fragment inside the VPN despite the dont-fragment bit. This of course depends on the VPN solution used.