Windows 10 Always On VPN clients regularly drop VPN connection with error 829

Question

Windows 10 Always On VPN clients regularly drop VPN connection with error 829

John Perkins 1

Since the November 2020 patch updates, we have a number of Windows 10 1909 (64-bit) laptop clients that periodically drop their Always On VPN device tunnels. The Windows 10 clients report a RasClient error 829 in most situations, although we sometimes see error 828.

There is no sign of the wireless connections failing when this occurs.

The Remote Access server runs Server 2016. Tunnels are certificate-based IPsec VPN links.

There was a known issue with Windows 10 2004 clients that should have been resolved with the September 2020 monthly update. Given that we're a few months after that patch update and on a different Windows 10 build, it seems unlikely to be the same cause.

Any suggestions for what might be causing this or how to clear up the issue?

Anonymous

2020-12-10T03:10:19.023+00:00

Hi,

Just checking in to see if the information provided was helpful.

If yes, you may accept useful reply as answer, if not, welcome to feedback.

Best Regards,
Sunny
John Perkins 1 Reputation point

2020-12-10T03:19:28.06+00:00

The explanation makes sense, but it doesn't apply to our situation.

I wanted to wait until I could apply the latest round of BIOS and device driver updates to one of our affected computers, but that did not clear things up. The connection out is via wifi...so there is no "modem" attached to the computer to drop the signal. There has been no sign that the wifi is dropping or that there is a network outage with the user's internet provider, either.

There is no sign on the RAS server of the connection dropping, either. We have multiple clients connected to the RAS server, and most of them continue to stay online when we see a client drop its connection. I have found nothing logged in the event log on the RAS server to indicate the VPN link dropped at all.
Arturas Radzys 1 Reputation point

2020-12-10T20:12:55.93+00:00

We have the same issue in POC environment

10 answers

Your answer

Anonymous

2020-12-10T03:10:19.023+00:00

Hi,

Just checking in to see if the information provided was helpful.

If yes, you may accept useful reply as answer, if not, welcome to feedback.

Best Regards,
Sunny
John Perkins 1 Reputation point

2020-12-10T03:19:28.06+00:00

The explanation makes sense, but it doesn't apply to our situation.

I wanted to wait until I could apply the latest round of BIOS and device driver updates to one of our affected computers, but that did not clear things up. The connection out is via wifi...so there is no "modem" attached to the computer to drop the signal. There has been no sign that the wifi is dropping or that there is a network outage with the user's internet provider, either.

There is no sign on the RAS server of the connection dropping, either. We have multiple clients connected to the RAS server, and most of them continue to stay online when we see a client drop its connection. I have found nothing logged in the event log on the RAS server to indicate the VPN link dropped at all.
Arturas Radzys 1 Reputation point

2020-12-10T20:12:55.93+00:00

We have the same issue in POC environment

Answer 1

Hello Marco,

Did you issue the command logman stop VPN-Tracing -ets to stop the trace and flush the buffers?

The 3 providers that you are using are not very verbose in their output.

I tried the same commands as you and, after establishing and tearing down a VPN connection, "logman query -ets" also reported "Buffers Written: 1", but when I stopped the trace and examined its header, it displayed "BuffersWritten = 8".

I am happy to help troubleshoot your issue if you get stuck.

BTW: I speak German (I live near Basel).

Gary

Answer 2

Hello Marco,

The IT landscape is changing at the moment, with increasing use of QUIC to transport HTTP (and other) traffic, but for a long time Microsoft-Windows-WinINet traced most browser HTTP traffic and the combination Microsoft-Windows-WinHttp and Microsoft-Windows-WebIO traced most use of HTTP by services (including the SSTP service since the SSTP protocol uses HTTP).

sc queryex SstpSvc

SERVICE_NAME: SstpSvc
TYPE : 30 WIN32
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 4384
FLAGS :

logman query providers -pid 4384

Provider GUID

