Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

A Little Netmon Goes a Long Way

Posted by William Diaz on August 13, 2013

You don’t necessarily need to be a network guru to use Microsoft Network Monitor. I have used it more than a few times to troubleshoot client side applications that fail to connect to external resources for whatever reason. For example, a user unable to logon to a some external server, receiving the follow error: “The remote server returned an error: (502) Bade Gateway

7-25-2013 6-16-51 PM

I tried the site myself with Netmon capturing a trace and saw the remote server was trying to establish a secure connection through a port other than common 443:


And here where printing from a remote app was failing to pass through our TMG proxy:


Another example was the following error when any user would try to launch a remote desktop application to an external resource: “The remote computer could not be authenticated due to problems with its security certificate. It may be unsafe to proceed… You cannot proceed because authentication is required.”


A netmon captured revealed that the process handling the Crypto API was trying to connect directly to certificate servers in the cloud instead of using the proxy our user’s were situated behind:


Some research revealed we needed to configure winhttp to use a proxy*. Afterwards, the certificate check was able to successfully validate through out proxies:


In another case, while troubleshooting an issue with a vendor website, we were seeing dozens of Schannel event errors: “An SSL 3.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.


The client workstation announces itself to the server (Hello) and the two begin to negotiate a cipher suite. However, the server’s initial response is to use SSL_RSA_WITH_RC4_128_MD5.


After some checking, this cipher suite is no longer supported on Windows 7/2008. The errors turns out to be benign as the server falls back on a supported cipher suite:


*To configure winhttp to use a proxy, open an elevated command prompt and type netsh winhttp set proxy proxy-server=”http://some-proxy:8080;https://some-proxy:8080” bypass-list=”* Also consider enabling CAPI2 logging on the client workstation to troubleshoot failed CRL checks.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: