Não encontrei a confirmação oficial de que o Mac OS X não suporta o PEAP-EAP-MSCHAPv2, mas também não consigo funcionar (o Windows SBS 2003 R2 e o L2TP-over-ESP com um Mac OS X 10.8 cliente aqui). Eu nem estou vendo as tentativas de login no arquivo de log do IAS. (O Log de Eventos de Segurança está cheio de todos os tipos de coisas, então eu não li muito de perto.) Eu confirmei para minha satisfação que pelo menos ISAKMP e IPsec ESP estavam trabalhando inspecionando /var/log/racoon.log no Mac, onde eu vi entradas semelhantes às seguintes (aqui 198.51.100.200 é o Mac e 192.0.2.100 é 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)
Eu também olhei para /var/log/ppp.log, que tem coisas como as seguintes:
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.
Isso recapitula a conexão bem-sucedida do IPsec mostrada no racoon.log e adiciona uma conexão L2TP bem-sucedida (o que faz sentido - o L2TP não é autenticado). Em seguida, o Mac tenta construir uma conexão PPP sobre o L2TP, como esperado, e é aí que eu começo a ver erros que não entendo:
lcp_reqci: rcvd unknown option 13
lcp_reqci: rcvd unknown option 23
lcp_reqci: returning CONFREJ.
Seguido por:
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
Observe o 'auth eap' e o 'auth chap MS-v2' acima.
Vou tentar fazer algumas das alterações que fiz na política de acesso remoto:
- reativar todos os tipos de criptografia (sem / básico / strong / mais strong, apenas o mais strong)
- remover todos os tipos de EAP e ativar somente MSCHAPv2 (foi Protected EAP [PEAP] / EAP-MSCHAPv2)
Dado que toda a troca é protegida por IPsec, eu me pergunto sobre o meu risco real. Se alguém tiver comprometido um cliente de tal forma que tenha acesso ao PSK ou ao certificado usado com o IPsec, não tenho certeza se será importante ter apenas o PEAP para autenticar a conexão PPP (pelo menos para o meu modelo de ameaça).
UPDATE: Eu reativei o MSCHAPv2 nas propriedades do servidor RRAS e na diretiva IAS que controla o acesso VPN e ativei todos os tipos de criptografia. Depois de fazer essas alterações, o Mac conseguiu se conectar novamente à VPN L2TP-sobre-IPsec, usando o MSCHAPv2 para autenticar por meio do PPP. Ativei o PEAP na política do IAS apenas para confirmar que o PEAP não funcionava e, de fato, com o PEAP ativado (mas desativado o MSCHAPv2), agora recebo uma mensagem de falha de autenticação e o Mac OS X registra o seguinte:
MS-CHAP authentication failed: E=649 No dialin permission
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
Suponho que o comportamento mais ambíguo anterior foi devido ao fato de eu ter desabilitado o MSCHAPv2 no próprio RRAS, assim como na diretiva IAS, enquanto minha configuração de teste atual tem o MSCHAPv2 habilitado no RRAS, mas desabilitado na diretiva IAS.