I have a problem – which I am wondering if anyone else has come across.
I have been tracking this problem since the release of 1803 last summer (2018).
This problem ONLY happens on Windows 10 1083 and Windows 10 1809 – In 1703 and below the problem does not reproduce.
The configuration is IKEv2 with EAP Smart Card or other Certificate.
Keep in mind as I explain the configuration that this rig and certificates, work fine on MACOS (current versions) iOS (12) and Windows 10 clients previous to and including 1703.
The issue is simply that the 1803 and 1809 client refused to connect. Point blank.
I upgraded the VPN server after reading a post concerning IKE auth fragmentation which is on by default in 1803 and 1809 and only supported in 2019.
I enabled fragmentation registry key on the 2019 server side and the traces show, no more split packets (against 1803/9) at OSI layer 4 (UDP). Great!
However still no connection.
I tried setting up a simple PPTP VPN connection – but got an error assigning IP address. This manifests as the following application event log on the client.
CoId={0FFE030D-5109-4498-854A-26F738804AEF}: The user DESKTOP-IGRMCJS\delete dialed a connection named test which has failed. The error code returned on failure is 942.
The server shows:
CoId={5CCE87DB-DA3B-6307-5AE8-7D3303AE1B71}: The following error occurred in the Point to Point Protocol module on port: VPN2-9, UserName: someone@somewhere.co.com.ic Error in assigning inner IP address to initiator in tunnel mode.
Odd.
The trace showed re-transmits in LCP (Line Configuration Protocol) so I gave up with that route and went back to IKEv2.
This time I decided to drop certificates and just use PEAP and MSCHAPv2 password style auth.
I still got the same error reported in the event log as above.
I managed to resolve this on 1803 and 1809 by enabling IPV6 and nothing else worked.
The doc above casually mentions at the bottom that one could add IPv6 support – so I did and hey presto it worked!
The next layer was to get the cert working over EAP. CNG has been broken and fixed quite a few times in the current Microsoft Client. I suspected that CNG was / is the issue.
To test my theory I issued a new (lower strength) certificate which uses a legacy crypto provider. ‘Microsoft Enhanced Cryptographic Provider V1.0’ a 2048 bit key size and a SHA2 signing algorithm. (Determined at the parent level in any case).
Guess what this works too!
So the problem falls fairly and squarely in the camp of the VPN client not correctly acquiring or transmitting the authentication material to the VPN (RRAS / NAP) server; in the case that the certificate type is of CNG. Keep in mind at this point the SAME certificate works fine on 1709, MACOS and iOS – to the same VPN server.
I am asserting that the problem is the newer win10 clients based on the following in the NPS event logs.
System:
CoId={A1E4D31E-A1A7-A6AF-742E-491177C98A20}: The following error occurred in the Point to Point Protocol module on port: VPN2-9, UserName: <Unauthenticated User>. The connection could not be established because the authentication method used by your connection profile is not permitted for use by an access policy configured on the RAS/VPN server. Specifically, this could be due to configuration differences between the authentication method selected on the RAS/VPN server and the access policy configured for it.
Security:
Authentication Details:
Connection Request Policy Name: Microsoft Routing and Remote Access Service Policy
Network Policy Name: NAP VPN
Authentication Provider: Windows
Authentication Server: Server.somwhere.com
Authentication Type: Unauthenticated
EAP Type: Microsoft: Smart Card or other certificate
Account Session Identifier: 3430
Logging Results: Accounting information was written to the local log file.
Reason Code: 66
Reason: The user attempted to use an authentication method that is not enabled on the matching network policy.
Client
CoId={4A37145E-6AB8-4427-BEDF-7491B737A0DB}: The user DESKTOP-IGRMCJS\delete dialed a connection named test which has failed. The error code returned on failure is 942.
The NPS log contains a lot of PII so I not going to include it here. However suffice it to say it shows auth type of 5 (EAP) five times in the same second and the correct username (UPN pulled from the SAN field in the cert) and then finally a 7. This is unauthenticated.
I just wonder if I am the only one using EDCH512 and SHA2512 certificates over IKEv2 and VPN in the universe – or if this is currently a known issue??