Netskope Help

General Troubleshooting Methods

General troubleshooting involves checking:

Netskope Client
Is the Netskope Client connected to NPA?

  1. Right-click on the Netskope Client icon in the system tray and select Configuration. Private Access should show as Connected.

    ClientStatus.png

  2. If the Configuration shows Private Access as Disabled, make sure the Steer all Private Apps option is enabled in the Steering Configuration settings for your tenant. Go to Settings > Security Cloud Platform > Steering Configuration.

    If you have multiple Steering Configurations, click on the name of the Steering Configuration you are using for NPA to open the details page.

    NPAsteeringConfig.png

    Tip

    If using only the Default tenant configuration, click Edit in the upper right corner.

  3. The details page for each steering configuration has a link that names what's being steered to NPA.

    image2.png

    Click the text to edit the configuration, and then enable Steer all Private Apps.

    image3.png
Has the Netskope Client never connected to NPA?

If the Client never enables, it could be that the Netskope Client is trying to register/enroll to the closest Netskope POP to enable NPA before the device’s network connection is active. Currently, the Netskope Client does not check again for network status.

Workaround: If you are displaying the Netskope Client icon in the system task bar (Windows) or menu bar (Mac), disable and enable the Netskope client to ensure it's connected.

Do you employ SSL/TLS inspection on your network?

If Yes, factor that NPA uses its own domain names for connecting to the Netskope Gateway and Stitcher. You will need to bypass the following URLs in order for the Client to connect successfully:

Component

URL

Port

Notes

Client

gateway.npa.goskope.com

Prior to February 2020: gateway.newedge.io

TCP 443 (HTTPS)

Publisher

stitcher.npa.goskope.com

Prior to February 2020: stitcher.newedge.io

TCP 443 (HTTPS)

UDP 53 (DNS)

DNS is not required to be allowed outbound if there is a local network DNS server internally.

Client and Publisher

ns<tenantid>.<mp-name>.npa.goskope.com

Prior to February 2020: ns-<tenantid>.newedge.io

Contact your Netskope SE, TSM, or Support for your tenantid and mp-name.

TCP 443 (HTTPS)

This is needed one time only during the registration.

Example URL: ns-1234.us-sv5.npa.goskope.com

MP-Name Variables:

  • us-sv5 (SV5)

  • us-sjc1 (SJC1)

  • de-fr4 (FR4)

  • nl-am2 (AM2)

Did the Real-time Policy you just applied go into effect?

Open the npadebuglog.log file in a text editor. Search for the name of your Private App as defined in the Private App in the Netskope tenant.

For windows: C:\Users\Public\netSkope\npadebuglog.log

For MacOS: /Library/Logs/Netskope/npadebuglog.log

If you can’t find any mention of your Private App name in this file, then you will not be able to connect to the Private App. This may be a result of the user not being authorized for this Private App (check the Real-time Protection policy).

How do I know the User/OU is authorized for Private Access?

Open up the nsdebuglog.log file and search for the word enroll. You may see more details on why the enrollment process is not working for the user.

Real-time Protection Policy
Is there a Real-time Protection Policy for the user to access the Private Application?

In the Netskope UI, go to Policies > Real-time Protection and verify that the User/OU authorizes the user for the private application.

Netskope Publisher and Private App Connection
Does the Publisher health check in the Netskope UI show that it is able to connect to the application?

If the Private App is defined with a list of TCP/UDP ports, then only the first port is checked for connectivity. The status is not dependent upon all defined ports being accessible. This may lead to a false sense that the Publisher can successfully connect to all defined ports successfully.

image4.png
Can the Publisher reach the defined Private Application from a routing/policy perspective?

  1. SSH to the Publisher (username is centos)

  2. Choose Option #3 to exit out of menu.

  3. Enter su. This will enter you into root.

  4. Enter yum install traceroute -y.

  5. Try to traceroute to the local IP address/domain name of the private application.

Can the Publisher reach the defined Private Application on ALL defined ports?

  1. SSH to Publisher.

  2. Enter su. This will enter you into root.

  3. Enter yum install telnet -y.

  4. Try to telnet to the local IP address/domain name of the private application: telnet <hostname> <port>.

If it connects, everything is good. If it doesn’t then there is a network or host security policy that is blocking the publisher from communicating to the server for the defined port.

Private Application
Does the Private Application have a security group/ACL that is blocking the IP address of the Publisher from accessing it?

This happens when the Publisher is deployed inside of an IaaS environment like AWS. Check the Security Group of the host. All traffic to the defined private application will be seen on the local network as having originated from the Client IP address.

In this section: