Hi,
The cert is generated by freeradius' makefile, however, the EAP session stalls and FR complains: | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | WARNING: !! EAP session for state 0xe0880a2ce3de07a8 did not finish! | WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility | WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! which seems a bit circular, but I'll try to resolve this myself before asking for further assistence. Progress! It turns out that 2048-bit certificates (as generated by FR's Makefile) cause the EAP session to stall, while 1024 bit certs do work!
You tried both client certs with the same server cert, issued by the same server-CA? Because this error message /often/ comes from the client seeing an unexpected server certificate, which it doesn't trust and then walks away silently. If you can exclude server trust issues, then yes, this looks a lot like an MTU problem.
So that might indeed be an MTU issue. It's mildly surprising, though, because the FR certs are supposedly known to work.
They do: FreeRADIUS can't help it if your network has MTU problems.
Couple of things to note:
There are two MTUs to consider - the IP MTU between the NAS and radius server, and the layer2 MTU between the NAS and the supplicant.
The EAP/TLS code will segment the EAP/TLS (or TLS-based like PEAP/TTLS) data into chunks of len == Framed-MTU (from the Access-Accept) or if that's absent, the "fragment_size" option from the tls{} block of the EAP method.
So if the Access-Accept contains Framed-MTU=1024 you'll get an Access-Accept that's a few hundred bytes larger (framing plus the other attributes) which should then be a 1024-byte EAP frame at layer2.
It would be interesting to know if you're getting a Framed-MTU from the NAS, and what size radius replies you are seeing going from FR to the NAS.
I don't think this particular explanation is very helpful. Framed-MTU and fragment_size only helps in situations where the /server/ has a large chunk to send and needs to decide how to chop it up. If the conversation breaks as the /client/ certificate gets bigger, none of those two is going to help. Supplicants have their own logic for creating fragments. They know which link they are attached to, and what the MTU on that link is. So the layer2 MTU is not a problem; they can't possibly go above that. We can safely assume that this MTU is 1500 or higher on any modern network. If the client certificate is ~ 1500 or more bytes, the EAP payload needs to be fragmented. The decision on size is - as per my observations - the following: - wpa_supplicant (and by consequence MacOS, iOS, Android, Linux) has a configurable parameter which defaults to something way below 1500. - Windows fills the MTU to the max. So, when you have a Windows supplicant, be prepared that there's a full 1500 byte EAP payload coming to your NAS. The NAS then wraps this inside a RADIUS packet, which adds size, resulting in a UDP datagram that is deterministic >1500 bytes. Which in turn means that UDP fragmentation *will* occur, and the network *must* be prepared to safely deliver the multiple fragments to the RADIUS server destination. For eduroam, we are requiring UDP fragmentation support for many years, for this exact reason (and also because it also helps server-side for admins setting a high MTU in that direction). So, fix your network: let UDP fragments pass to the RADIUS server. Otherwise, your EAP-TLS deployment is going to get stuck. Or at least, fragments of it ;-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66