Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Following the recent security advisory, I'm reconfiguring our VPN servers and having trouble.

We're using Windows 2008 R2 server for VPN services, running RRAS and NPS on the same server and configure it to use PEAP-EAP-MSCHAPV2 authentiation for all tunnel type(PPTP, L2TP, IKEv2, SSTP), which previously allowed plain MSCHAPv2.

But Apple products, MacOS and iOS cannot connect to VPN after this change. I tried to install root certificate used in PEAP transaction but no change.

Does anyone know whether MacOS/iOS supports PEAP-EAP-MSCHAPv2 authentication in PPTP/L2TP? If so any tips to make it work? (I know PEAP-EAP-MSCHAPv2 is supported in WPA/WPA2 enterprise)


share|improve this question
I've been testing this for a Customer. I'm finding that neither MacOS or iOS supports PEAP for PPTP. I haven't tested L2TP. Sniffing confirms that the clients never attempt PEAP. – Evan Anderson Sep 26 '12 at 4:32

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 is the Mac and is SBS):

DEBUG: agreed on pre-shared key auth.
INFO: NAT detected: ME PEER
INFO: ISAKMP-SA established[4500]-[4500] spi:0123456789abcdef:0123456789abcdef
INFO: NAT detected -> UDP encapsulation (ENC_MODE 2->61444).
INFO: IPsec-SA established: ESP/Transport[4500]->[4500] spi=01234567(0x012345)
INFO: IPsec-SA established: ESP/Transport[4500]->[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 received SCCRP
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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.