Access-Accept OK · client never associates

EAP succeeds but Wi-Fi won't connect — MPPE keys stripped by the proxy

This is one of the most disorienting RADIUS failures: the server log says Access-Accept, EAP completed, the user is “authenticated” — and the client still won’t get onto the Wi-Fi. It sits at “obtaining IP address” or drops back to the password prompt. The authentication genuinely succeeded. What failed is keying.

What’s actually happening

For any EAP method on WPA2/WPA3-Enterprise, a successful handshake produces session keys. The RADIUS server hands those to the access point inside two vendor attributes on the Access-Accept — MS-MPPE-Send-Key and MS-MPPE-Recv-Key — encrypted under the RADIUS shared secret. The AP needs them to run the 4-way handshake and actually encrypt the air. No keys at the AP, no working Wi-Fi — regardless of how clean the auth looked server-side.

So when EAP “succeeds” but the client can’t associate, ask one question: did the MPPE keys reach the access point intact? Two things stop them.

1. A RADIUS proxy stripped the VSAs

If auth passes through a proxy (a regional RADIUS, an ISE/NPS chain, a cloud RADIUS relay), a proxy that doesn’t forward vendor-specific attributes will pass the Access-Accept along while dropping MS-MPPE-Send-Key/MS-MPPE-Recv-Key. The final AP gets an accept with no keys. Fingerprint: it works when the AP talks to the home server directly and fails only through the proxy. Check: capture the Access-Accept as the AP receives it (on the last hop) and confirm both MPPE key attributes are present.

2. A shared-secret mismatch corrupted the keys

The keys are encrypted under the shared secret. If a secret is wrong on one hop — even when the packet still validates far enough to look “accepted” — the AP decrypts garbage keys and the 4-way handshake fails. This is the same root cause as FreeRADIUS ‘invalid Message-Authenticator’ and NPS Reason Code 262, just surfacing one layer later. Check: verify the shared secret on every hop between the AP and the authenticating server, not just the first.

3. (Rule it out) It’s not a VLAN or DHCP problem

“Authenticated but no network” also describes a dynamic VLAN that didn’t apply or a dead DHCP scope. Tell them apart by where it stalls: MPPE-key failures break the 802.11 association / 4-way handshake (the client never fully connects); VLAN/DHCP failures happen after association (connected, but no usable IP). If the client never reaches “connected,” you’re on this page.

The one diagnostic that settles it

Packet-capture the Access-Accept on the segment between the last RADIUS hop and the AP, and look for Vendor-Specific attributes 16 and 17 (Microsoft, vendor 311). Present and the client still fails → suspect a shared-secret mismatch corrupting them (cause 2). Absent → a hop stripped them (cause 1). Because the payload is encrypted you won’t read the key bytes, but their presence or absence is the whole answer.