Share via


L2TP/IPSEC VPN Client Connection will not work

Question

Sunday, May 5, 2019 6:40 PM

I've finally successfully created a client vpn pptp connection between my home and remote pc's. the home pc is win10pro 1809 .475 and the remote pc is win10home 1809 .475.

I am now trying to create a more secure L2TP/IPSec client VPN connection and get this:

Can't connect to l2tpvpn.

The L2TP connection attempt failed because the security layer could not negotiate compatible parameters with the remote computer.

I am using a pre-shared key not a certificate. 

I have allow these protocols  checked along with Microsoft CHAP v2 selected .

Changing Data Encryption values doesn't result in any difference.

I have made sure that all the appropriate firewall entries are made both inbound and outbound. 50,500,4500,1701

I have made sure that all the required services are started.

I have AssumeUDPEncapsulationContextOnSendRule = 2 in my registry.

I have uninstalled every WAN miniport and restarted the machine and recreated the vpn client connection entry.

What diagnostics do you suggest I perform?

TIA

All replies (12)

Monday, May 6, 2019 2:38 AM

Hi,

Make sure that these 2 service are started.

IKE and AuthIP IPsec Keying Modules” and “IPsec Policy Agent” 

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]


Monday, May 6, 2019 2:19 PM

Travis, yes both of those services are started. they are running as Automatic(Trigger Start)

I do notice that if I create a rule in the firewall to open ports 50, 500,4500 it says that are protocol 17 in properties. I read this:

/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd458955(v=ws.10)

where it states ports 500,4500 should be opened inbound/outbound and that protocol 50 should be enabled both inbound and outbound. 

So I create a custom rule selecting protocol 50 and another rule for ports 500,4500, and that didn't work either. 

It's funny but a pptp vpn client connection works fine with encryption set to maximum encryption, but so far I can't get L2tp/IPsec or SSTP vpn client connections to work. I'm saving the sstp post for later ..hahahaha

I am using a pre-shared key for the client vpn connection. I know of no way to enter this pre-shared key on the vpn server incoming connection, or if it even needs to have it. 


Monday, May 6, 2019 4:22 PM

Hello rocketjetz,

As you may have guessed, a "pre-shared key" is a key that is shared (i.e. known by both) server and client before ("pre-") establishing a connection.

If the VPN server has not been configured to know the pre-shared key then pre-shared key authentication will not work. There is no obvious way of defining a pre-shared key for an "Incoming Connections" network connection definition.

There does seem to be a trick that works to specify a pre-shared key (I blogged about this here: http://gary-nebbett.blogspot.com/2018/10/establishing-vpn-connection-from-macos.html): define a “dummy” IPsec tunnel with “Preshared key” authentication; any tool can be used to do this (e.g. the “Windows Defender Firewall with Advanced Security” control panel applet, the “netsh advfirewall consec add rule” command or the “New-NetIPsecRule” PowerShell cmdlet). Obviously, having more than one IPsec tunnel definition with a (different) pre-shared key is problematic.

Gary


Monday, May 6, 2019 9:08 PM

"As you may have guessed, a "pre-shared key" is a key that is shared (i.e. known by both) server and client before ("pre-") establishing a connection.

If the VPN server has not been configured to know the pre-shared key then pre-shared key authentication will not work. There is no obvious way of defining a pre-shared key for an "Incoming Connections" network connection definition."

I think that about states the obvious.

TIA

I guess I will have to install OpenVPN Server/client and figure out how to config it for L2TP. I was hoping not to have to do that, because the few windows config websites I have seen about it , makes it look like a major pain in the ass.

Microsoft: Is their a registry edit that would allow me to put in the pre-shared key on a vpn server, actually win10pro? powershell? wmic? 

Just asking...... 


Tuesday, May 7, 2019 9:20 AM

Hi,

Did you use RRAS as VPN server?

If so, you need to enter preshared key on VPN server.

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]


Tuesday, May 7, 2019 10:04 PM

I am using win10pro 1809  .475   there is No RRAS server on Win10pro or home but they both allow you to create incoming connection aka vpn server and l2tp vpn client connections.


Wednesday, May 8, 2019 7:48 AM

Hi,

If you use incoming connection, it doesn't support pre-shared key.

As shown in the picture above, you need to enter preshared key both on the server and client.

I would suggest you use another authentication methods.

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]


Wednesday, May 8, 2019 3:16 PM

Hello Travis,

There is no built-in human interface explicitly intended for setting a (server-side) pre-shared key for L2TP/IPsec authentication under Windows 10 Pro, but this does not mean that it is not supported. The side-effects of the commands that I mentioned in an earlier message set a pre-shared key; alternatively, one can write a short program that calls MprAdminInterfaceSetCredentialsEx (https://docs.microsoft.com/en-gb/windows/desktop/api/mprapi/nf-mprapi-mpradmininterfacesetcredentialsex documents the API and https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rrasm/dcad4e29-723b-4832-84d8-5bfac7895b2e provides some useful tips on the parameter values).

Gary


Wednesday, May 8, 2019 11:25 PM

unfortunately I don't have the time nor interest to learn a programming/scripting  language to use those api's. I'll just install OpenVPN server on my win10pro and use that for my server component and either use OpenVPN client or the windows vpn client for L2TP/IPSec. 


Thursday, May 9, 2019 8:26 AM

Hi Gary Nebbett,

Thank you for sharing the solution, I learn more from your reply, and I believe partners who may visit this thread in the future will benefit from your sharing. 

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]


Thursday, May 9, 2019 8:31 AM

Hi rocketjetz,

Thanks for your reply.

I understand that the issue brought some trouble to you. 

Sorry for all these inconvenience.

If there is anything else we can do for you, please feel free to post in the forum.

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]


Thursday, May 9, 2019 9:33 AM

Hello Travis,

A slightly fuller story is even more revealing.

The Windows Filtering Platform (WFP) Base Filtering Engine (BFE) is at the core of IPsec, VPN and many other Windows networking features.

If "Incoming Connections" is configured (and no IPsec rules are defined) then there is normally just one FWPM_IPSEC_IKE_MM_CONTEXT providerContext (named "L2TP Main Mode Policy") in the BFE state; if, and only if, a pre-shared key has been set via MprAdminInterfaceSetCredentialsEx or equivalent then the providerContext will contain a presharedKeyAuthentication element where the pre-shared key can be seen (the BFE state can be viewed with the command "netsh wfp show state").

Defining IPsec rules creates additional FWPM_IPSEC_IKE_MM_CONTEXT providerContexts; if these rules contain pre-shared key authentication proposals then there will be corresponding presharedKeyAuthentication elements in the BFE state.

When an incoming IPsec connection is detected, the server calls the routine IkeFindCorrectMMFilterFromArray. If there is more than FWPM_IPSEC_IKE_MM_CONTEXT providerContext then it might not be possible to identify a uniquely "correct" context and the wrong pre-shared key might be used.

Gary