Diagnose EAP-TLS stalls / clients hang mid-handshake

The tell-tale sign: 802.1X hangs instead of rejecting — some devices authenticate fine, others sit and wait until they time out, and nothing is logged as a failure. That's almost never credentials; it's a large RADIUS packet carrying part of the server's certificate getting fragmented and dropped somewhere on the path.

1. Why a handshake stalls silently

During EAP-TLS (and PEAP's outer TLS) the server sends its certificate chain, which is several KB. EAP splits it across large RADIUS packets; if one exceeds the path MTU it's fragmented at the IP layer, and a firewall or tunnel that drops IP fragments makes those bytes vanish. The client waits for data that never arrives, the NAS retransmits, everything times out — no reject, just a stall. The server-side symptom is documented in the KB: EAP stalls mid-handshake — the fragment-size fix.

2. Measure the path with --mtu

Instead of guessing, the probe sends a few progressively padded packets and reports the size at which the path stops delivering them — the effective MTU between where you run it and the server:

# run the path-MTU / fragmentation probe alongside the normal checks
authhound-probe radius test --server radius.corp.com \
  --secret-file /etc/authhound/secret --mtu

Run it from the same segment the stalling clients are on — the drop is a property of the path, so where you test from matters. A jump box on a different VLAN can pass while the user VLAN fails.

3. Read the result and act

• The probe reports a reduced path MTU / large packets dropped. You've confirmed fragment loss. Two fixes, best applied together: cap the EAP fragment on the server (fragment_size = 1024 in FreeRADIUS, or the equivalent), and fix or raise the MTU on the offending hop (IPsec and GRE tunnels are the usual culprits). The full server-side fix is on the fragmentation KB page.
• Large packets get through cleanly. MTU isn't your problem. Look instead at a supplicant waiting on a certificate-trust prompt (identical retransmit pattern, but the client is waiting on a human), or a genuinely broken chain — test that with a normal --client-cert EAP-TLS run and check the cert errors in troubleshooting.
• Everything times out, including the basic checks. That's registration or reachability, not MTU — start at first-run timeouts.

Related

• EAP stalls mid-handshake — the fragment-size fix

  The server-side fragment_size fix, trimming the cert chain, and confirming with tcpdump.

• Reference: the RADIUS attributes in play

  What the Access-Accept carries once the handshake finally completes.

• Log analyzer

  Have the radiusd -X log with the "Discarding duplicate request" lines? Paste it in.