Direct Access Clients intermittently lose connectivity to Corp Network with IPHTTPS Connectivity
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
Note: |
If any of the following servers have a name suffix that matches an NRPT entry for the intranet namespace, that server name must be an NRPT exemption:
These servers must always be resolved with the DNS servers specified in the client’s TCP/IP settings. |
After that we added WPAD to NRPT Exemption and after that all IPHTTPS connections were stable.
Author :
Junaid Jan
Support Escalation Engineer - TMG / UAG