I haven't found official confirmation that Mac OS X doesn't support PEAP-EAP-MSCHAPv2, but I can't get it to work either (Windows SBS 2003 R2 and L2TP-over-ESP with a Mac OS X 10.8 client here). I'm not even seeing the login attempts in the IAS log file. (The Security Event Log is full of all kinds of stuff, so I haven't read through it very closely.) I did confirm to my satisfaction that at least ISAKMP and IPsec ESP were working by inspecting /var/log/racoon.log on the Mac, where I saw entries similar to the following (here 198.51.100.200 is the Mac and 192.0.2.100 is SBS):
DEBUG: agreed on pre-shared key auth.
INFO: NAT detected: ME PEER
INFO: ISAKMP-SA established 198.51.100.200[4500]-192.0.2.100[4500] spi:0123456789abcdef:0123456789abcdef
INFO: NAT detected -> UDP encapsulation (ENC_MODE 2->61444).
INFO: IPsec-SA established: ESP/Transport 192.0.2.100[4500]->198.51.100.200[4500] spi=01234567(0x012345)
INFO: IPsec-SA established: ESP/Transport 198.51.100.200[4500]->192.0.2.100[4500] spi=89abcdef(0x6789ab)
I also looked at /var/log/ppp.log, which has stuff like the following in it:
IPSec connection started
IPSec phase 1 client started
IPSec phase 1 server replied
IPSec phase 2 started
IPSec phase 2 established
IPSec connection established
L2TP sent SCCRQ
L2TP received SCCRP
L2TP sent SCCCN
L2TP sent ICRQ
L2TP received ICRP
L2TP sent ICCN
L2TP connection established.
This recaps the successful IPsec connection shown in racoon.log and adds a successful L2TP connection (which makes sense - L2TP is itself unauthenticated). Next, the Mac tries to build a PPP connection over L2TP, as expected, and this is where I start to see errors that I don't understand:
lcp_reqci: rcvd unknown option 13
lcp_reqci: rcvd unknown option 23
lcp_reqci: returning CONFREJ.
Followed by:
sent [LCP ConfRej id=0x0...
rcvd [LCP ConfAck id=0x1...
rcvd [LCP ConfReq id=0x1 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x1 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x2 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x2 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x3 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x3 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x4 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x4 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x5 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x5 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x6 <mru 1400> <auth eap>...
lcp_reqci: returning CONFREJ.
sent [LCP ConfRej id=0x6 <auth eap>]
rcvd [LCP TermReq id=0x7...
sent [LCP TermAck id=0x7]
Fatal signal 6
Note the 'auth eap' and 'auth chap MS-v2' in the above.
I'm going to try backing out some of the changes I made to the remote access policy:
- re-enable all encryption types (no/basic/strong/strongest, was strongest only)
- remove all EAP types and enable only MSCHAPv2 (was Protected EAP [PEAP]/EAP-MSCHAPv2)
Given that the entire exchange is protected by IPsec, I wonder about my actual risk. If someone's compromised a client such that they have access to the PSK or certificate used with IPsec, I'm not sure if having only PEAP to authenticate the PPP connection will matter (at least, for my threat model).
UPDATE: I re-enabled MSCHAPv2 in both the RRAS server properties and in the IAS policy that controls VPN access, and I enabled all encryption types. After making these changes the Mac was able to connect to the L2TP-over-IPsec VPN again, using MSCHAPv2 to authenticate over PPP. I toggled PEAP on and off in the IAS policy just to confirm that PEAP would not work, and in fact, with PEAP enabled (but MSCHAPv2 disabled), I now receive an authentication failure message, and Mac OS X logs the following:
MS-CHAP authentication failed: E=649 No dialin permission
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
I suppose the more ambiguous behavior before was due to the fact that I disabled MSCHAPv2 in RRAS itself as well as in the IAS policy, whereas my current test configuration has MSCHAPv2 enabled in RRAS but disabled in the IAS policy.