DirectAccess reconnection problems when Internet connection changes

hey there,

a customer using directaccess windows 8.1 contacted me reporting clients reconnect via directaccess takes long if internet connection gets interrupted switching connection method (e.g. wlan wwan).  it seems happen sporadically , not on every client.

has of experienced problem, too?

i asked troubleshooting assistant logs und took @ them. seems iphttpsinterface recovers fast disruption. figured out because ping-test da-server’s iphttpsinterface worked log stated. resolution of dns-names of target resources configured assistant check worked, traffic requires protected ipsec doesn't work (e.g. http-test).

this lead me assumption ipsec re-negotiation hasn’t taken place @ point of time. unfortunately didn’t chance jump onto client , have @ time problem arises yet.

i not sure if idle timeout existing ipsec-sas plays role here. although da forces on drop on sas once reconnects usually. maybe in case doesn’t?

i aware minimum idle timeout ipsec connection before gets dropped on windows 5 minutes. setting configurable command “netsh advfirewall set global saidletimemin” doesn’t allow value below 5 minutes.

is there supported way of lowering value e.g. 1 minute?

another option have in mind configure following registry key on da-server 1, stated in kb https://technet.microsoft.com/en-us/library/ee382281(v=ws.10).aspx:  “hkey_local_machine\system\currentcontrolset\services\policyagent\oakley\nlbsflags”

as far understood key used shorten time takes doing failover when da-server running server 2008 r2 made highly available via hyper-v. of have experiences key regarding directaccess on server 2012 r2? think may in our scenario here, too?

i found kb server 2008 r2 here http://support.microsoft.com/kb/980915/en-us recommends setting following registry keys after installing hotfix:

hkey_local_machine\system\currentcontrolset\services\ikeext\parameters\nlbsflags

hkey_local_machine\system\currentcontrolset\services\ikeext\parameters\nlbsidletime

does of have experiences keys regarding directaccess on server 2012 r2? think may in our scenario here, too?

the last option have in mind deploying script clients uses get-netipsecmainmodesa , remove-netipsecmainmodesa cmdlets manually flush sas , force reestablishment. unfortunately cmdlets require admin rights. way know around permission issue deploy script via da troubleshooting assistant. of know if somehow grand end users ability run cmdlets without granting them admin rights? network configuration operators group membership isn’t enough tested out. script kind of last resort, though

edit: while digging deeper logfile of da troubleshooting assistant noticed lots of dropped packets because of 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 , thanks,

steven

on wed, 4 feb 2015 09:56:41 +0000, stevend_2011 wrote:

a customer using directaccess windows 8.1 contacted me reporting clients reconnect via directaccess takes long if internet connection gets interrupted switching connection method (e.g. wlan wwan).  it seems happen sporadically , not on every client.

directaccess questions better posted here:

https://social.technet.microsoft.com/forums/forefront/en-us/home?forum=forefrontedgeiag

---

paul adare - fim cm mvp
should never anthropomorphize computers; hate that. -- skud

Windows Server  >  Network Infrastructure Servers