Description

While using McAfee Web Gateway you might have notice this error - "This site can’t be reached". As you can see below this error is generated by your Browser and can have only two possible reasons why this message is displayed.

browser_error.JPG

Root cause

 

Reason 1

Network Issue - Network traffic don't reach Proxy interface and is blocked or routed incorrectly trough your network.

Troubleshooting:

Create Tcpdump on client and Web Gateway site at the same time so you can confirm if as example the initial SYN packet that your client send, reach Web Gateway Interface. On client site you will need additional application like "Wireshark" to create tcpdump. On Web Gateway no additional tools are required. GUI -> Troubleshooting -> Packet Capture (Parameters: -npi any -s0 host x.x.x.x). This will limit captured traffic to defined IP only. Another sign of a network issue is, when creating Rule Engine Trace no entries appears on your screen. This most like happens when no request is received from configured client. More about Web Gateway: Troubleshooting with Rule Engine Tracing.

 

Reason 2

Configuration Issue - It is crucial to enable SSL-Scanner to get Block Page provided to your Client, otherwise the request will be blocked without any visible notification for the client. The reason for this issue is that you have to intercept SSL tunnel in order to be able to present "Block Page" to the client inside of encrypted SSL tunnel. More about SSL scanner in following Article: Best Practices: Giving your SSL Client some Context.

Troubleshooting:

To begin you can create Rule Engine Trace and verify if SSL Scanner has been triggered. The Rule order is crucial and will take big effekt if you will or will not receive expected Block Page. Once this has been verified and you still see same error message create TCPdump for further troubleshooting. Using Wireshark you can follow client TCP Stream communication (Right Click > Follow > TCP Stream). In case Wireshark has not automatically identified communication as SSL Stream "Right Click > Decode As > Select "Current" column as "SSL". Now you can clearly identify the Start of SSL handshake which begins with "Client Hello"

 

tcpdump_clinet_Hello.JPG

In this sample above I've already marked crucial fields you should give attention to. Client Start communication offering SSLv3.0 protocol, ciphers suits it support and "Compression Method".

alert.JPG

Finally MWG (Marked in red) close client communication with an alert. This is a general message which do not provide the root cause in clear text and is related due to OpenSSL library. This basically don't have better message or notification implemented within SSL protocol. As next step you have to compare your Client Ciphers, Protocol and Compression method with your configured "Cipher Suits" string in your MWG configuration.

 

SSL_settings.JPG

 

This screenshot has been created from Policy Viewer and is a real world sample. It might not look exactly like you're familiar with from MWG user interface. Anyway you can already confirm SSLv3 (in red) has been selected and could be excluded from potential root cause of the issue. Second possible issue is the accepted cipher suites. To understand what this streang exactly mean please refer to external sources like: Manual:Ciphers(1) - OpenSSLWiki

 

Final solution here was to adjust "Cipher Suits" on MWG to customer needs and MWG start to accept connections from this Client. In case you have some old clients that you have to support it is suggested to create additional setting in "SSL Client Context with CA" and only apply those to specific clients based on IP or any other unique identifier in your network in order to reduce security risk for your company.