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
Tuesday, November 7, 2017 11:56 AM
Good Morning All,
We have a VPN infrastructure setup using Windows Server 2012 R2 Routing and Remote Access. It is configured to use IKEv2 with Windows credentials used so users don't have to log in after logging into their laptops.
The server setup for IKEv2 has the defaults (sorry I am not allowed to post images).
Whilst the client setup has mobility enabled for 5 minutes. The problem comes when a client gets disconnected for whatever reason, some users will see the following message:
Can't connect to VPN The context has expired and can no longer be used
This will clear itself after a while but is hugely inconvenient for users. I had a case raised with Microsoft and they told me to reduce mobility settings which made a big difference but this is still common for some users.
Any suggestions would be very much appreciated.
Thanks
All replies (10)
Wednesday, November 8, 2017 8:16 AM
Hi Scott,
Did you mean to reduce settings in Windows Mobility Center?
If so, we can configure the IKEv2 Mobility Network outage time to keep on connection.
More information, please refer to this link:
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Thursday, November 9, 2017 2:39 PM
Hi there,
This is the setting that I have reduced to 5 minutes, on Microsoft's advice to try and stop this from happening.
The problem seems to be that the laptop keeps some sort of security context that it doesn't release if the laptop gets disconnected. I haven't managed to find any information anywhere as to what causes this error and Microsoft support seemed to know nothing about it either.
Friday, November 10, 2017 3:19 AM
Hi,
As I know, Mobility manager primarily targets a roaming user and provides her continuous corporate connectivity when she moves across various networks. It also provides for seamless switching of a VPN connection from one interface to another when the interface, on which the VPN connection is established, goes down, hence providing continuous connectivity to a static user also。
During the Waiting period, if it's as long as 5 mins, context could be released.
For further troubleshooting, please enable RAS log for our research:
netsh ras diagnostics set tracefacilities enabled
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Tuesday, November 14, 2017 1:55 AM
Hi,
Is there any update on your issue? Post back here to let us know if you need further assistance.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Friday, November 17, 2017 7:05 AM
Hi,
I just would like to know if there is any further question on this issue.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, November 22, 2017 12:37 PM
Hi There,
Apologies, I have been away and haven't had any notifications of replies.
I have now set the requested logging. I don't know whether this is going to be a problem with the server or with the client. The error is triggered at the client, and frustratingly can persist for much longer than the mobility settings suggest it should. It can take over 30 minutes for the client to reconnect due to the security context error. The problem we have is that we have hundreds of laptops and this is not happening regularly enough for us to be able to get logs/traces from a client machine with the issue!
It's frustrating that this issue has persisted since we started to use RRAS and yet no one else ever seems to have had this issue.
Thanks
Saturday, November 2, 2019 6:26 PM
Anybody ever got to the bottom of this?
One of my AlwaysON clients suddenly developed this error 1931
I can see on the server client (machine) connecting, then it is gone & the user cannot connects
All the log RasClient shows is that error
Rather difficult to try to troubleshoot it remotely via Teamviewer...
Sunday, November 3, 2019 10:52 AM
Hello Seb,
I have never encountered this problem, so I don't know an answer, but this is what I would do to analyse the problem. I would trace the 4 ETW providers below on both the server and the client when the problem is occurring. The format of the list below is suitable for use with logman.exe, but the same trace can be created with Powershell (Add-NetEventProvider), Microsoft Message Analyzer (MMA), "netsh trace" and other tools.
"IKEEXT Trace Provider" 0xFFFFFFFF 255
Microsoft-Windows-RRAS
Microsoft-Windows-WFP
Microsoft-Windows-Base-Filtering-Engine-Connections
If the list is saved in a file called, say, "providers.lst" then "logman start seb -ets -pf providers.lst -o seb.etl" will start a trace and "logman stop seb -ets" will stop the trace. The remote VPN user should be able to use these commands themselves.
As usual, the first trace results might only be useful enough to suggest what else might need to be traced to get nearer to understanding the issue.
The two providers most likely to be useful are Microsoft-Windows-RRAS (whose events are easy to interpret, with a tool like Microsoft Message Analyzer) and "IKEEXT Trace Provider" (whose events are very difficult to interpret, since this is a WPP provider).
If you need help with the interpretation of the trace data and are prepared to share the data, then I will take a look at it.
Gary
Wednesday, November 6, 2019 7:55 PM
Thanks Gary, it would be great to understand what is actually causing it, but I think it is a router that does not allow proper passthrough of UDP 500/4500
Once the user returned home & used her own connection, all was back to normal
Wednesday, November 6, 2019 8:08 PM
Hello Seb,
It's perhaps an odd thing to say in response to a resolved problem, but it is a bit of a shame that the problem has gone away. I mostly see ERROR_VPN_TIMEOUT (809) status codes when there is a low-level connectivity problem (messages not getting through). The two forum posts have a large number of views (combined total of 4500+), suggesting that ERROR_CONTEXT_EXPIRED (1931) is an often encountered error with unknown cause. It seems that it will stay that way for a little longer...
Gary