What is Netskope Private Access?

Netskope Private Access system requirements differ between deployment environments. For more information, reference: System Requirements for a Netskope Private Access Publisher.

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

Application	Protocol and Port	Factors
Web Traffic	TCP: 80, 443 (custom ports: 8080, so forth) UDP: 80, 443	Google Chrome uses the QUIC protocol (HTTP/S over UDP) for some web applications. Duplicating the web browsing ports for both TCP and UDP can provide a performance improvement.
SSH	TCP: 22
Remote Desktop (RDP)	TCP: 3389 UDP: 3389	Some Windows Remote Desktop Protocol (RDP) client apps (such as newer Windows 10 versions) 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. For more information, reference Configure the Windows Firewall to Allow SQL Server Access (https://docs.microsoft.com/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017).
MySQL	TCP: 3300-3306, 33060 TCP: 33062 (for admin-specific connections)	For general MySQL connection use cases, only port 3306 is required, but some users may take advantage of the additional MySQL feature ports. Netskope recommends using a port range for MySQL database private apps. MySQL blocks connections from the Netskope Private Access publisher because it detects the reachability test as a potential attack. Using a range in the port configuration results in the Netskope Private Access publisher performing a reachability check only on the first port in the range. This prevents MySQL from seeing this traffic and avoiding the port block. For more information, reference MySQL Port Reference Tables (https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html).

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

The polling interval is about one minute.

Netskope Private Access Publisher tries 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 by hostname (for example, jira.globex.io) and port (for example, 8080).
• When an app is specified with multiple ports or a port range, the publisher uses the first port from the list or range to check availability.
• The publisher cannot 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).

If the registration fails (for example, because a digit was missed while entering the registration code), 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 unsupported and not advised. In this scenario, reinstall the publisher.

No. Netskope Private Access does not tunnel ICMP, only TCP and UDP. You cannot run ping or traceroute over Netskope Private Access to test network connections.

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

No. The publisher does SSL pinning for the registration process and server-side certificate authentication against a specific certificate.

In this case, if there is any proxy which terminates the TLS connection, the destination must be allowlisted/bypassed (*.newedge.io).

The private app host sees the connection as originating from the IP address of the publisher that is connecting to it. There is no range. Depending upon the number of publishers used to connect to the private app host, allowlist each of those IP addresses.

If deployed into Amazon Web Services, assign the Amazon Machine Image (AMI) a KeyPair.pem that you already have (or generate a new KeyPair.pem) during the provisioning of the publisher.

From an SSH client, type ssh -i [KEYPAIR.PEM] centos@[PUBLISHER] and then press Enter.

After successfully using SSH to connect to the publisher, you are placed into an interactive command-line interface (CLI) menu. You can choose option 3 to be placed into a normal UNIX CLI for additional troubleshooting. For more information, reference What is a good method for troubleshooting accessibility issues to a private app/service behind a publisher?

1. Right-click the Windows Start Menu and then click Run.

2. In the Run UI, type cmd and then press OK.

3. In the Command Prompt, type ssh centos@[publisher] and then press Enter.

Publishers work in active/passive mode. All traffic goes to a first publisher if it is operational (connected). If it goes down, we switch over to a secondary publisher.

The first best option is to use the Troubleshooter. Click Troubleshooter from the Private Apps page.

Choose the private app and device that you are trying to access, and then click Troubleshoot.

The Troubleshooter renders the list of performed checks, issues which may affect your configuration, and solutions.