Netskope Client Network Configuration

Netskope Client Network Configuration

For the normal functioning of the client, a set of outbound domains and port 443 must be allowed in the user’s firewall or proxy. The following table describes the list of domains and ports used by the client.


  • Firewall address: We recommend the use of IP addresses instead of domain names to configure firewall or proxy rules allowlist. If your environment uses a firewall or proxy, ensure that you process the backup gateway URL in the same manner as the primary gateway URL. The backup gateway URL is suffixed with gateway-backup to the primary URL.
  • HTTP/2: We negotiate HTTP/2 for all domains if the origin server supports it, otherwise, we fallback to HTTP 1.1. All other traffic will continue to leverage HTTP 1.1. In addition, the Netskope Client and GRE / IPSEC and iOS access methods are fully supported. The protocol change is completely transparent to users, no configuration is required by admins. Contact Support to enable this feature in your account.
  • iOS device behind NAT: While using Guest WiFi for your iOS users, all iOS devices behind a NAT device establish a VPN connection with the Netskope Cloud VPN server with a NATted IP address. Netskope recommends you to use multiple NAT IPs to avoid slow VPN connection or performance degradation. By using multiple NATted IPs, the VPN connection gets distributed to multiple VPN gateways because of the load balancing algorithm that is currently based on the source IP address.
Primary: gateway-<tenant-URL>

Backup: gateway-backup-<tenant-URL>
For client data plane connectivity. This domain needs to be SSL allowlisted on the egress firewall if SSL interception is enabled. Also, do the same for gateway-backup-{tenant_hostname}.<tenant-domain>
addon-<tenant-URL>For downloading configuration files and dynamically detecting proxies.
download-<tenant-URL>For downloading client package updates.
achecker-<tenant_URL>For client enforcement. This is required to enforce the end-user to install the Client on their device. If the Client is not installed in the users’ device, access to an app or domain specified in the steering configuration is restricted and the user is redirected to a browser page with instructions to install the Client.
nsauth-<tenant_URL>Used when Netskope Client is configured to use IdP authentication in IdP enrollment, NPA re-auth, and so on.
Network Settings for Secure Web Gateway (SWG)

To learn more about the network settings for Network Private Access (NPA), view NPA settings.

NewEdge Traffic Management Gateway Selection

NewEdge Traffic Management 2.0(or GSLB) is a platform that allows more intelligent features to be layered on top of NewEdge, providing diagnostic data that allows Netskope to quickly identify and address network issues, improve data center(DC) selection, enable consistent performance, and so on. In simplest terms, Global Server Load Balancing(GSLB) translates into better performance, stability, resilience, and an overall better experience for users.

NewEdge Traffic Management is no longer purely DNS-based and incorporates real-time RTT measurements to ensure optimal DC selection. In short, it allows the Netskope Client to accurately select DCs, resulting in improved performance. Additionally, the Netskope Client is aware of the larger number of DCs, providing improved resiliency.


  • GSLB services are available for SWG and  Private Access.
  • In the event of GSLB call failure, Publisher and Netskope Client fallback to EDNS or LDNS.
  • Configure the number of IPs returned by the GSLB service for a tenant. Default is 10. Contact Support to modify this value.
  • For Private Access:
    • The minimum version for Client and Publisher must be 109.0.0. Restart of Netskope Client and Publisher is required upon enabling the feature. Older versions continue to work with EDNS/LDNS.
      • If GSLB functionality is enabled for Netskope Client versions 108.0.0 or lower, updating to 109.0.0 activates GSLB automatically without requiring a restart.
      • If the GSLB functionality is enabled for Netskope Publisher versions 108.0.0 or lower, updating to 110.0.0 activates GSLB automatically without requiring a restart.
    • You can now configure New Edge Traffic Management Zones per tenant.
    • Do not support Periodic RTT checks during the session.
    • Fallback to EDNS/LDNS can be disabled.

Netskope Private Access tenants may now take advantage of NewEdge Traffic Management intent-based Zones. Some organizations have inline (or “data in motion”) compliance requirements that restrict inline traffic processing to specific geographical regions. Now, the NPA tenants can restrict traffic to supported Zones. To learn more: Configure NewEdge Traffic Management Zones per NPA Tenant.

Existing Behavior(Prior to version 100.0.0 for SWG and 109.0.0. for Private Access)

NewEdge Traffic Management 1.0 is a DNS-based DC selection mechanism where the Netskope Client performs DNS lookups of one of the following FQDNs:

  • gateway-<tenant-name>.<tenant-domain>

  • gateway-backup-<tenant-name>.<tenant-domain>

Additionally, with the previous version, the Netskope Client attempts to resolve these FQDNs using Google DNS through DNS-over-HTTPS(DoH). If DoH fails, local DNS resolvers are used.

New Behavior(Applicable from version 100.0.0 for SWG and 109.0.0 for Private Access)

With NewEdge Traffic Management 2.0, a TCP-based method is used to obtain RTTs, utilizing services fully hosted within NewEdge, without reliance on any external services.


  • For SWG: This behavior is currently enabled by default only for new tenants. To enable this feature for the existing tenants, contact your Sales Representative or Netskope Support.
  • For Private Access: To enable this feature, contact your Sales Representative or Netskope Support.
Supported Operating Systems

New behavior is supported on all operating systems. For more details, view Netskope Client Supported OS and Platform.


Refer to the Support portal to understand the allowed IP ranges for outbound access on your firewall.