FWPUCLNT Trace Provider {5A1600D2-68E5-4DE7-BCF4-1C2D215FE0FE}
Microsoft-Windows-AppModel-Runtime {F1EF270A-0D32-4352-BA52-DBAB41E1D859}
Microsoft-Windows-ASN1 {D92EF8AC-99DD-4AB8-B91D-C6EBA85F3755}
Microsoft-Windows-AsynchronousCausality {19A4C69A-28EB-4D4B-8D94-5F19055A1B5C}
Microsoft-Windows-CAPI2 {5BBCA4A8-B209-48DC-A8C7-B23D3E5216FB}
Microsoft-Windows-COM-Perf {B8D6861B-D20F-4EEC-BBAE-87E0DD80602B}
Microsoft-Windows-COM-RundownInstrumentation {2957313D-FCAA-5D4A-2F69-32CE5F0AC44E}
Microsoft-Windows-Crypto-BCrypt {C7E089AC-BA2A-11E0-9AF7-68384824019B}
Microsoft-Windows-Crypto-NCrypt {E8ED09DC-100C-45E2-9FC8-B53399EC1F70}
Microsoft-Windows-Crypto-RSAEnh {152FDB2B-6E9D-4B60-B317-815D5F174C4A}
Microsoft-Windows-DNS-Client {1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}
Microsoft-Windows-DNS-Client-DiagTrack {80E30BFE-62CF-5C77-5DC4-425D2C7734A3}
Microsoft-Windows-Eventlog {FC65DDD8-D6EF-4962-83D5-6E5CFE9CE148}
Microsoft-Windows-Heap-Snapshot {901D2AFA-4FF6-46D7-8D0E-53645E1A47F5}
Microsoft-Windows-Ndu {DF271536-4298-45E1-B0F2-E88F78619C5D}
Microsoft-Windows-Networking-Correlation {83ED54F0-4D48-4E45-B16E-726FFD1FA4AF}
Microsoft-Windows-RPC {6AD52B32-D609-4BE9-AE07-CE8DAE937E39}
Microsoft-Windows-RPC-Events {F4AED7C7-A898-4627-B053-44A7CAA12FCD}
Microsoft-Windows-RRAS {24989972-0967-4E21-A926-93854033638E}
Microsoft-Windows-Schannel-Events {91CC1150-71AA-47E2-AE18-C96E61736B6F}
Microsoft-Windows-Services-Svchost {06184C97-5201-480E-92AF-3A3626C5B140}
Microsoft-Windows-User-Diagnostic {305FC87B-002A-5E26-D297-60223012CA9C}
Microsoft-Windows-VerifyHardwareSecurity {F3F53C76-B06D-4F15-B412-61164A0D2B73}
Microsoft-Windows-WebIO {50B3E73C-9370-461D-BB9F-26F32D68887D}
Microsoft-Windows-WinRT-Error {A86F8471-C31D-4FBC-A035-665D06047B03}
Microsoft-Windows-Winsock-NameResolution {55404E71-4DB9-4DEB-A5F5-8F86E46DDE56}
Microsoft-Windows-Winsock-Sockets {BDE46AEA-2357-51FE-7367-D5296F530BD1}
Microsoft-Windows-Winsock-WS2HELP {D5C25F9A-4D47-493E-9184-40DD397A004D}
Security: SChannel {37D2C3CD-C5D4-4587-8531-4696C44244C8}

Gary

Answer 3

Hi,

Thanks for your question.

The error 829 appears when the modem (in the case of dial-up or broadband connections) or tunnel (in the case of VPN connections) is disconnected due to a network failure or a failure in the physical link to the modem.

The following are possible reasons for the failure.

1)A problem in the network between the modem and the RAS server might have caused the basic dial-up or, in the case of a broadband connection, PPPoE connection, or VPN tunnel to fail.

2)Please check connectivity between the modem and the telephone/cable connection jack. If an external modem is being used, check the physical connectivity between the modem and the computer.

3)In the case of VPN connections set up over a wireless network, problems in the wireless network might have caused the connection to fail. Check the status of the wireless connection in Network Connections folder.

Some of the causes of problems in the wireless network are:

The wireless access point might have gone down due to loss of power or for other reasons.
The user's computer might be out of the operating range of the wireless network or the RF signal strength might be weak.
4)The RAS server might have failed or restarted and closed the connection. Check the event logs on the RAS server.

5) Please also check the event viewer both on the VPN server and the problematic client if there’s any error event so that we can find more clue about this issue.

For more details, please refer to the following article.

Event ID 20226 — RAS Connection Termination

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 4

Hello @John Perkins ,

One approach would be to try to understand the cause of the problem. To demonstrate the idea, I caused a VPN interruption by switching to a different WiFi network with no access to the VPN server. As expected, this resulted in the following entry in the Application event log:

CoId={DAB05C6F-CE12-0002-B4FD-B1DA12CED601}: The user GARY\Gary dialed a connection named Test-Direct which has terminated. The reason code returned on termination is 828.

During this test, I used Event Tracing for Windows (ETW) to trace some relevant providers. The first image shows what happens before and during the interruption:

The IKEv2 Security Association keep-alives can be seen, as can the first error code (18446744072638103583, STATUS_NDIS_MEDIA_DISCONNECTED).

13 seconds later, the VPN is completely torn down:

The ETW providers that I used for this trace are:

Microsoft-Windows-RRAS
Microsoft-Windows-WFP
Microsoft-Windows-Ras-AgileVpn
Microsoft-Windows-Kernel-Process 0x10
"IKEEXT Trace Provider" 0x10 4

Not included in this trace (because of the large volumes of data that it generates), but useful in tricky cases is Microsoft-Windows-TCPIP. With enough experience, it is usually possible to obtain a fairly complete understanding of the behaviour from this trace data and to judge what can be done to influence it.

Gary

Answer 5

Marco Hald 1

Hi @Gary Nebbett ,

