On 13/04/11 16:22, Alan DeKok wrote:
Phil Mayers wrote:
Actually, I was just testing this and proxying the inner EAP-MSCHAPv2 as plain MS-CHAPv2 seems to be broken, at least in my testing. It doesn't crash the server, but equally it doesn't pass the S=XXX success back correctly either, so the client does a PEAP reject.
Hmm... OK.
Ok; the problem seems to be that mschap_postproxy is never run, because the "eap" module in the inner-tunnel is returning NOOP. AFAICT this can only happen if "request->proxy_reply == NULL", but I don't see how that can be. On a working version of 2.1.1, we see: rad_recv: Access-Accept packet from host 155.198.30.59 port 1812, id=8, length=227 Proxy-State = 0x38 Framed-Protocol = PPP Service-Type = Framed-User Class = ... MS-MPPE-Recv-Key = 0xce2bf43311878d6da4657e39ecc46f35 MS-MPPE-Send-Key = 0x6342361df2ade968d8f02a297f16025b MS-CHAP2-Success = ... +- entering group post-proxy {...} [eap] Doing post-proxy callback [eap] Passing reply from proxy back into the tunnel. server inner-tunnel { [eap] Passing reply back for EAP-MS-CHAP-V2 +- entering group post-proxy {...} [eap] Doing post-proxy callback rlm_eap_mschapv2: Passing reply from proxy back into the tunnel 0xb2e4d0 2. rlm_eap_mschapv2: Authentication succeeded. MSCHAP Success ++[eap] returns ok } # server inner-tunnel [eap] Final reply from tunneled session code 11 ...and the reply has turned into an Access-Challenge. But in v2.1.x HEAD we see: rad_recv: Access-Accept packet from host 155.198.30.59 port 1812, id=130, length=227 Proxy-State = 0x38 Framed-Protocol = PPP Service-Type = Framed-User Class = ... MS-MPPE-Recv-Key = 0x19ced6034408d55a75c8f0470f208337 MS-MPPE-Send-Key = 0x7889a7dd82d892c6d40b7d58d686b1f5 MS-CHAP2-Success = ... MS-CHAP-Domain = "\010IC" # Executing section post-proxy from file /home/pjm3/frdev/usr/local/etc/raddb/sites-enabled/default +- entering group post-proxy {...} [eap] Doing post-proxy callback [eap] Passing reply from proxy back into the tunnel. server inner-tunnel { [eap] Passing reply back for EAP-MS-CHAP-V2 # Executing section post-proxy from file /home/pjm3/frdev/usr/local/etc/raddb/sites-enabled/inner-tunnel +- entering group post-proxy {...} ...and then it goes off the rails: ++[eap] returns noop WARNING: Empty post-auth section. Using default return values. # Executing section post-auth from file /home/pjm3/frdev/usr/local/etc/raddb/sites-enabled/inner-tunnel } # server inner-tunnel [eap] Final reply from tunneled session code 2 ...since mschap_postproxy hasn't run, the access-accept reply code hasn't been transformed into an access-challenge, the MS-CHAP-Success isn't tunneled back to the client and an EAP-TLV Success is sent - which the client rightly rejects. I'm a bit stuck as to why rlm_eap is returning noop for inner-tunnel in 2.1.10 but not in 2.1.1, but I guess it's related to the other changes in this area?