Private Access FAQs
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.
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).
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 apps is defined by hostname (like
jira.globex.io) and port (like8080).When an app is specifies with multiple ports or a port range, the Publisher will use only the first port from the list or 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 multiple ports and/or port ranges, it will check whether any of them is 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). It also does not check reachability of apps with port ranges defined (3305-3306).
From the /home/ubuntu folder, enter sudo ./npa_publisher_wizard.
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.
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.
ssh ubuntu@<External IP Address of Publisher>Default password: ubuntu
You will be required to change the password after first login.
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. A round-robin algorithm is used to spread Netskope Clients across publishers.
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.
General Host Requirements
2 CPUs
4 GB RAM
8 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 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.
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.
An individual Publisher can handle approximately 500 Mbps of throughput, and can handle approximately 32,000 concurrent UDP orTCP connections.
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.
No. Re-enrolling a Publisher is not currently supported.
Yes. Netskope Publishers can utilize the native autoscaling capabilities of Public Cloud platforms via Netskope REST API or automation tools such as Terraform.
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.
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.
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 |
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 |
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. Refer to the MySQL documentation for more details: MySQL Port Reference Tables. |
For further specifics, please reach out to your Netskope Technical Success Manager or Sales Engineer for assistance.
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.
NPA can support any client to server TCP and UDP traffic.
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.
No. NPA does not support protocols that establish connections from a private app to a Client. For example, FTP Active mode is not supported.
The Client auto checks for updates as set by the administrator or end user.
Yes. The Client provides both periodic and dynamic updates, such as device classification, authentication status, and user to the controller for authorization information.
No. NPA does not support protocols that establish connections from a private app to a client.
VoIP requires usage of Session Border Controllers in order to traverse NAT. We’ve discovered that many customers do not have Session Border Controllers deployed as they are not required for enterprise VoIP deployments. However without them, VoIP support with NPA is not possible.
No. Running other containers on the Publisher virtual machine is not supported. This includes Netskope and third-party Docker containers.
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.
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.