Netskope Global Technical Success (GTS)

Verifying SSL Decryption and Tunnelling Through Netskope

Netskope Cloud Version - 119

Objective

This article aims to explain how to determine whether the web traffic from a machine is tunnelled through Netskope client and if it is being decrypted.Readers will learn how to verify traffic flow, understand the decryption process, and troubleshoot any issues related to traffic visibility and security in Netskope.

Prerequisite

Netskope CASB Inline/SWG license is required

Context

When using the Netskope client to manage and secure network traffic, there may be scenarios where we need to verify whether traffic is correctly tunnelled through Netskope and if it is being decrypted as intended. Ensuring that traffic is both routed through Netskope and decrypted is essential for applying the appropriate security policies and maintaining visibility into network activity. This document provides a comprehensive guide on how to check if traffic from a machine is being tunnelled through Netskope and verify its decryption status.

Do You Know?

Netskope provides an SSL Inspection dashboard in the Netskope Advanced Analytics library that allows you to monitor the inspection rate of all traffic routed through the service. This dashboard helps you review traffic and destinations that have not been inspected, giving you valuable insights into your traffic management and security processes.

• Check out the SSL Inspection dashboard here to explore your traffic inspection data.
• Want a walkthrough? Watch this video for a detailed overview of how to use the SSL Inspection dashboard effectively.

Procedure

Your initial step should be to check whether the traffic is being tunnelled or bypassed from the client by reviewing the nsdebuglog.log in the Netskope log bundle.

For guidance on collecting Netskope logs, please see: How do I save my Netskope Client logs?

• It is suggested that you close any extra browser tabs and applications that aren’t a priority. This will help reduce the log entries in nsdebuglog.log, enabling you to concentrate on the specific traffic you are investigating.        
• Ensure the client log level is set to "info," as this is the default log level. Any changes to a different log level should only be made upon recommendation from the Netskope support team.

• To showcase the logs, I have set up the following exceptions in the steering configurations:
• Bypass web traffic in the Finance/Accounting category.
• Bypass all web traffic directed to *.netskope.com.
• Bypass traffic from Slack.exe.
• Bypass traffic from Zoom.exe in Tunnel mode.

Use the command below in PowerShell to monitor real-time logs from the Netskope client. Note that if "Protect Client configuration and resources" is enabled in the client tamperproof settings, this command will not work. Instead, refer to nsdebuglog.log after collecting the Netskope client bundle logs.

 Get-Content -Path C:\ProgramData\netskope\stagent\logs\nsdebuglog.log -Wait -Tail 1

For MAC OS : tail -f /Library/Logs/Netskope/nsdebuglog.log

• Category based exception test ( Finance/Accounting ):

With “Category” exceptions the initial request always reaches the Cloud to retrieve the Category since the Endpoint does not keep a database of categories. The Endpoint then caches the corresponding category for that destination and further packets are bypassed at the client level.

Initial request:

After the endpoint has cached the category linked to the destination:

• Domain based exception test (www.netskope.com):

• Process based bypass test ( Slack.exe)

• Process based bypass test with bypass + tunnel mode ( Zoom.exe)

The client tunnels traffic from applications and domains, but here, the Netskope proxy will bypass it. This option is useful for domains associated with an SSO authentication service, since these services use the source IP of the Netskope cloud to determine if access to the cloud app is protected by Netskope. 

Here, you can see a log entry specifically stating, “Bypassing the connection by tunnelling.”

Now, let’s see how the logs look when your traffic doesn’t fall under any steering exceptions and is sent through Netskope.

From the examples given, readers should have gained an understanding of how to investigate the Netskope client logs to see if your traffic is bypassed or tunnelled to Netskope.

Now, we’ll examine the traffic that is tunnelled through Netskope and check if your traffic is decrypted or not.

Note : To maximize the security benefits of Netskope, it's generally recommended to enable SSL decryption where possible, while carefully considering any legal or privacy implications. For applications or services that absolutely cannot be decrypted (e.g., due to certificate pinning), a balanced approach using No SSL Decryption policies may be necessary to maintain some level of visibility and control.

• Validating the SSL decryption by checking the CA certificate within the browser:

You can validate whether a connection has undergone SSL inspection by reviewing the certificate. If you find ca.<tenant-name>.goskope.com, this indicates that your connection was indeed SSL inspected.

If this certificate is absent, it suggests that the connection is not being SSL inspected. In such cases, it is important to check for any steering bypass or SSL decryption bypass that may be preventing this from occurring.

• Validating the SSL decryption from SkopeIT Page Event logs:

If the traffic matches an SSL DND rule and is not decrypted, you can verify this using the search query: “bypass_traffic eq yes and ssl_decrypt_policy eq yes.”

Terms and Conditions

• All documented information undergoes testing and verification to ensure accuracy.

Notes

• This article is authored by Netskope Global Technical Success (GTS).
• For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.