On Jul 9, 2025, at 12:35 PM, Christoph Egger via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I need to add MPPE keys in the reply packet for the WPA NAS to have an encrypted connection to the mobile client.
The MPPE keys are added automatically by the authentication method.
That is what the vendor says their WPA NAS requires for wireless clients. The documentation I found concerning to MPPE keys are related to MS-CHAP.
Sure. They're also used for EAP.
What keys/values can I use to add MPPE ? I am doing EAP-TTLS+PAP.
You don't "use values" for them. The values are calculated automatically. And the debug output below doesn't show it using TTLS+PAP.
The final Access-Accept should look like this:
Yes... we know that.
The full debug output:
That is NOT the full debug output. The documentation which you should have read by now explains what the full debug output is. But in any case, the debug output is large, but clear. I'll edit it and comment on it below.
authentik-freeradius-1 | (8) Received Access-Request Id 9 from 10.0.0.5:46092 to 10.1.2.1:1812 length 273
Why the extra text "authentik-freeradius-1 "? It doesn't add anything useful. i.e. the harder it is for people to follow the debug output, the harder it is to help you. There are a bunch of packets from (8) to (14) all obout TTLS, and then this:
authentik-freeradius-1 | Waking up in 4.9 seconds. authentik-freeradius-1 | (15) Received Access-Request Id 16 from 10.0.0.5:46092 to 10.1.2.1:1812 length 358 authentik-freeradius-1 | (15) User-Name = "thatsme" authentik-freeradius-1 | (15) } # if (&User-Name) = notfound authentik-freeradius-1 | (15) } # policy filter_username = notfound authentik-freeradius-1 | (15) eap: Peer sent packet with method EAP TTLS (21) authentik-freeradius-1 | (15) eap: Calling submodule eap_ttls to process data authentik-freeradius-1 | (15) eap_ttls: Authenticate authentik-freeradius-1 | (15) eap_ttls: (TLS) EAP Done initial handshake authentik-freeradius-1 | (15) eap_ttls: Session established. Proceeding to decode tunneled attributes authentik-freeradius-1 | (15) eap_ttls: Got tunneled request authentik-freeradius-1 | (15) eap_ttls: User-Name = "testuser" authentik-freeradius-1 | (15) Expecting proxy response no later than 29.667657 seconds from now
That's very weird. It should run the inner tunnel data through the virtual server "inner-tunnel". But I can't tell if that's been configured properly because the debug output has been edited to remove all of the startup information about the module configuration. Have I mentioned posting the FULL debug output before? Is there some reason why it's still being edited before posting?
authentik-freeradius-1 | Waking up in 4.5 seconds. authentik-freeradius-1 | Suppressing duplicate proxied request (too fast) to home server 172.16.1.7 port 1812 - ID: 15
That's also unusual, and shouldn't happen. There's something weird going on. Maybe with packets (0)..(7), but again I can't tell, because those have "helpfully" been removed.
authentik-freeradius-1 | (15) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! authentik-freeradius-1 | (15) BlastRADIUS check: Received packet without Message-Authenticator from home_server authentik_radius_outpost authentik-freeradius-1 | (15) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! authentik-freeradius-1 | (15) The packet does not contain Message-Authenticator, which is a security issue authentik-freeradius-1 | (15) UPGRADE THE HOME SERVER AS YOUR NETWORK IS VULNERABLE TO THE BLASTRADIUS ATTACK. authentik-freeradius-1 | (15) Once the home server is upgraded, set "require_message_authenticator = true" for home_server authentik_radius_outpost authentik-freeradius-1 | (15) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! authentik-freeradius-1 | (15) Clearing existing &reply: attributes authentik-freeradius-1 | (15) Received Access-Accept Id 15 from 172.16.1.7:1812 to 10.1.2.1:47859 length 20 authentik-freeradius-1 | (15) server default { authentik-freeradius-1 | (15) }
The Access-Accept from the home server is empty, and doesn't contain the MPPE attributes. This reply is what's being sent back to the client. That's why the MPPE attributes are msising. You've somehow configured the server in a very unusual way, and perhaps have triggered a bug. But without the full debug output, it's impossible to say more. Did I mention POST THE FULL DEBUG OUTPUT? This is the last time I will say that. There is no excuse for this continual refusal to follow the documentation and clear instructions. Alan DeKok.