Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, June 17, 2019 12:04 PM
Hi,
We have installed Windows Server 2019 Datacenter and have installed a IKEv2 VPN on this server. This works as hoped until the server reboot's, or more specifically when the service is restarted.
If we tried to connect with a client PC we get "ike authentication credentials are unacceptable", and the only way I can resolve this from what I can tell is to Disable Routing and Remote Access and Configure and Enable Routing and Remote Access again in the same way each time:
- "Custom Configuration > VPN access"
- "Authentication Methods" > Tick "Allow machine certificate authentication for IKEv2
- "Allow custom IPsec policy for L2TP/IKEv2 connection" (Using a Preshared Key)
- Changing the "SSL Certificate Binding" for one I made
I've also run SFC /SCANNOW and powershell DISM /Online /Cleanup-Image /ScanHealth, none of which helped.
What could be stopping the VPN from continuing to work after the service has restarted?
Kind regards
Adam
All replies (7)
Monday, June 17, 2019 4:31 PM âś…Answered | 1 vote
Hello Adam,
This seems to be a straightforward case of a bug in the Microsoft software.
As you can see, in the "good" case, 4 authentication mechanisms are defined for IKEv2: EAP, RSA certificates and two Elliptic Curve certificate types. For L2TP, 2 authentication mechanisms are define: RSA certificates and a Preshared Key.
After a restart, the original IKEv2 authentication mechanisms have been "overwritten" by the L2TP mechanisms - that is why IKEv2 VPN users get the "authentication credentials are unacceptable" (because what the client sends does now not match what the server expects).
I am fairly sure that it is enabling preshared key authentication that is causing the problem.
My "two-cents worth" on your options are:
- Long term - press Microsoft to fix the bug.
- Medium term - move away from preshared key authentication (if that is "politically" possible, since you will need to manage policies on the (privately owned?) Android/Apple devices).
- Short term - be aware that the problem will occur, handle it as you do now and try to avoid restarts!
Gary
Monday, June 17, 2019 2:10 PM
Hello Adam,
When (re-)creating your configuration, why do you mention: "Allow custom IPsec policy for L2TP/IKEv2 connection" (Using a Preshared Key)?
You initially spoke about an IKEv2 VPN (which does not support preshared keys) and then added that text (even setting "Preshared Key" in a bold face).
I have been "playing" with all sorts of VPN configurations and think that I had a slightly similar situation: at one time I had configured machine certificate authentication for IKEv2 and preshared key authentication for L2TP. They were not in use at the same time and they were probably added and removed successfully several times (the server remaining up all of the time). I had been looking at the low level Windows Filtering Platform state (netsh wfp show state) and everything looked good after each change. After a while (measured in weeks/months, during which time the server had rebooted), I wanted to perform another test and encountered the "authentication credentials are unacceptable" message. I quickly looked at the WFP state and I think that the preshared key setting from the L2TP main mode policy had somehow "infected" the IKEv2 server main mode policy. I could only clear the problem by clearing the preshared key and rebooting.
A guess would be that when restoring the persisted WFP state after a reboot, the preshared key was added to the IKEv2 context. It happened just the once and I was keen to get on with my original idea, so all of this happened in rather a hurry.
In short, if you don't need preshared key authentication for anything then don't set one...
Gary
Monday, June 17, 2019 2:50 PM
Hi Gary,
Thanks for getting back to me on it, I was unaware that IKEv2 didn't support it (Sorry the bold was from where I copied it and pasted it out of a wiki I was writing at the same time and it kept the format), I especially didn't realise it wasn't supported as it said "Allow custom IPsec policy for L2TP/IKEv2 connection".
The reason I had that configured was because the Directors wanted their Android or IPhone to connect to the VPN and this seemed to allow them to connect using L2TP the Protocol. Is there another way I could get both Android and IPhone setup Ideally on IKEv2 if possible) to avoid using the PreShared Key if that's the cause of the issue?
Kind regards
Adam
Monday, June 17, 2019 3:23 PM
Hello Adam,
I think that it used to say "Allow custom IPsec policy for L2TP connection" (I found this old picture of the dialog):
I too would really like to know the full implications of this option - as far as I could determine in the past, it just enables the Preshared Key field and nothing more (but I could be wrong).
My (old) Android does not have out-of-the-box support for IKEv2 but does support L2TP with certificates ("L2TP/IPSec RSA") and I guess new Android devices and iPhone would support at least this, but then one needs to be able to enrol the Android/Apple devices into a certificate hierarchy.
What you can do, in order to be clearer about what whether I described is actually occurring in your case, is to issue the command "netsh WFP show state file=before.xml" now and then execute it again after a reboot (e.g. "netsh WFP show state file=after.xml"). The files will be several megabytes large and a simple "windiff" style comparison might get confused, but there are actually just two items in the before and after state that you need to identify and compare: the item named "IKEv2 Server Main mode IPsec tunnel policy (v4) (* to *)" and the item named "L2TP Main Mode Policy". Compare the two entries from "before" with the two entries from "after" and if they are essentially the same then you have a different problem.
To help you recognize them, this is what "IKEv2 Server Main mode IPsec tunnel policy (v4) (* to *)" looks like on my system:
<item>
<providerContextKey>{5d386cc4-292d-4bfc-9057-ac1a92a89737}</providerContextKey>
<displayData>
<name>IKEv2 Server Main mode IPsec tunnel policy (v4) (* to *)</name>
<description/>
</displayData>
<flags/>
<providerKey/>
<providerData/>
<type>FWPM_IPSEC_IKEV2_MM_CONTEXT</type>
<ikeV2MmPolicy>
<softExpirationTime>0</softExpirationTime>
<authenticationMethods numItems="4">
<item>
<authenticationMethodType>IKEEXT_EAP</authenticationMethodType>
<eapAuthentication>
<flags numItems="1">
<item>IKEEXT_EAP_FLAG_REMOTE_AUTH_ONLY</item>
</flags>
</eapAuthentication>
</item>
<item>
<authenticationMethodType>IKEEXT_CERTIFICATE_ECDSA_P384</authenticationMethodType>
<certificateAuthentication>
<inboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</inboundConfigType>
<inboundTrustedRootStoreCriteria/>
<outboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</outboundConfigType>
<outboundTrustedRootStoreCriteria numItems="2">
<item>
<certData/>
<certHash/>
<eku>
<numEku>2</numEku>
<eku numItems="2">
<item>1.3.6.1.5.5.7.3.1</item>
<item>1.3.6.1.5.5.8.2.2</item>
</eku>
</eku>
<name/>
<flags/>
</item>
<item>
<certData/>
<certHash/>
<eku>
<numEku>1</numEku>
<eku numItems="1">
<item>1.3.6.1.5.5.7.3.1</item>
</eku>
</eku>
<name/>
<flags/>
</item>
</outboundTrustedRootStoreCriteria>
<flags/>
<localCertLocationUrl/>
</certificateAuthentication>
</item>
<item>
<authenticationMethodType>IKEEXT_CERTIFICATE</authenticationMethodType>
<certificateAuthentication>
<inboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</inboundConfigType>
<inboundTrustedRootStoreCriteria/>
<outboundConfigType>3</outboundConfigType>
<flags/>
<localCertLocationUrl/>
</certificateAuthentication>
</item>
<item>
<authenticationMethodType>IKEEXT_CERTIFICATE_ECDSA_P256</authenticationMethodType>
<certificateAuthentication>
<inboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</inboundConfigType>
<inboundTrustedRootStoreCriteria/>
<outboundConfigType>3</outboundConfigType>
<flags/>
<localCertLocationUrl/>
</certificateAuthentication>
</item>
</authenticationMethods>
<initiatorImpersonationType>IKEEXT_IMPERSONATION_NONE</initiatorImpersonationType>
<ikeProposals numItems="1">
<item>
<cipherAlgorithm>
<algoIdentifier>IKEEXT_CIPHER_AES_256</algoIdentifier>
<keyLen>0</keyLen>
<rounds>0</rounds>
</cipherAlgorithm>
<integrityAlgorithm>
<algoIdentifier>IKEEXT_INTEGRITY_SHA_256</algoIdentifier>
</integrityAlgorithm>
<maxLifetimeSeconds>28800</maxLifetimeSeconds>
<dhGroup>IKEEXT_DH_ECP_384</dhGroup>
<quickModeLimit>0</quickModeLimit>
</item>
</ikeProposals>
<flags/>
<maxDynamicFilters>100</maxDynamicFilters>
<retransmitDurationSecs>1800</retransmitDurationSecs>
</ikeV2MmPolicy>
<providerContextId>9223372036854775814</providerContextId>
</item>
Gary
Monday, June 17, 2019 3:53 PM
Hi Gary,
"netsh WFP show state file=before.xml" (changed name to "working.xml" for clarity), restarted the service to break it and then did it again for netsh WFP show state file=after.xml" (changed name to "broken.xml" for clarity)
Monday, June 17, 2019 4:04 PM
Hello Adam,
You probably noticed that the extracts include your preshared key in plain text. I have seen the data and in the few seconds I took to look at it before sending this reply it looks like you have the problem that I described. I will look again in detail now, but you might want to delete your last message now.
Gary
Monday, June 17, 2019 4:11 PM
Thanks Gary, I wasn't aware of that and I have deleted the sections now.
Let me know if you needed them to look at in details and I'll remove those parts.
So is it that the Pre-Shared Key is causing the issue you say? I need to then figure out how to get the phones working without the use of the pre-shared key if that's the case.
Kind regars
Adam