I was working on a case  where intermittently DA Clients were losing Corp connectivity

We collected following Data on DA Client and UAG Server

Capturing DirectAccess scenario tracing on Server and Client :

1. Open an administrator-level command prompt on the DirectAccess client and on the UAG server.

2. In both the command prompt windows, type the following command:

netsh trace start scenario=directaccess capture=yes report=yes

3. Reproduce the problem that you are having with DirectAccess.

a. Run ipconfig /flushdns on UAG and client

b. Restart the IP Helper service on the client : net stop iphlpsvc && net start iphlpsvc

c. Ping intranet DC and Application server by name

d. Start run \\DC and \\App-Srv

e. Record the results of above tests

4. In the command prompt windows stop tracing with the command:

netsh trace stop

5. With this procedure, Netsh.exe writes tracing information to the NetTrace.cab files in the %LOCALAPPDATA%\Temp\NetTraces folder.

6. You will have NetTrace.cab files at both UAG Server and at the DA client.

 
After analysing the Client side Trace, we saw this :

  06:10:41.702 ::DHCP WPAD: Detection on Adapter {48E526CC-576E-4F0A-B5B8-15BB9850F951} FAILED with Error: 54f

 06:10:41.702 ::DNS WPAD: Looking up wpad

 06:10:41.702 ::DNS WPAD: Resolve SUCCESSFUL, Autoconfig URL: http://[2002:8dbd:f865:8001::a31:a09]/wpad.dat

 06:10:41.702 ::WinHttpCrackUrl("http://[2002:8dbd:f865:8001::a31:a09]/wpad.dat", 0x0, 0x0, 0x155ef74)

 06:10:41.702 ::WinHttpOpenRequest(0x1d5f338, "", "/wpad.dat", "", "", 0x722be8ac, 0x00000040)

 06:10:41.702 ::    WinHttpCreateUrl(); URL = http://[2002:8dbd:f865:8001::a31:a09]/wpad.dat, URL Length = 46

 0x1DB89B0: WebCreateHttpRequest completed successfully. (Session 0x167D5A8[0xF500000020000021]) (Method GET) (URI        http://[2002:8dbd:f865:8001::a31:a09]/wpad.dat) (Version 0x1.0x1) -> (Request Handle 0xFD0000003000001F)

 0x1DB89B0: Sending Headers: GET /wpad.dat HTTP/1.1

 06:10:49.782 ::DHCP WPAD: Adapter Pass: [#21] Adapter name={7162BB35-0845-4E19-B1A3-93A5A567A323}, 

 06:10:49.798 ::DHCP WPAD: Detection on Adapter {48E526CC-576E-4F0A-B5B8-15BB9850F951} FAILED with Error: 54f

 06:10:49.798 ::DNS WPAD: Looking up wpad

 06:10:52.746 ::DNS WPAD: getaddrinfo FAILED with Error: 2afc

 06:11:01.715 ::DNS WPAD: Looking up wpad

 06:11:01.902 ::DNS WPAD: Resolve SUCCESSFUL, Autoconfig URL: http://[2002:8dbd:f865:8001::a31:a09]/wpad.dat

So as we can see Client was able to get the WPAD successfully and that was breaking the Connection .

And also as per http://technet.microsoft.com/en-us/library/dd857325.aspx

 After that we added WPAD to NRPT Exemption and after that all IPHTTPS connections were stable.

Author :

Junaid Jan
Support Escalation Engineer - TMG / UAG