Proxying PEAP inner as MS-CHAP broken (was: Freeradius and Microsoft NPS)

[Phil Mayers]

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?