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:

SNAGHTML567f6d8

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

image

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.”

CertCheckFail

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:

image

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

image

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.

image

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.

image

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:

image


*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=”*.domain.com. Also consider enabling CAPI2 logging on the client workstation to troubleshoot failed CRL checks.

Advertisement

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: