When I was asked to write an article on identifying, troubleshooting, and resolving common Netskope Client-related issues, I initially thought, "Sure! How hard can it be?" However, I quickly realized that troubleshooting is a broad and open-ended topic, varying significantly depending on the specific issues encountered.

In this article, we will explore common Netskope Client problems, their root causes, and the best tools and methods to resolve them. These insights align with the key topics we will cover in our live presentation.

Those topics are as follows:

• Understanding Netskope Client Architecture – How the client interacts with cloud security services and network components.
• Common Client Issues and Root Causes – Connectivity failures, latency, and policy misconfigurations.
• Troubleshooting Tools and Logs – Leveraging Netskope Client Debug Logs, Packet Captures, and Browser Developer Tools.
• Best Practices for Resolution – Steps to address common client-side issues and optimize deployment.
• EXCLUSIVE ONLINE DEMO:  Register at ​​Inside Netskope: Identify, Troubleshoot, and Resolve Common Netskope Client-related Issues Online Event

Understanding Netskope Client Architecture

Understanding Netskope Client Architecture is the key to start troubleshooting client issues.  Without that understanding, there are so many different options to look into. I liken this to an unplugged network cable. It does not matter how much you know about networking if the cable is unplugged…traffic won’t go anywhere.

The Netskope Client is responsible for steering real-time traffic to the Netskope tenant for processing. This is just one of several methods for sending Netskope traffic for analysis and enforcement.

The client operates using a secure tunnel (TLS or DTLS) to establish connectivity. Once connected, various policies can be applied, including:

• Traffic Steering Policies: Define which applications and traffic types are routed through Netskope.
• Client Configuration Policies: Control user access, client installation, and security settings.

Since the purpose of this article is to cover the Netskope Client only, let’s see what the client does.

As seen above, the Netskope Client connects to a Netskope dataplane and does so by using a tunnel using TLS or DTLS. Once the client connects, “policies” can be applied at the dataplane level.  In this instance, “policies” can be how or what we steer to the tenant, i.e. CASB, Web, DNS, etc, etc. A “policy” can also be restricting the ability of end users to interact with the client, i.e. disable the client or uninstall it. 

So, we have client “policies” which include client configurations and steering configurations.

• What’s in a client configuration?
  • Tunnel Settings
  • EDLP, NPA, Install & Troubleshoot, and Tamperproof
• What’s in a traffic steering configuration?
  • Dynamic Steering
  • Cloud, Web and Firewall
  • DNS Traffic
  • Private Apps
  • Borderless SD-WAN Apps
  • Exceptions: SSL Cert Pinned, Categories, CFW Apps, Application (Custom)

Common Client Issues and Root Causes

With the different client “policies” in mind, we can start to dig into what we see on endpoints and so on.

Client Configuration Errors

Since the client configuration is the basis on which the client relies on, we’ll tackle this one first.  

• Incorrect client configuration. We’ve seen issues where people are pulling the wrong configurations.
  • This has been due to a syncing issue with our IDP to the tenant for user and group association.  
  • Ordering in the tenant is also another issue we have seen. Since we work from the top down, ordering of the policies is important.
  • Group membership. If an individual belongs to multiple groups or there are changes in group structures that can disorient.
• Fail/Close. If the Netskope Client cannot reach the tenant to establish a tunnel, it bricks the machine. The client configurations that use this setting have a captive portal timeout which allows them to connect and accept a use agreement in a coffee shop.
• Admin passwords. Use password vaults and sync the passwords on a regular basis.  Before we started going this there were a few times where we would have to reset the password on an endpoint before performing admin work. Which is not that big of a deal until the client cannot get connected to the tenant and therefore the new admin password isn’t updated.

Steering Configurations

Working our way up the stack, steering configuration “policies” are other potential areas to dig into. When I first started all we had was the ability to steer Cloud apps only or web, all the above. Things have changed quite a bit since then and it seems to have been in the past two years that this has occurred. 

A feature that I had anticipated for quite some time is the logging of bypassed traffic in the tenant, which should be turned on. You will be able to see this in page events.

Other considerations with steering configurations are:

• Incorrect steering configuration issues are similar to those as incorrect client configurations as mentioned above. Steering configurations and client configurations are independent of each other.
• Bypassing traffic at the client or Netskope. If you rely on ssl cert pinned app exceptions, keep bypassed traffic at the client.
• With private applications, we typically steer all NPA applications. However, there are times where only specific apps need to be steered. Keep this in mind with restrictions and limits, especially with ordering of steering configurations.
• Exceptions. This is a section in which we spend a fair amount of time.  
  • SSL Cert Pinned applications.  We have had to create custom applications when a major software provider like Apple adds a new process for updates after an update or domains to existing  SSL Cert Pinned applications.
    When this happens, new SSL Cert Pinned applications need to be created in order to accommodate application developers' use of applications that cannot use our certificates.
  • Custom applications. There have been a number of applications like Ring Central which require the creation of applications and adding them to the steering configuration to avoid delays in real time traffic or streaming applications.
  • Categories. We tend to exclude some categories from being monitored, i.e. healthcare or financial. However, there are some URLs or cloud applications that are in either of those categories which we want to see. In this instance, we create a custom category with a URL list containing those URLs or domains belonging to the cloud app to be excluded, in effect steered to Netskope.

Custom Applications

The definition of custom applications or lack thereof is relevant when it comes to applications that are set to Discovery Only in our CCI DB.

files.com is a good example of a file that is known by our CCI DB and activities are detected at best by Discovery Only which is best effort activity detection with our Universal Connector and only on a NG-SWG tenant only. In other words, we might be able to see only certain activities on a best effort only, not all the time, and might change.

Activities detected are best effort since the application is discovery only.  Since the application is discovery only, you cannot create a real-time protection policy to restrict access or use DLP for protection. We see this by trying to define a policy but the Cloud app does not exist. Sure PostMyFiles.com does, but not the files.com application.

We can then define a custom cloud application in Security Cloud Platform and App Definition.  After the custom app is created and the client is updated, we can then create a real-time protection policy using the new app and potentially influence behavior with this application.

Netskope Tenant Settings

Netskope Client Enforcement, found in Security Cloud Platform settings. We use this to restrict access to internal applications within our IDP using a sign-on policy. If we do not originate from a Netskope Dedicated Egress IP (DEIP), access is not granted to the application, typically seen as a lock on the application. Problems we have seen that cause locks on the applications are the use of clients from different tenants which are not using our DEIP range, client communication issues, and a typo in bypasses.  

Troubleshooting Tools and Logs

Netskope Client Logs

• nsdebuglog.log & nsdebuglog_old.log: this is the log in which I spend the most time when reviewing Netskope Client logs. In this file I see what is being tunneled, bypassed, and if there are issues connecting to resources needed to establish tunnels to the Netskope tenant.
  
  I can also see why the client is choosing a dataplane for connectivity which is not anticipated, i.e. several states away versus right down the street.
  
  
   
• npadebuglog.log: determine what application is being pushed down to the client, ports, using client dns, and publishers.
  
   
• nsbwanuidebuglog.log: use this to watch how the BWAN application interacts with the OS.
• nsbypass.json: use this to see what bypasses are being sent to the client.
• nsconfig.json: use this to see what the configuration is when pushed down to the client.
• processInfo.log: will sometimes review this to determine if other processes might be affecting Netskope Client communications, i.e. AV or other security softwares.

Notskope.com

We use this to determine what dataplane a user is hitting and what source IP they are originating from at the ISP. We can then check our IDP logs to determine if the IP address is in the range of expected addresses in the sign-on policy access control list.

NPA Troubleshooter

This tool is found in Security Cloud Platform Private App, App Definitions.

We will use this to determine if the app is pushed down to the end user, policies are in place for them to access the application, and if the end user has been seen.

Resources Sent to Support

• Packet Captures (inner/outer). This is found in the advanced debugging, packet capture tab.  These are saved to the Netskope Client logs folder and bundled up when saving Netskope Client logs.
• Netskope Client Logs. Click on the client, choose save logs, and attach to the support ticket in the web UI after creating the ticket.
• Http ARchive (HAR). In Chrome, three dots on top of each other, More Tools, and Developer Tools. This will tell us what the browser is doing when communicating with remote services/apps.

(Helpful Hint: Google changed the location or action to download the HAR file, choose the button with the yellow square around it.)

• Videos and screenshots. Yes, we too have to prove these. As painful as they are at times to compile, they are necessary.
• Date, Timestamps, and Timezones. Since our support team operates all over the globe, this is important to send to them. Even if the logs are taken during the issues, still provide this.

Best Practices for Resolution

In addition to suggestions mentioned above, we like to follow

• Rotate tamperproof restrictive passwords.
• Review SkopeIT and Netskope Advanced Analytics reports to determine where users are going and what they are doing.
• Keep client software updated: ensure Netskope Clients are running the software which is at least a golden image.
• Regularly review configurations: proactively check client and steering configurations for accuracy and alignment with organizational policies as well as updates to SSL Cert pinned applications and bypasses.
• Document changes: maintain a log of configuration changes, updates, and troubleshooting steps to track issues and prevent future problems.  One of the things that we do at Netskope is create Netskope Advanced Analytics reports that show a before and after picture of changes related to access, DLP, or threat policies, to name a few.
• Provide user training: educate end users on how to report issues such as Netskope Client logs, date/timestamps, and screenshot if possible.
• Test configuration changes: before deploying configuration changes to the entire organization, test them on select steering or client configurations of those early adopters….aka Security and Corporate IT.
• Stay informed: keep up-to-date with Netskope's documentation, release notes, and community forums for the latest information and best practices

Understanding, troubleshooting, and resolving Netskope Client issues requires a comprehensive approach. By grasping the client's architecture, recognizing common issues and their root causes, utilizing the available troubleshooting tools and logs, and implementing best practices, we can effectively manage and optimize Netskope Client deployments. Consistent review of reports and proactive password management further enhance security and operational efficiency.