i have a similar Problem with disconnecting VPN Session and tried to configure an Autologger to get a Logfile after a reboot.
I tried this code below, but my Problem is that it does not generate a Logfile.
Can you Point me in a direction what's wrong with the code ?

   #New-EtwTraceSession -Name VPN -LogFileMode 0x8100 -FlushTimer 1 -LocalFilePath "C:\VPN.etl"  
   $AutoLoggerName = 'VPN'  
   $AutoLoggerGuid = "{ca24376d-a261-480b-91ba-46576ea3f483}"  
   Remove-AutologgerConfig  -Name $AutoLoggerName  
     
   New-AutologgerConfig -Name $AutoLoggerName -Guid $AutoLoggerGuid -LogFileMode 0x8100 -FlushTimer 1 -LocalFilePath "C:\VPN-Autologger-%d.etl" -Start Enabled  
     
   $rasAgileVpnGUID = Get-NetEventProvider -ShowInstalled | where Name -eq "Microsoft-Windows-Ras-AgileVpn"  
   $VpnClientGUID = Get-NetEventProvider -ShowInstalled | where Name -eq "Microsoft-Windows-VPN-Client"  
   $RasSstpGUID = Get-NetEventProvider -ShowInstalled | where Name -eq "Microsoft-Windows-RasSstp"  
     
     
   Add-EtwTraceProvider -AutologgerName $AutoLoggerName -Guid $rasAgileVpnGUID.Guid -Level 0xff -MatchAnyKeyword ([UInt64] (0x8000000000000001 -band ([UInt64]::MaxValue))) -Property 0x41  
   Add-EtwTraceProvider -AutologgerName $AutoLoggerName -Guid $VpnClientGUID.Guid -Level 0xff -MatchAnyKeyword ([UInt64] (0x8000000000000001 -band ([UInt64]::MaxValue))) -Property 0x41  
   Add-EtwTraceProvider -AutologgerName $AutoLoggerName -Guid $RasSstpGUID.Guid -Level 0xff -MatchAnyKeyword ([UInt64] (0x8000000000000001 -band ([UInt64]::MaxValue))) -Property 0x41  
     
     
   #Remove-EtwTraceSession -Name VPN

Sorry for the formating, but I can't find any Code Tags here in the editor
In what tool are you viewing the trace Files ?

King Regards
Marco

Gary Nebbett 6,211 Reputation points

2022-02-23T21:17:00.53+00:00

Hello Marco,

Without trying the code (which is tedious since it involves reboots and cleaning-up unwanted auto-loggers), there is nothing which stands out as obviously wrong.

Personally, I would not include EVENT_TRACE_REAL_TIME_MODE as part of the LoggingMode,

The purpose of 0x8000000000000001 -band ([UInt64]::MaxValue) eludes me - surely that always delivers 0x8000000000000001?

For testing purposes, I might try omitting the LocalFilePath parameter, instead depending on the default behaviour of naming the file %SystemRoot%\System32\LogFiles\WMI\<sessionname>.etl.

I mostly use self-developed tools to analyse ETW trace files; occasionally I use Microsoft Message Analyzer (now defunct) when the trace data includes network protocols.

Gary

Marco Hald 1

Hi Gary,

thank you for the hint with the reboot. This was simply missing.
I thought the -Start Enabled is enough and i don't need to reboot .
The File is now created but is empty.

So I tried to step back and try to log via the logman uttility.
I used this Commands.

logman create trace VPN-Tracing -ets

logman update VPN-Tracing -p Microsoft-Windows-Ras-AgileVpn -ets
logman update VPN-Tracing -p Microsoft-Windows-VPN-Client -ets
logman update VPN-Tracing -p Microsoft-Windows-RasSstp -ets

And waited till the VPN Session gets aborted.
It seems that this command also don't log anything.
when is run logman query VPN-Tracing -ets this is the Output:

Name:                 VPN-Tracing
Status:               Wird ausgef hrt
Stammpfad:            C:\Windows\system32
Segment:              Aus
Zeitpl„ne:            Ein

Name:                 VPN-Tracing\VPN-Tracing
Typ:                  Ablaufverfolgung
Ausgabespeicherort:   C:\Windows\system32\VPN-Tracing.etl
Anh„ngen:             Aus
Zirkul„r:             Aus
šberschreiben:        Aus
Puffergr”áe:          8
Verloren gegangene Puffer:0
Geschriebene Puffer:  1
Leerungszeitgeber f r Puffer:0
Uhrtyp:               Leistung
Dateimodus:           Datei

Which basically means only 1 written Buffer.

Marco Hald 1 Reputation point

2022-02-24T14:16:33.993+00:00

I found your great Blogpost http://gary-nebbett.blogspot.com/2019/05/diagnosing-vpn-problems-with-windows-10.html when i was searching for Microsoft-Windows-RasSstp
The netsh command seems to be promising, at least it captures something, now I have to wait till the connection dies again.

Can you tell me where you found the Information that "Microsoft-Windows-WebIO" is related to the SSTP VPN ?

Thank you for your help

Marco
Gary Nebbett 6,211 Reputation points

2022-02-24T14:50:32.797+00:00

Hello Marco,

I have posted a response which is awaiting moderation...

Gary

Share via

Windows 10 Always On VPN clients regularly drop VPN connection with error 829

10 answers

Your answer