Updated on December 6, 2023

Docy

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.

Note

  • 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.
Table 22. Network Settings for Secure Web Gateway (SWG)
DomainPurpose
  • Primary: gateway-<tenant_hostname>.goskope.com
  • Backup: gateway-backup-<tenant_hostname>.goskope.com
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}.goskope.com
addon-<tenant_hostname>.goskope.comFor downloading configuration files and dynamically detecting proxies.
download-<tenant_hostname>.goskope.comFor downloading client package updates.
achecker-<tenant_hostname>.goskope.comFor 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.
sfchecker.goskope.comTo verify secure forwarder connection.


Note

For international deployments, use one of the following as per the region of the your home PoP:

  • <tenant_hostname>.eu.goskope.com
  • <tenant_hostname>.de.goskope.com.
  • <tenant_hostname>.au.goskope.com.

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.

Note

  • 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 on 109.0.0. Versions 108.0.0 and prior continue to work in an existing manner with EDNS/LDNS. When a client version 108.0.0 or lower has the functionality enabled, updating to 109.0.0 causes the GSLB to activate automatically without requiring a restart. After the functionality is activated on Publisher versions 108.0.0 and lower, updating to 110.0.0 cause Publishers to automatically activate the GSLB 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. NPA customers will now be able to 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>.goskope.com

  • gateway-<tenant-name>-backup.goskope.com

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.

Note

  • 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.

Prerequisites

Ensure that the following IP ranges are allowed for outbound access on your firewall:

  • 8.36.116.0/24

  • 8.39.144.0/24

  • 31.186.239.0/24

  • 163.116.128.0/17

  • 162.10.0.0/17

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(dns.google) 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 gateway.gslb.goskope.com 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.

Note

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: Box.com)
  3. Browser/App receives a DNS response (For example: 74.112.184.73)
  4. The Client driver captures DNS response and creates a map of domain and IP (For example: Box.com = 74.112.184.73 for cloud app domains)
  5. Browser/App sends packets to Box.com (For example: DST IP 74.112.184.73)
  6. Client tunnels Box traffic (For example: DST IP 74.112.184.73) 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 will first try 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. 

    Note

    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: ep.customer.com.
  3. The client parses the initial header of the connection.
  4. If the initial header indicates the connection is a SaaS app, then the client sends the entire payload through that SSL tunnel to the Netskope gateway.
  5. If the initial header does not indicate SaaS app HTTPS access, the TCP proxy opens a connection to and forwards the entire payload to the explicit proxy server. For example: ep.customer.com.

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 10.10.10.11 and Proxy port is 8080 and the managed domain is www.box.com 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: 192.168.13.40:49614, 
process: chrome.exe to host: www.box.com,addr: 10.10.10.11:8080
Share this Doc
In this topic ...