Before deploying a Publisher, factor these requirements and recommendations:
General Host Requirements
- x86_64 architecture
- 2 CPUs
- 4 GB RAM
- 16 GB HDD space
Network Time Protocol
For Network Time Protocol (NTP), either:
- Ensure your local NTP servers are synchronized properly (this is generally required in case of DHCP networking configuration).
- Ensure that access to Internet NTP servers works properly.
Publisher Capacity
When factoring publisher capacity and scaling, consider the following key points:
- Each tenant can support up to 1000 Publisher instances. The default limit is 100 Publisher instances. This limit can be increased following a review with the Netskope product team.
- Each Publisher can handle around 500 Mbps of throughput.
- A Publisher is agnostic to the number of users that traverse it.
- A Publisher is limited to using a single IP address for both inbound and outbound connections.
- A single Publisher can support up to 28,000 concurrent TCP/UDP connections, Netskope recommends to leave a 20% buffer when determining the number of required publishers.
Firewall Requirements
The Publisher only requires communication over the following ports and protocols:
- Inbound
- SSH Access: Port 22 for management.
- Outbound
- DNS: Port 53.
- HTTPS: Port 443.
- Other Ports: The Publisher requires connectivity to/from the TCP and UDP ports necessary for application access.
Note
NPA Publisher traffic expects TCP return traffic from these destinations to be implicitly allowed as part of typical stateful outbound firewall policy.
Network Access
NPA access needs are:
| Component | URL | Port | Notes |
|---|---|---|---|
| Client |
| TCP 443 (HTTPS) |
|
| Publisher |
| TCP 443 (HTTPS)
TCP 80 (HTTP) for |
|
| Client and Publisher |
ns-<tenant-ID>.<MP-name>.npa.<tenant-domain-suffix> Contact your Netskope SE, TSM, or Support for your | TCP 443 (HTTPS) |
Requires outbound access during enrollment/re-enrollment of NPA for the Client and for registration of the Publisher. Example URL:
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 |
| Client and Publisher |
| 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 Publisher | dns.google | TCP + UDP 53 (DNS) TCP 443 (DNS-over HTTPS / DoH) |
|
DNS and IP Information
Publisher uses DNS for Enrollment into the NPA service and for connecting to the Netskope cloud. Please refer to the following DNS information for your NPA tenant.
https://gateway.npa.<tenant-domain-suffix>https://stitcher.npa.<tenant-domain-suffix>*.docker.com*.docker.io*.ubuntu.comhttps://ns-<tenant-ID>.<MP-name>.npa.<tenant-domain-suffix>tenant-IDwould be the typical ID, such as 1234, etc.MP-namerepresents the Home MP Name.
For example: ns-1234.us-sjc1.npa.goskope.com.
For Management Plane IPs, go to List of IP Ranges for Allowlisting 
and refer to the Netskope Private Access List for Allowlisting table.
For Dataplane IPs, go to Data Plane IP Ranges .
Publisher Sizing for Apps or Wildcard Networks/Domains
While Publishers are agnostic to the number of users, the number of users that are supported by a single Publisher is dependent on the type of application. Use the information below to help determine maximum number of users per Publisher based on the applications used:
- In a customer environment where a Publisher is processing different types of application flows (such as Web, RDP, SMB and others), a Publisher’s resources (CPU, TCP/UDP connections, throughput) may be over-utilized as they process compute for intensive applications that rely on RDP or SMB. In such a scenario, a customer should monitor Publisher utilization and consider dedicating Publishers for the compute intensive applications to avoid resource starvation for other applications on the shared Publishers.
- For web applications, browsers can open up to six concurrent connections per domain. For the purpose of sizing, the recommendation is to divide 32,000 by 6 to derive how many maximum concurrent users may be using a single Publisher for a web server.
- For FTP workloads, it’s 2 TCP connections per user per FTP session.
- For SSH/SQL connections, it’s one TCP connection per user.
To scale access to broad networks and/or large applications, the following approach can be used.
In order for NPA to distribute the load evenly across the newly introduced Publishers in the cluster, you can reboot the original set of Publishers during a maintenance window. This results in users getting evenly distributed across Publishers.
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.
- 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.
- Netskope recommends that your network includes DHCP.
Note
Publishers may be subject to SSL interception. Make sure that access to *.npa.goskope.com is disabled for SSL interception.
Network Settings
In the Publisher Wizard (available via your virtualization console or after SSHing to a running Publisher), you can now select Network Settings for configuration details.
There are two configuration options available:
- DHCP: This allows you to specify a network adapter for DHCP configuration. eth0 is used in the example, but other adapters may be present depending on your Publisher hardware configuration. For example, ens32 or similar will be present on Publishers deployed to VMWare.
- Static IP: This option allows you to specify static IP address configurations in environments where DHCP configuration is not possible. The following values must be provided as part of this configuration:
- Network Adapter
- IP Address and Mask: For example, 192.168.1.189/24
- Gateway: For example, 192.168.1.1
- DNS Servers: We recommend using two DNS server IP addresses, though only 1 is required.
- Default Search Domain: This configuration is typically set to match the domain name of your company.
Note
For Publishers running in Public Cloud environment like AWS, Azure, and GCP, network settings need to be set via the Cloud Provider Console.
To enable access using a PQDN with multiple search domains, refer to this article about enabling the Multi Search Domains Support feature. The Multi Search Domains Support feature is currently available for Windows and macOS operating systems. If PQDN access is needed from a mobile device such as Android or iOS, or from a device that is not domain joined, you will need to provision multiple search domains on the Publisher.
Publisher wizard settings allow adding one default search domain. Use the following steps to add multiple search domains on Ubuntu 22.04 Publisher machines:
- Create a
/etc/netplan/51-cloud-init.yamlfile with multiple search domains. For example:network: ethernets: eth0: nameservers: search: [one.com] search: [two.com] search: [three.com] search: [four.com] search: [five.com] search: [six.com]Note
Change “eth0” to the corresponding internet network interface.
- Run this command:
sudo netplan try. - Run this command:
sudo netplan apply.
Only six or less search domains can be added through netplan due to the limitation in systemd on Ubuntu 22.04. If there is a requirement to add more than six search domains, add the search domains in /etc/resolv.conf instead of netplan. Keep in mind the settings don’t persist on reboot, and the entries for search domains need to be added again if a Publisher is rebooted.
In addition to the above, the App Definition would also need to include the PQDN. For example, if the application to be accessed via PQDN is app1, then app1 must be defined as a host within the App Definition.