Netskope LogoNetskope Logo
  • Security Services
  • AI Services
  • Networking Services
  • Analytics Services
  • Integrations
  • getting-started.svgGetting Started
    • Support
    • Community
    • Netskope.com
    © 2026 All Rights Reserved. Netskope Inc.
    Home
    Netskope Private Access
    Private Access FAQs

    Private Access FAQs

    Can Netskope Private Access co-exist with other VPN clients?

    Netskope supports the following deployment model for Netskope Private Access in the presence of another VPN client on the user’s device.

    The Netskope Private Access tunnel in the Netskope Client can actively forward traffic, provided the VPN client is disabled, and the VPN tunnel is not actively intercepting and/or forwarding traffic to Private Apps (including DNS).

    Is there any order that the Client uses to match hosts defined in Private Applications? If you have subnets, subdomains, wildcards and hosts, what is the order that the Client will try to use to match the traffic?

    The vertical order of matching the rules is:

    1. Host or IP (without any wildcard)
    2. Subnet (CIDR)
    3. Subdomain

    The horizontal order is not guaranteed except for subdomains, which matches the longest prefix first.
    A horizontal order example is:

    • App1: 10.10.0.0/23
    • App2: 10.10.0.0/24
    • App3: myserver.mydomain

    Subnet: App1, App2 are in the same level, and thereby horizontal
    Subdomain: App3

    The gateway/client will find App1 and App2 first, and then App3.

    What services and polling interval does a Publisher use to check if a private app/service is available?

    The polling interval is about 1 minute.

    The Publisher will try to connect to a configured port on a Private App to check whether the private app is reachable.

    Important factors to consider:

    • The Publisher works best when you define Private App by hostname (like jira.globex.io) and port (like 8080).
    • When a Private App is specified with a port range, the Publisher will use only the first port from the range to check availability. For example, port range 70-90 will return unreachable, even if you are listening on port 80, because the only port that will be checked is 70 (this is a known limitation).
    • If an app definition specifies ports and/or port ranges, it will check whether any of them are reachable. For example, if you specify 22, 70-90, if it’s able to reach port 22, it will mark the app as reachable.

    The Publisher can’t check reachability for Private Apps that are defined with a wildcard (*.globex.io) or CIDR block (10.0.1.0/24).

    How do I return to the setup menu during a Publisher SSH session?

    From the /home/ubuntu folder, enter sudo ./npa_publisher_wizard.

    How does Netskope  handle the connection of an application when the end user terminates a session?

    Netskope will terminate the end-to-end tunnel between the Publisher and the end application upon session termination in SSH and other TCP-based flows.

    Do Publishers support Active-Active in the event there are multiple Publishers that have access to the same Private App?

    Publishers work in Active-Active mode. Active-Active mode enables higher throughput. Up to 16 publishers are supported in an Active-Active deployment per app. Further details on Publisher Selection can be found here.

    What happens if the Publisher registration token is corrupted during the initial deployment stage? Can I reset it locally at the Publisher?

    If the registration failed (for example, because you missed a digit from the registration code), you can SSH into the Publisher and provide a new registration token.

    If the registration succeeded, but you decided to register the Publisher with another token, this is not officially supported and not advised. You will need to reinstall the Publisher.

    My 2nd (or subsequent) Publisher shows as Connected to an older publisher record in the Netskope UI. Now what?

    This could be a known issue. If you copied your new Publisher from an older (working) Publisher, then you’ve likely hit this issue. For example, creating an AMI image from a known working EC2 instance, and then launching a new instance from that AMI image, is an example of one way to hit this issue.

    Please contact Netskope Support or create a new Publisher rather than copying an AMI or image.

    How much bandwidth can a Publisher handle?

    An individual Publisher can handle approximately 500 Mbps of throughput, and can handle approximately 32,000 concurrent UDP orTCP connections.

    How much downtime should I expect during Publisher upgrades and/or failover to secondary Publisher?

    Single Publisher: 1-3 minutes as the system is upgraded until the Publisher comes up.

    HA Publishers: Less than 5 seconds as the traffic switches to the other Publishers in the app definition.

    Can I re-enroll an existing Publisher?

    No. Re-enrolling a Publisher is not currently supported.

    Can the Publisher utilize autoscaling functionality of Public Cloud platforms?

    Yes. Netskope Publishers can utilize the native autoscaling capabilities of Public Cloud platforms via Netskope REST API or automation tools such as Terraform.

    Can syslog be set up on a Publisher?

    Yes. The basic steps are:

    1. SSH into the Publisher.
    2. Select the menu option Configure syslog.
    3. Provide the syslog server host/IP and port.
    4. The Publisher restarts to apply the settings, and sends these entries to the configured syslog server.

    For Private Application allowlisting, what IP Address is seen at the Private App level from NPA?

    The Private Application Host will see the connection as originating from the IP address of the Publisher that is connecting to it. There is no range, but depending upon the number of Publishers used to connect to the Private Application Host, you will need to allowlist each of those IP addresses.

    What access needs to be allowed for NPA to work correctly?

    ComponentURLPortNotes
    Client
    • gateway.npa.<tenant-domain-suffix>

      Example:

      gateway.npa.goskope.com, gateway.npa.eu.goskope.com, ..)
    • addon-<customer-tenant-url>

      Example:

      addon-acme123.goskope.com
    • nsauth-<customer-tenant-url>

      Example:

      nsauth-acme123.goskope.com
    TCP 443 (HTTPS)
    • Requires outbound access only.
    • The addon URL is typically required for retrieving feature flags and IDP enrollment.
    • The nsauth URL is required for the Periodic Re-authentication feature.
    Publisher
    • stitcher.npa.<tenant-domain-suffix>
      Example: 
      stitcher.npa.goskope.com
    • addon-<customer-tenant-URL>
      Example:
      addon-acme123.goskope.com
    • dns.google
    • *.docker.com
    • *.docker.io
    • *.ubuntu.com

      Note

      If your Publisher is running in China, you need to add the following two domains into the allowlist.

      • ns-1-registry.cn-shenzhen.cr.aliyuncs.com
      • npa-ova.oss-cn-shenzhen.aliyuncs.com
    TCP 443 (HTTPS)
    UDP 53 (DNS)
    TCP 80 (HTTP) for *.ubuntu.com
    • Requires outbound access only.
    • The addon URL is typically required for retrieving feature flags.
    • Note

      For administration, please allow TCP 22 (SSH) from admin subnets to the Publisher.

    • For Publisher updates, allow outbound access to:
      • *.docker.com
      • *.docker.io
      • docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com

        for TCP 443 outbound.

      • *.ubuntu.com

        for TCP 80 and TCP 443 outbound.

    Client and Publisher

    ns-<tenant-ID>.<MP-name>.npa.<tenant-domain-suffix>

    Contact your Netskope SE, TSM, or Support for your tenantid and mp-name and if IP subnets are needed instead of FQDNs.

    TCP 443 (HTTPS)Requires outbound access during enrollment/re-enrollment of NPA for the Client and for registration of the Publisher.

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

    MP-Name Variables:

    • us-sv5 (SV5)
    • us-sjc1 (SJC1)
    • us-sjc2 (SJC2)
    • de-fr4 (FR4)
    • nl-am2 (AM2)
    • au-mel2 (MEL2)
    • ch-zur2 (ZUR2)
    • uk-lon3 (LON3)
    • sg-sin2 (SIN2)
    • de-fra2 (FRA2)
    • us-dfw3 (DFW3)
    • sa-ruh1 (RUH1)

    Note

    Requires allowing inbound access only if using a CRL server that is maintained internally within your infrastructure for Prelogon enrollment, or enabling Browser Access. This is not needed for the dataplane traffic.

    For allowlisting ns-<tenant-ID>.<MP-name>.npa.<tenant-domain-suffix> based on IP addresses, refer to the Netskope Private Access List for Allowlisting section here.

    Client and Publisher
    • gateway.gslb.goskope.com
    • gateway.npa.<tenant-domain-suffix>
    TCP 443 (HTTPS)

    Netskope is transitioning away from the old EDNS and LDNS mechanisms over DNS and DNS-over-HTTPS.

    For most customers, the DNS rules will be used as a fallback mechanism, and this is the preferred method, meaning the primary mechanism is through an API connection over HTTPS to our GSLB gateway.

    Consult with your technical contacts at Netskope to validate which rules are exactly needed.

    Client and Publisherdns.googleTCP + UDP 53 (DNS) TCP 443 (DNS-over HTTPS / DoH)
    • For identifying the closest Netskope Data Center, the Client leverages EDNS as the secondary method, so TCP 443 using DNS over HTTPS to dns.google needs to be allowed. (Corresponding IPs are 8.8.8.8, 8.8.4.4).
    • The fallback to EDNS is Local DNS (LDNS), so DNS (UDP 53) will need to be allowed to the DNS resolver.
    • Netskope is transitioning to our new GSLB API for identifying datacenters. Consult with your technical contacts at Netskope to validate which rules are exactly needed.

    I’m not certain what TCP/UDP ports my application needs in order for it to work. What can I do?

    To connect users with applications/services, an NPA administrator must configure Private App policies within the Netskope UI in a few places. Here are the configuration options and details for known application/service types.

    ApplicationProtocol/PortFactors
    Web TrafficTCP: 80, 443
    (custom ports: 8080, etc.) UDP: 80, 443
    Google Chrome will use the QUIC protocol (HTTP/S over UDP) for some web applications, so duplicating the web browsing ports for both TCP and UDP can provide a performance improvement
    Secure Shell (SSH)TCP: 22 
    Remote Desktop (RDP)TCP: 3389
    UDP: 3389
    Some Windows RDP client apps (in particular, newer Windows 10 versions) will now prefer to use UDP:3389 to perform Remote Desktop connectivity
    Windows SQL ServerTCP: 1433, 1434
    UDP: 1434
    The default port for Windows SQL Server is 1433, though this can be customized in your environments. Refer to the Microsoft documentation for more details: Configure the Windows Firewall to Allow SQL Server Access.
    MySQLTCP: 3300- 3306, 33060 TCP: 33062 (for admin specific connections)For general MySQL connection use cases, only port 3306 is required, but some customers may take advantage of the additional MySQL feature ports. Netskope recommends using a port range for MySQL database private apps. MySQL will block connections from the NPA Publisher because it detects the reachability test as a potential attack. Using a range in the port configuration will result in the NPA Publisher performing a reachability check only on the first port in the range and therefore prevent MySQL from seeing this traffic and avoiding the port block.

    For further specifics, please reach out to your Netskope Technical Success Manager or Sales Engineer for assistance.

    Can NPA tunnel protocols and ports outside the common ones listed above?

    Yes. NPA can tunnel apps outside of that list. NPA supports both the TCP and UDP protocols and all associated ports, with one notable exception: Netskope does not currently tunnel most DNS traffic, but we do support tunneling DNS SRV lookups over port 53. This is needed for service discovery, which is used in various Windows AD scenarios involving LDAP, Kerberos, etc.

    Note

    Sometimes applications like VoIP can be problematic. Not so much due to tunneling, but rather configuration. For example, applications that perform dynamic port allocation when establishing a connection can be problematic, because an admin cannot know which ports will be set up by the service end of the application in advance, so there’s no way to know what ports to specify.

    What protocols and ports can NPA tunnel for Private Applications?

    NPA can support any client to server TCP and UDP traffic.

    Can NPA tunnel ICMP?

    No. NPA does not tunnel ICMP, only TCP and UDP. So you cannot ping or traceroute over NPA to test network connections. To quickly check whether NPA steering is working for a private application defined by FQDN,from a command prompt/Terminal window, enter: nslookup<FQDN_of_Private_App>. You can utilize tcping, psping, or other tcp based tools to test connectivity.

    Does NPA support tunneling connections established from a private app to a Client?

    No. NPA does not support protocols that establish connections from a private app to a Client. For example, FTP Active mode is not supported.

    What is SRP and how does NPA leverage SRP to steer traffic?

    The SRP is a document describing a list of apps available to a user. When an NPA tunnel is established for a given user, the NPA management plane performs the calculation of the Service Routing Protocol (SRP). Also, SRP may be revised dynamically based on changes made to the NPA policy, steering, application, device posture or group membership changes.

    Based on the SRP, NPA filters and tunnels private application traffic to the NPA dataplane, and if allowed, then forwards it through the NPA infrastructure to the private app. If not allowed, the NPA dataplane blocks the traffic.

    Important

    Starting in Release v118, the Netskope Private Access backend will drop traffic if the resulting SRP is greater than 40MB.

    This is a protection mechanism to shield misconfigurations from one tenant from harming the overall solution.

    Any large Private App policies, such as enumeration of large number of ports one-by-one, must be disabled to reduce the size and unblock access to those users.

    If these configurations cannot be optimized, please reach out to Netskope Support for additional assistance.

    How long does it take for a client to receive new policy changes (like having a new Private App assigned to them, and have the changes propagate to the Client)?

    Currently each client checks in with the management plane every 15 mins to see if any policy changes need to be downloads and SRP needs to be recalculated. As such, it should take no longer than 15 minutes for new policy changes to propagate to all clients. In reality, it can be from a few seconds to 15 minutes based on the position of timer on the particular client.

    Optionally, you can verify the most recent NPA Policy update by looking at the bottom of the npadebuglog.log for the string SRP live status is 1, and verifying the last timestamp for the log entry. You may see dozens of log entries; just make sure you look for the newest one.

    How does the the Netskope Client check for configuration updates?

    The Client auto-checks for updates as set by the administrator or end-user.

    Does the Client send state changes for updated authentication?

    Yes. The Client provides both periodic and dynamic updates, such as device classification, authentication status, and user to the controller for authorization information.

    What is a good method for troubleshooting accessibility issues to a private app/service behind a Publisher?

    The first best option is to use the Troubleshooter. Click Troubleshooter on the Private App Segments tab in the App Definition page.
     
    Select a Private App Segment and choose an access method.
    • For Client, select a user, and click Troubleshoot.
    • For Browser Access, enter a custom hostname and select a user, and click TroubleShoot.

    The Troubleshooter renders the list of executed checks, problems which may affect your configuration, and solutions for these problems.

    The Troubleshooter has about a dozen of checks now. However, there are multiple additional conditions which could affect access (which Troubleshooter doesn’t check). As a result, it is useful to be able to run some of the checks manually.

    In this Topic
    • Private Access FAQs