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?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
