L2TP avec authentification PEAP depuis MacOS/iOS

Je n'ai pas trouvé de confirmation officielle que Mac OS X ne supporte pas PEAP-EAP-MSCHAPv2, mais je n'arrive pas non plus à le faire fonctionner (Windows SBS 2003 R2 et L2TP-over-ESP avec un client Mac OS X 10.8 ici). Je ne vois même pas les tentatives de connexion dans le fichier journal IAS. (Le journal des événements de sécurité est rempli de toutes sortes de choses, je ne l'ai donc pas lu de très près). J'ai confirmé à ma satisfaction qu'au moins ISAKMP et IPsec ESP fonctionnaient en inspectant /var/log/racoon.log sur le Mac, où j'ai vu des entrées similaires à ce qui suit (ici 198.51.100.200 est le Mac et 192.0.2.100 est 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)

J'ai également regardé le fichier /var/log/ppp.log, qui contient des éléments tels que les suivants :

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.

Cela récapitule la connexion IPsec réussie indiquée dans racoon.log et ajoute une connexion L2TP réussie (ce qui est logique - L2TP est lui-même non authentifié). Ensuite, le Mac essaie d'établir une connexion PPP sur L2TP, comme prévu, et c'est là que je commence à voir des erreurs que je ne comprends pas :

lcp_reqci: rcvd unknown option 13
lcp_reqci: rcvd unknown option 23
lcp_reqci: returning CONFREJ.

Suivi par :

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

Notez les mentions "auth eap" et "auth chap MS-v2" dans le texte ci-dessus.

Je vais essayer d'annuler certaines des modifications que j'ai apportées à la politique d'accès à distance :

• réactivation de tous les types de cryptage (no/basic/strongest/strongest, était strongest only)
• supprimer tous les types d'EAP et n'activer que MSCHAPv2 (était Protected EAP [PEAP]/EAP-MSCHAPv2)

Étant donné que l'ensemble de l'échange est protégé par IPsec, je m'interroge sur mon risque réel. Si quelqu'un compromet un client de telle sorte qu'il a accès au PSK ou au certificat utilisé avec IPsec, je ne suis pas sûr que le fait de n'avoir que PEAP pour authentifier la connexion PPP soit important (du moins, pour mon modèle de menace).

MISE À JOUR : J'ai réactivé MSCHAPv2 dans les propriétés du serveur RRAS et dans la politique IAS qui contrôle l'accès au VPN, et j'ai activé tous les types de cryptage. Après avoir effectué ces changements, le Mac a pu se connecter à nouveau au VPN L2TP-over-IPsec, en utilisant MSCHAPv2 pour s'authentifier sur PPP. J'ai activé et désactivé PEAP dans la politique IAS juste pour confirmer que PEAP ne fonctionnerait pas, et en fait, avec PEAP activé (mais MSCHAPv2 désactivé), je reçois maintenant un message d'échec d'authentification, et Mac OS X enregistre ce qui suit :

MS-CHAP authentication failed: E=649 No dialin permission
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]

Je suppose que le comportement plus ambigu avant était dû au fait que je désactivais MSCHAPv2 dans RRAS lui-même ainsi que dans la politique IAS, alors que dans ma configuration de test actuelle, MSCHAPv2 est activé dans RRAS mais désactivé dans la politique IAS.