Private Access Best Practices

Private Access Best Practices

Consider these best practices when using Netskope Private Access.

Best Practice for Managing Publisher Recovery and Migrations

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:

  • 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.

Best Practice for Using the Publisher DNS Feature in Netskope Private Access

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 a policy, NPA on the endpoint listens for any DNS name queries and, if any of them matches the Private App hostname, NPA resolves them to a fictitious IP address. In previous versions the IP address range was 191.x.x.x, but in the current versions we use a CGNAT address space of 100.64.0.0/16 (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 a new name resolution based on the DNS servers it points to in order to resolve the internal IP of the published application.

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 captured and tunneled over to the Publisher, and the response received by the Client 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 (like a browser) is going to be 10.10.10.10 instead of the stub IP address (191.x.x.x, or 100.64.0.0/16, depending on the version). 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.

Note

The IP address and CIDR block need to be on separate lines. For example:
hosta.company.com
10.10.10.10/32

A CIDR notation (like /32) is not needed if you specify an exact IP host.

This approach 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 the 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 NameHostPortUse Publisher DNS
App Ahosta.company.comTCP/443Yes
App Bhostb.company.comTCP/443Yes
App Chostc.company.comTCP/443Yes
Location A172.16.0.0/16TCP/443No

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 NameHostPortUse Publisher DNS
App Ahosta.company.com 10.10.10.10/32TCP/443Yes
App Bhostb.company.com 10.10.10.11/32TCP/443Yes
App Chostc.company.com 10.10.10.12/32TCP/443Yes

Considerations for Assigning Private App Definitions in a Real-time Policy

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 6000 application specifications. For more than 6000 application specifications per user, you should consider aggregating IP addresses, or hostnames into IP subnets, or wild card domains.

NPA-App-Definition.png

An administrator needs to ensure that Real Time Policy for any user does not exceed 40 MB. The size of the Real-time policy for any user can be seen in the output of the NPA Troubleshooter tool.

Note

The NPA Troubleshooter tool displays the Application Specifications and size of the Real-time policy for a specific user.

Share this Doc

Private Access Best Practices

Or copy link

In this topic ...