Netskope Help

This section 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:

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:

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 section 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:

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:

For individual users, NPA supports access to an unlimited number of Private Apps regardless of the application specification in a Private App Definition. Each Private App Definition is referenced by an Application Name (1). In a Private App Definition, the Application Specifications (2) can be either individual IP addresses or IP subnets, hostnames, or wild card domains (*.corp.com).

Private App Definitions are enumerated in a Real-time Policy to enable end-user access to application specifications. Based on policy definitions, for each user, NPA builds a logical association of application specifications and supports up to a maximum of 1000 application specifications. For more than 1000 application specifications per user, you should consider aggregating IP addresses, or hostnames into IP subnets, or wild card domains.