– FedRAMP High IPs are different and the current list can be found here: (Requires a Support account).
– To collect Client logs through the Netskope tenant, view Unable to collect client debug logs remotely(Requires a Support account).

Also, ensure that your VPN is not configured to tunnel those IP ranges through a VPN tunnel. To learn more about VPN compatibility, view VPN Applications.

NewEdge Traffic Management 2.0 eliminates the need to use Google DNS service( to resolve the Netskope Gateway domains. The reason for this is DNS resolution alone may fail to identify the optimal Netskope Gateway or consider the performance characteristics related to Netskope Client tunnels. With GSLB, the Netskope Client establishes a connection with the optimal Netskope Gateway that provides better performance and resilience. 

NewEdge Traffic Management 2.0 works as follows:

  • The Netskope Client makes an API call to the NewEdge Traffic Management service to obtain the list of DCs. This service is resolved by performing a DNS lookup of the FQDN. The service generates the candidate list based on geolocation of the endpoint’s full IP address.

  • It then performs RTT measurements against each DC.

  • It packages this information and includes it in a second API call to the service.

  • The service then responds with a prioritized list of DCs that the Netskope will use to establish tunnels to NewEdge.


Netskope recommends blocking DoH(DNS over HTTPS) or DoT(DNS over TLS) as it enforces the browsers to use the DNS over UDP resolution. In this way, Netskope Client continues to monitor the DNS responses and maintain the IP address to hostname mapping.

For the Client to apply steering configurations, it is essential to validate the DNS queries and responses. Since DoH or DoT encrypts the DNS payload, the Netskope Client cannot look into the DNS response. Hence, Netskope recommends to configure policies in proxy or firewall to block DoH and DoT and steer traffic. To steer DoT traffic(using port 853), Netskope Client checks for the following conditions:

  • If SecureDNS and Cloud firewall is enabled.
  • If SWG is enabled at custom port 853.
  • If CASB mode is enabled at custom port 853 and DoT server is at the steering domain list. SWG is required to configure custom port in CASB mode.

To learn more about the policies to block DoH, view Recommended Policy.

Netskope Client in a Non-Proxy Environment

Here are the packet flow details of how the cloud app traffic is intercepted and sent through the tunnel when the client is installed in a non-proxy environment:

  1. The Client establishes the SSL tunnel between the Client and the Netskope gateway.
  2. Browser/App sends a DNS request for a managed cloud service (For example:
  3. Browser/App receives a DNS response (For example:
  4. The Client driver captures DNS response and creates a map of domain and IP (For example: = for cloud app domains)
  5. Browser/App sends packets to (For example: DST IP
  6. Client tunnels Box traffic (For example: DST IP through the SSL tunnel.

Netskope Client in an Explicit Proxy Environment

Here are the packet flow details of how the Cloud app traffic is intercepted and sent through the tunnel when the client is installed in an explicit proxy environment:

  1. The Client establishes the SSL tunnel between the Client and the Netskope gateway. The Client first tries to connect directly through default gateway to establish the SSL tunnel. If this is blocked, then it looks for system proxy settings, such as PAC (proxy auto-config) files, WPAD (Web Proxy Auto-Discovery Protocol), and manual configuration. The client uses the proxy settings and connects to the Netskope gateway via HTTP Connect.

    The Netskope gateway should be SSL allowlisted if the proxy is configured for SSL decryption. If your environment uses firewall or proxy, ensure that you process the backup gateway URL in the same manner as the primary gateway URL. The backup gateway URL is suffixed with gateway-backup to your primary URL.
  2. The browser or native app reads the proxy settings (PAC file, explicit proxy setting) and opens a connection to an explicit proxy server, for example:

  3. The client parses the initial header of the connection.

  4. If the initial header indicates the connection is:

    • Cloud mode (SaaS app): The initial header indicates the hostname of the SaaS application. If the hostname is not a part of the managed SaaS application exception configuration, the Client bypasses the traffic to a local proxy server.

    • Web and All Traffic mode: The initial header indicates the hostname of the web application. If the hostname is a part of the exception, the Client bypasses the traffic to a local proxy server. Otherwise, the traffic is tunneled to the Netskope gateway.

  5. If the initial header does not indicate SaaS app HTTPS access, the Netskope Client bypass the traffic and forwards the entire payload to the explicit proxy server. For example:

Netskope Client log messages with On-prem Proxy

Steering traffic flow and Log message: With on-prem proxy, the Netskope Client monitors for HTTP CONNECT requests. It checks for the domain name in these requests against the managed domain list. If the name matches then it will reconstruct the TCP SYN packet and send it through the Netskope Tunnel and at the same time it will send TCP RST to on-prem proxy, and it will take control of that connection. After the TCP 3-way handshake with Netskope proxy, it sends the HTTP CONNECT request and the flow continues with Netskope proxy. Since TCP flow will be with destination IP of on-prem proxy when Netskope Client logs the message, it will show destination IP as on-prem Proxy and the domain name will be the managed domain.

Assuming on-prem Proxy IP is and Proxy port is 8080 and the managed domain is then you will see the log line as below:

2021/07/18 17:16:11.282 stAgentSvc pfbc t296c 4 tunnel.cpp:618 nsTunnel TLS [sessId 1]
Tunneling flow from addr:, 
process: chrome.exe to host:,addr:
Share this Doc

Netskope Client Network Configuration

Or copy link

In this topic ...