Skip to main content

Netskope Help

Private Access Best Practices

Consider these best practices when using Netskope Private Access.

This document provides recommended best practices for managing Netskope Private Access (NPA) Publisher recovery and migration efforts.

The Publisher, as deployed, does not contain any sensitive or persistent info that needs to be maintained and preserved separately outside of the management plane. In order to be connected to the Netskope tenant, a Publisher needs to be registered with a unique registration code.

Sometimes you may be faced with the situation where you need to rebuild or recover the Publisher. Some of those situations include:

  • Losing/misplacing Publisher user password or certificate.

  • Having hosting hypervisor or storage device experience hardware failure or disk corruption.

  • Desire to migrate a Publisher to a newer version of the operating system.

Due to the nature of Publishers architecture and configuration, it is not worth trying to recover any existing Publisher images, but rather deploy a new Publisher image and register it under the same Publisher definition. We recommend that if you ever experience failure or loss of access to the Publisher, do the following:

  1. Build/deploy a brand new Publisher installation/image in the same location as the failed/degraded Publisher.

  2. Ensure that the failed/degraded Publisher is shut down, and verify this by looking at the Publisher in the Netskope tenant to confirm it shows as Disconnected in the Netskope UI:

    image1.png
  3. Click on the menu icon MenuIcon.png to the right of the publisher and click Edit.

    image2.png
  4. Click Save and Continue

  5. Click Generate Token. If the button is grayed out, the Publisher is still connected to the tenant and you need to ensure it is in the Disconnected state before proceeding.

  6. Copy the token and use it to register the new publisher that you have built.

After performing the steps above, your new publisher will automatically take on the role and definition of the old one and will begin serving applications that the old publisher was assigned to.

This document describes the best practices for managing Netskope Private Access (NPA) policies and configurations in order to minimize any potential disruption to the end-users.

How does the Client work with Netskope Private Access?

When the Netskope Client establishes connection to the NPA Gateway, NPA management plane performs the calculation of the Service Routing Policy (SRP). SRP consists of all the entitlements and associated interdependencies of the user’s connection: Private Access policies assigned to the user and Publishers serving those applications.

Any time a Private Access policy is updated to affect a user's entitlements, like adding, changing, or removing an application, this will cause the SRP to be recalculated. The Netskope Client checks in every 15 minutes with the gateway for SRP updates. If a change is detected, the Client will tear down the existing NPA tunnel and establish a new one to follow the new SRP.

The SRP change will be invoked any time user entitlements are affected, even without directly making changes to the Private Access policy.

For example, you have all your Private Applications assigned to all users. You then decide to create a new restricted Private Application and assign it to a group of users. When you apply the policy changes, any user who is a member of the group that has the new policy assigned is going to detect and pick up the new SRP and reestablish their NPA connection.

Now, let’s say at a certain period of time you add a user to the group that has this new selected Private Application assigned. Once the user group membership is synced to the Netskope tenant, the user who is affected by the change will have their SRP recalculated and connection re-established no more than 15 minutess from the moment the change was applied.

Note

No other users should be impacted by this update.

Another event that will cause SRP recalculation is adding/removing Publisher(s) that serve a Private Application. If a Publisher is added or removed to an application definition, or if a Publisher is rebooted or reconnects with the Private Access Stitcher, for example, this action will cause an SRP recalculation and all users connected to the Private Application served by that Publisher will have their SRP recalculated and Private Access tunnels re-established.

While the above mentioned scenarios are most frequent causes for the SRP recalculation, the are a couple of other changes outside of the policy construct that can cause SRP to be recalculated. One is the change of the User Notification page in the policy that blocks access to a Private Application. Another one is a change in Steering Configuration assigned to the user if it affects which Private Apps are steered for that user (dynamic steering, or enumerating assigning steered Private Applications explicitly in the Steering Configuration).

Considerations for Private Apps Connectivity Interruption

While many Private Apps published are web-based, and therefore are usually resilient to tunnel/connectivity interruptions, some other applications, such as SSH, RDP, FTP, etc., are subject to reconnection attempts if the underlying Private Access tunnel is reestablished. As such, we recommend the following best practices to manage NPA policies and publishers:

  • Have a clear understanding of the types of Private Access applications being served by Netskope.

  • Understand which applications may be more susceptible to interrupted user experience in case a Client reconnection is forced by the new SRP.

  • Perform NPA policy changes during non-business hours to minimize potential access interruption for non-HTTP applications.

This document explains how to properly use the Use Publisher DNS feature in a private app definition. First, let’s revisit how NPA works with this feature turned off.

