Hey there,
A customer who is using DirectAccess with Windows 8.1 contacted me recently reporting that for his clients a reconnect via DirectAccess takes too long if the internet connection gets interrupted by switching to another connection method
(e.g. from WLAN to WWAN). It seems to happen very sporadically and not on every client.
Has anyone of you experienced that problem, too?
I asked for the troubleshooting assistant logs und took a look at them. It seems as the IPHTTPSInterface recovers very fast from the disruption. I figured that out because the PING-Test to the DA-Server’s IPHTTPSInterface worked as the
log stated. Resolution of the DNS-Names of the target resources we configured the assistant to check also worked, but traffic that requires to be protected by IPSec doesn't work (e.g. the HTTP-Test).
This lead me to the assumption that the IPSec re-negotiation hasn’t taken place at that point of time. Unfortunately I didn’t get the chance to jump onto a client and have a look at the time the problem arises yet.
I am not sure if the idle timeout for existing IPSec-SAs plays a role here. Although DA forces on drop on the SAs once it reconnects usually. Maybe in this case it doesn’t?
I am aware that the minimum idle timeout for an IPSec connection before it gets dropped on Windows is 5 minutes. This setting is configurable with the command “netsh advfirewall set global saidletimemin” but doesn’t allow any value below
5 minutes.
Is there a supported way of lowering that value to e.g. 1 minute?
Another option I have in my mind is to configure the following registry key on the DA-Server to 1, as stated in this KB https://technet.microsoft.com/en-us/library/ee382281(v=ws.10).aspx: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley\NLBSFlags”
As far as I understood this key is used to shorten the time it takes for doing a failover when the DA-Server running Server 2008 R2 is made highly available via Hyper-V. Does anyone of you have experiences with that key regarding DirectAccess
on Server 2012 R2? Does anyone think this may help in our scenario here, too?
I also found another KB for Server 2008 R2 here http://support.microsoft.com/kb/980915/en-us which recommends setting the following registry keys after installing a hotfix:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\nlbsflags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\NlbsIdleTime
Does anyone of you have experiences with those keys regarding DirectAccess on Server 2012 R2? Does anyone think this may help in our scenario here, too?
The last option I have in my mind is deploying a script to clients that uses the Get-NetIPsecMainModeSA and Remove-NetIPsecMainModeSA cmdlets to manually flush the SAs and force a reestablishment. Unfortunately those cmdlets require admin
rights. The only way I know now to get around this permission issue would be to deploy the script via the DA troubleshooting assistant. Does anyone of you know if I could somehow grand end users the ability to run those cmdlets without granting them admin
rights? Network Configuration Operators group membership isn’t enough as I tested out. The script would be kind of a last resort, though
EDIT: While digging deeper into the Logfile of the DA Troubleshooting assistant I noticed lots of dropped packets because of a queue overflow:
<localAddrV6.byteArray16>xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx</localAddrV6.byteArray16>
<remoteAddrV6.byteArray16>fc00:a:58:7777::xxxx:xxxx</remoteAddrV6.byteArray16>
<localPort>58361</localPort>
<remotePort>389</remotePort>
<scopeId>0</scopeId>
<appId/>
<userId/>
<addressFamily>FWP_AF_INET</addressFamily>
<packageSid/>
</header>
<type>FWPM_NET_EVENT_TYPE_IPSEC_KERNEL_DROP</type>
<ipsecDrop>
<failureStatus>0xC000A010 (STATUS_IPSEC_QUEUE_OVERFLOW)</failureStatus>
<direction>FWP_DIRECTION_OUTBOUND</direction>
<spi>3779956078</spi>
<filterId>9223372036854775838</filterId>
<layerId>0</layerId>
</ipsecDrop>
Best regards and thanks,
Steven