The problem is ALWAYS the same. The Wiki page describes the problems, and the solutions.
That particular error is known to pop out when a Windows client uses a misconfigured certificate, or the MTU is too high. This case is neither one nor the other.
Try setting up the second server as a brand new server with brand new certificates. Follow the *documented* process of setting up a new server with EAP-TLS / PEAP. It *will* work.
I have no heavy modifications of the original configuration, just the minimum required for eap-peap-mschapv2 to work. Which has been copied from a working server. It's probably the cert.
I suspected that, but I'm making no progress with it, and I've ended with the process pretty much automated. I will continue doing tests, but i felt i was missing something else. If it's NOT the cert, then you need to investigate the AP/switch or the
client; FreeRADIUS is not receiving the next packet, so either the client or the AP/switch has dropped / ignored it.
Maybe, but the only change made was the address where to point at. However, i should check that too.
One thing to check is MTU; you've trimmed the debug so it's hard to know, but usually the next EAP packet would be large(-ish).
Framed-MTU = 1100 << from debug fragment_size = 1024 << eap.conf (default setting) Also check the client - look in the logs, or use tcpdump to check the
client actually receives the EAP packet, and sends a reply. Likewise the AP/switch.
Also check any firewalls inbetween.
Yes, it shows a conversation, so no dropped packets inbetween. -- Alberto Martínez Setién Servicio Informático Universidad de Deusto Avda. de las Universidades, 24 48007 - Bilbao (SPAIN) Phone: +34 - 94 413 90 00 Ext 2684 Fax: +34 - 94 413 91 01