When you define a host on the private app and assign that app to a user via policy, NPA on the endpoint listens for any DNS name queries and, if any of them match the private app hostname, resolves them to a 191.x.x.x IP address, let's call it a stub IP address. Then, when a process is making a request to that stub IP address, the NPA intercepts it, tunnels it to a Publisher, and the Publisher performs name resolution based on the DNS servers it points to.

When you turn on Use Publisher DNS, the concept of using a stub IP addresses goes away. The actual DNS request for the hostname specified in the request is tunneled over to the Publisher, and the response received is the actual IP address returned by the DNS query to the DNS servers that Publisher points to.

For example, if you are trying to access the private application portal.company.com, and that hostname resolves to 10.10.10.10 by the Publisher's DNS server, the IP address returned to the endpoint process (e.g a brower) is going to be 10.10.10.10 instead of 191.x.x.x. The browser is then making a request to the IP address 10.10.10.10, which is as arbitrary as any IP address can be and NPA needs to know that it should intercept and tunnel traffic destined to that IP address. This is why you need to include either a CIDR block covering the IP address of the private application or the exact IP address of the private application in the private app definition. This tells NPA on the endpoint that it needs to intercept traffic destined to 10.10.10.10 and send it over the NPA tunnel.

This is a very powerful concept, but it requires you to exercise due diligence in identifying the exact private IP space that should be served by a particular application. If you accidentally specify a broader range than should be handled by a single application, then you may inadvertently send traffic to all of the private apps that have the Use Publisher DNS flag switched on to a single publisher or publisher group defined on the application that covers the IP range and not via the Publisher the app hostname is defined on. For a practical example of best practice deployment with Publisher DNS mode, please refer to the NPA guide.

Approaches to Managing and Defining Private Apps

If you are defining applications with the Use Publisher DNS feature, you have a couple of options. One is to ensure that each application definition includes an appropriate CIDR range that corresponds to the hostnames being resolved. If you’re publishing multiple applications, such an approach may become tedious as you’d want to ensure that for each application, the CIDR range specified is unique and non-overlapping with other apps definitions to avoid the steering conflict of where to send that traffic.

Another way to approach this is to define private application definitions by CIDRs that are served through the same [set of] publishers. Let's look at the following scenario:

You are defining three private applications: hosta.company.com, hostb.company.com, and hostc.company.com, all reachable by the same publisher. You know that the CIDR network range of the Publishers serving those three application is 172.16.0.0/16, but you’re not sure of the specific IPs of each app, or those IPs can change in the future.

Configuration Approach

You can define three separate applications with just their respective hostnames/ports with the Use Publisher DNS feature turned on. Then you also create a private application for Location A network, as an example, and define it by CIDR 172.16.0.0/16 with the Use Publisher DNS feature turned off. This will ensure that NPA will intercept any traffic destined to the 172.16.0.0/16 networks and application port[s] that you define and send it over NPA tunnel. The CIDR definition does not need to be a part of the same private app definition that is using the Use Publisher DNS feature. Refer to the table below for visual representation of how the application definitions would look like:

App Name

Host

Port

Use Publisher DNS

App A

hosta.company.com

TCP/443

Yes

App B

hostb.company.com

TCP/443

Yes

App C

hostc.company.com

TCP/443

Yes

Location A

172.16.0.0/16

TCP/443

No

This configuration will allow you to access App A, App B, and App C by hostname, as well as any internal resource defined by the Location A CIDR block. You can also see that Location A application CIDR definition may result in undesired steering actions as it covers a very broad RFC1918 range that may interfere with the local network resources, and steering conflicts or irregularities may occur. Defining a private app by such a CIDR block exposes all of its IP addresses to access by the user whom this app is assigned to, potentially violating the least privilege tenet of the Zero Trust Network Access (ZTNA) concept.

The most secure way of defining private applications with the Use Publisher DNS feature is to provide precise CIDR-based IP definitions for the private apps in their definition. For example, in defining private app A, you should put in hostname hosta.company.com, and, if it resolves internally to 10.10.10.10, you should put 10.10.10.10/32 as the CIDR value in that app definition. Then in defining private app B, you put in hostname hostb.company.com, and, if it resolves internally to 10.10.10.11, you put 10.10.10.11/32 as the CIDR value in that app definition as well. This approach allows you to effectively prevent accidental overexposure to the internal network or creating network IP conflicts. Please refer to the table below for the recommended private app definitions in order to achieve this goal:

App Name

Host

Port

Use Publisher DNS

App A

hosta.company.com 10.10.10.10/32

TCP/443

Yes

App B

hostb.company.com 10.10.10.11/32

TCP/443

Yes

App C

hostc.company.com 10.10.10.12/32

TCP/443

Yes