Private Access FAQs
Private Access FAQs
What is the Netskope Private Access Gateway?
The Private Access Gateway provides both control and transport functionality. It delivers application authentication and authorization info to the Client, including the SRP (application authorization and routing info) and also serves as the first entry to the Netskope NewEdge infrastructure for Netskope Private Access. It transports all Private Application traffic following authentication.
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).
Does NPA support VoIP or Soft Phones?
VoIP traffic that requires server to client initiated flows is not supported over NPA. However, Netskope’s offering ZTNA Next which combines NPA and SD-WAN capabilities with a single client can support the use case. Please reach out to your account team to learn more about ZTNA Next.
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 (like8080).
- The Publisher works best when you define Private App by hostname (like
-
- 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).
- The Publisher can’t check reachability for private apps that are defined with a wildcard (
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.
How do I SSH into the AWS Publisher?
If deployed in AWS, you will assign the AMI a KeyPair.pem that you already have (or generate a new one) during the provisioning of the Publisher.
ssh -i <Path To Your KeyPair.pem file> ubuntu@<External IP Address of Publisher>
ubuntu is the default username for the Publisher. (Please notice that it’s different from ec2-user, which is the default username for Amazon AWS AMIs).
After successfully connecting via SSH to the Publisher, you will see an interactive CLI menu (below). You can choose option 3 to be placed into a normal UNIX CLI for additional troubleshooting. Go here for troubleshooting tips.
 |
To get back to the interactive CLI menu after exiting, use $ sudo ~/npa_publisher_wizard.
How do I SSH into the VMWare Publisher?
ssh ubuntu@<External IP Address of Publisher>
Default password: ubuntu
You will be required to change the password after first login.
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.
What are the requirements for deploying a Publisher into a VMware environment?
General Host Requirements
-
- 2 CPUs
-
- 4 GB RAM
-
- 16 GB HDD space
Networking Services
Network:
-
- Publishers should have network connectivity to your internal apps.
-
- Publishers should have network connectivity (outbound) to the Internet to reach various Netskope services: configuration, gateways, upgrade, and other service endpoints.
DNS:
-
- Publishers should be able to resolve internal service names, for example:
myapp.example.com.
- Publishers should be able to resolve internal service names, for example:
-
- Publishers should be able to resolve external service names (on the Internet), including the various Netskope services: configuration, gateways, upgrade, and other service endpoints.
SSH:
You should be able to SSH into the Publisher from an internal desktop computer for basic administration tasks, such as passing the registration token to the Publisher during initial setup and troubleshooting any issues which might arise. A publisher cannot be used to connect to itself.
Note
-
- If you deploy the Publisher VM into a network with DHCP services, it should pick up a valid networking configuration automatically, including an IP address, default gateway, and DNS.
-
- If you deploy the publisher VM into a network without DHCP services, you must configure a static IP address, default gateway, and DNS.
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 setup on a Publisher?
Yes. The basic steps are:
- SSH into the Publisher.
- Select the menu option Configure syslog.
- Provide the syslog server host/IP and port.
- 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?
| Component | URL | Port | Notes |
|---|---|---|---|
| Client |
|
TCP 443 (HTTPS)
UDP 53 (DNS) |
|
| Publisher |
|
TCP 443 (HTTPS)
UDP 53 (DNS) TCP 80 (HTTP) for |
|
| Client and Publisher | ns-<tenant-ID>.<MP-name>.npa.<tenant-domain>
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: MP-Name Variables:
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 |
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.
|
Application |
Protocol/Port |
Factors |
|---|---|---|
|
Web Traffic |
TCP: 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 Server |
TCP: 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. |
|
MySQL |
TCP: 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 checkwhether 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.
Does NPA support push operations or server to Client initiated traffic?
No. NPA does not support protocols that establish connections from a private app to a client.
Some Netskope components such as the Publisher, Cloud Exchange, and Log Shipper run on Docker containers. Can we run the other components on the Publisher VM?
No. Running other containers on the Publisher virtual machine is not supported. This includes Netskope and third-party Docker containers.
Does NPA support multi-user (peruser) mode in shared environments such as Citrix XenDesktop, Azure VD, etc.?
When multiple users are logged onto a shared environment system (VDI or RDP), the Netskope Client will steer traffic for users over a single tunnel using the initial identity presented to the Client during authentication. This will typically map to the initial user.
For example, if User A was NPA enrolled and steering private apps, but then logs out, and then User B logs in, User B shall be NPA enrolled and all traffic/steering will be updated to User B’s configuration. At this stage, if User A logs back in, User A will use User B’s traffic/steering configuration for NPA.
Note
On Citrix VD (multi-user concurrent session mode), the active user (the first logged in user) needs to be the domain user; otherwise, NPA enrollment will fail.
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 located on the Private Apps page.
 |
Choose the private app and device you are trying to access, and then click Troubleshoot.
The Troubleshooter renders the list of executed checks, problems which may affect your configuration, and solutions for these problems.
 |
Note
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.
Can Netskope Private Access Support Privileged Access Management (PAM) Use Cases?
Privileged Access Management, commonly known as PAM, includes a multitude of use cases. In the context of providing remote access to private applications, the following PAM use cases are of key significance:
- Secure Remote Access: Enable secure remote access based on the principle of least privilege for third-party users, vendors, and contractors accessing remote servers, including critical infrastructure like IT/OT systems.
- Privileged Accounts Credentials Management: Ensure that user accounts (privileged accounts) utilized for accessing remote servers are effectively controlled and safeguarded. This includes the effective management of credentials associated with these privileged accounts.
- Security Controls: Enforce controls via policy to restrict access and control advanced capabilities such as copy, paste, and print screen, improving security posture.
- Audit and Compliance: Address audit and compliance requirements, ensuring that all access and activities are tracked and compliant with organizational policies.
NPA supports all of the key use cases mentioned above:
- Enable Browser Access (Agentless) for both web and non-web applications, including RDP, SSH, and VNC with the AnyApp feature. Administrators also have the ability to set up a private apps user portal where authenticated privileged users can view the list of Browser Access applications they are authorized to access and launch the applications from the portal.
- With Netskope’s Enterprise Browser, while accessing sensitive/critical remote servers, privileged user access can be further safeguarded by implementing protection policies. These policies can include data protection controls for activities such as copy, paste, and print.
- Session Recording and Management allows for the recording of sessions to meet audit and compliance needs, enabling later review. Administrators can enable session recording via policy and retrieve recorded sessions as needed. This essentially enables the monitoring and auditing of third-party privileged user access to sensitive remote servers.
- Vault integration enables the mapping of credentials for privileged user access to sensitive remote servers without the need to share the actual credentials with the users. Credentials can be injected via the vault, minimizing risks associated with credential sharing and ensuring compliance with standardized password rotation policies.
To inject credentials, it is essential for a Publisher (where AnyApp is running as a container) to integrate with a vault hosted in a customer-owned environment. Once this integration is done, when an end user successfully authenticates using NPA Browser Access, the SAML Identity and the configured credentials policy for the server will dictate the specific credentials or secrets that must be injected for access.
