20H2 L2TP VPN Connection Failure

Question

Installed 20H2 on several workstations; all of them have an existing L2TP connection to a client site. Now that 20H2 is installed all 20H2 patched system are no longer able to connect. The sole system that can connect is 1909. When will this be fixed so that my staff can resume providing the services we offer? It will really suck if I have to reload a bunch of systems from backups to go back to 1909.

Answer 1

Hi,

Thanks for posting in Q&A platform.

May I know whether the windows 10 client is a windows built-in VPN client or a third party VPN client?

What's the error message when connected to VPN? Please help to provide related screenshots for further troubleshooting.

Best Regards,
Sunny

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hello @Tim Andaya ,

Here is a top-level view of the network traffic during the set-up of an L2TP/IPsec VPN:

The first four packets are not encrypted and are probably where your problem is detected (your error message mentions "initial negotiations"); it is possible that the problem occurs later (during either the "Quick Mode" exchanges or the L2TP exchanges (concealed in the ESP encapsulation in the trace image) - we could discuss the possibilities for examining problems at these stages later, if necessary.

My strong suspicion is that the IPsec parameters for the connection on the "old" systems have been modified from the out-of-the-box default (perhaps via the PowerShell cmdlet Set-VpnConnectionIPsecConfiguration or the registry); I am fairly sure that there were no changes in the default configuration between 1909 and 20H2.

By comparing the Main Mode proposal transforms of working and non-working systems, it should be possible to work out what configuration changes are needed to make the 20H2 clients work with the target server.

Gary

Answer 3

BTW - Even hitting "Cancel" after taking the monkey screen shot, the monkey screen hosed up the adapter settings, again.

Answer 4

Hello @Tim Andaya ,

Is it plausible that "custom" IPsec parameters for the connection have been set on the old systems? One way of checking this would be to look for the item CustomIPSecPolicies in the %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk file of a working system. It might be necessary to check the registry at HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters for values like NegotiateDH2048 or NegotiateDH2048_AES256 too.

Other ways of checking would be to use the PowerShell cmdlets Get-NetIPsecMainModeSA and Get-NetIPsecQuickModeSA or the command "netsh adv mon sho con" on a working system while the VPN connection is active, or to ask whoever manages the VPN server what IPsec parameters are accepted and check whether that is compatible with the default settings of the VPN client.

Gary

Answer 5

I checked the phonebooks, everything matches between working and not working; the phonebook is just a sub screen of the legacy adapter settings I sent a screen shot earlier.

No substantive differences other than the rasman.dll version, on the system that works, the version is 10.0.18362.1237 on the system that doesn't work it is 10.0.19041.546

--
I think I have found problem but, I have no way to fix a manufacturer's defect.