Connector Deployment Prerequisites

Connector Deployment Prerequisites

Before deploying a Connector on any supported platform, Zscaler highly recommends reading the following information and making the necessary changes to your organization's environment, where applicable.

After you have met all of the prerequisites, you can deploy the Connector on a supported platform.

The following specifications are recommended by Zscaler for each ZPA Connector:

  • Memory: 4 GB RAM
  • CPU:
    • 2 CPU cores (Xeon E5 class) for physical machines without hyperthreading
    • 4 CPU cores (Xeon E5 class) for virtual machines (VMs) with hyperthreading 
      • Both Amazon Web Services (AWS) and Google Cloud Platform (GCP) require a minimum of 4 CPU cores due to hyperthreading
        • To deploy a Connector on AWS, Zscaler recommends using c4.xlarge or m4.xlarge
        • To deploy a Connector on GCP,  Zscaler recommends using a Linux RPM on n1-standard-4 or n1-highcpu-4
      • Azure VMs older than V3 require 2 CPU cores, while VMs V3 and higher require 4 CPU cores due to hyperthreading
        • To deploy a Connector on Azure, Zscaler recommends using Standard_F4s_v2 or Standard_D4s_v3

To learn more, see the Connector Deployment Guide for your platform.

  • Disk Space: 8 GB (thin provisioned)
  • Network Card: 1 NIC (minimum)

Using these specifications, each Connector supports up to 500 Mbps of throughput. To learn more, see Understanding Connector Throughput below. Based on Zscaler's recommendations, determine the Connector sizing requirements for your deployment.

Once a Connector is enrolled, an outbound TLS tunnel over port 443 is established to the ZPA cloud infrastructure. This communication channel provides various functionality and utilizes minimal bandwidth, which includes the following traffic:

  • Periodic keepalives to ZPA ZENs
  • Application learning
  • Application health reporting
  • ZPA software upgrades (upgrades are completed based on a weekly schedule)

You can deploy additional Connectors at any time, using the same provisioning key to add them to the existing Connector Group, while ensuring network and Internet connectivity. Connectors are designed to scale elastically. You can deploy additional Connectors, in the same Connector Group, to increase the total throughput as required by your deployment. To learn more, see About Deploying Connectors and Supported Platforms for Connectors.

After deployment, ensure that the Connector meets your sizing requirements. To learn more, see Verify Connector Sizing Specifications.

Understanding Connector Throughput

Throughput numbers are aggregate (i.e., total inbound and outbound). The following best practices apply regarding Connector throughput sizing:

  • Check your existing VPN solution's average and peak throughput. Be sure to only account for user/client VPN traffic and not any site-to-site tunnel traffic.
  • Connectors communicate over the provided (default) gateway, which is most likely your ISP WAN broadband connection.
  • Using double encryption will affect throughput. However, the affect varies based on the number of applications that are enabled for double encryption.

So, if you have a 1 Gbps connection (aggregate) in your data center, you can use the throughput guidelines below to make sure you have enough Connectors to support the connection and have room for failover (N+1). For example, with a 1 Gbps connection, you would need to deploy 2-3 Connectors if your applications are not using double encryption, but 4-6 Connectors if they are. To learn more, see About Double Encryption.

The following throughput guidelines apply based upon the recommended Connector specifications:

% of Applications with Double Encryption Per Connector Throughput
0% 500 Mbps
25% 437.5 Mbps
50% 375 Mbps
75% 312.5 Mbps
100% 250 Mbps

To increase throughput it is possible run a Connector on hardware with more memory and CPUs. However, Zscaler recommends that you have more Connectors with lower specifications rather than fewer Connectors with higher specifications in order to horizontally scale your deployment. For example, if you have a fewer larger Connectors and one fails, you could adversely affect more user application traffic/sessions than a smaller Connector that fails.

Before you begin any procedures within the Connector Deployment Guide for your platform, make sure that you have met all of the following prerequisites:

  • Intel x86_64/AMD64 based architecture
  • systemd
  • Root or sudo access to the system in order to configure a new package repository and install packages
  • DNS resolution and network access
  • A Connector provisioning key obtained from the ZPA Admin Portal

If you are deploying a Connector for AWS, you must create a Connector provisioning key for each AWS Region. If VPC peering isn't in place, a new provisioning key will also be required for each VPC within a Region.

  • A static MAC address

Connectors can be deployed in different ways (as private cloud VMs, public cloud VMs, or OS packages), so the security features for each deployment type are slightly different.

Operating System Security  

The Connector VMs distributed by Zscaler for use in private clouds are configured without any remotely accessible services running. While these Connector VMs have default credentials, the default username and password are normally only usable on the local console. Zscaler recommends that you change the default password. To learn more, see the Connector Deployment Guide for the platform you're using.

In public cloud environments such as Azure Compute and Amazon Web Services EC2, SSH is enabled by default but password-based login is disabled. You to need access to the system using SSH public-key based authentication instead of a username and password. You can retrieve the SSH public keys using standard mechanisms such as cloud-init and the EC2 metadata service. Additional security in such environments is provided via the use of "Security Groups", which are firewall policies that are applied to the VMs.

Both the private and public cloud VM images provided by Zscaler were configured with minimal listening services to reduce the remotely exploitable attack surface. Because these are essentially unmodified operating systems (currently based on CentOS 7.2), you can patch these systems when necessary by using the standard yum OS update mechanism. To learn more, see Update Connector System Software

Due to the fact that vulnerabilities are regularly found in core open-source components such as DNS resolvers and the Linux Kernel, Zscaler recommends either patching or using new Zscaler-distributed VM images on a regular basis, or protecting Connectors using firewall policies. Additionally, if you've installed the Connector as a package, Zscaler recommends that you take similar precautions.

Some organizations choose to firewall or otherwise restrict outbound traffic to the Internet from the data center. It is possible to deploy a Connector in such an environment as long as the Connector is able to reach all Zscaler data centers containing ZPA ZENs. For firewall configuration information for your deployment, see

Firewall Requirements and Interoperability Guidelines

All of the Zscaler data centers containing ZPA ZENs must be allowed. A partial firewall configuration will result in connectivity problems for end users. Zscaler’s policy is to provide a 90 day notice for activating additional IP CIDR ranges, in order to provide organizations with sufficient opportunity for changing control policies.

To ensure interoperability with other security products and services, including the Zscaler Internet Access (ZIA) service:

  • Zscaler explicitly recommends against sending Connector traffic through an existing Zscaler tunnel (IPSec, GRE, etc.) or through any form of encapsulation that might interfere with the use of a standard 1500 byte MTU.
  • Because the service enforces TLS certificate pinning for both client and server certificates, all forms of inline or man-in-the-middle TLS interception or inspection must be disabled. Connectors will not function if the TLS certificates presented by the ZPA ZENs do not cryptographically verify against Zscaler-trusted public keys.

By design, certificate verification is not configurable in order to maintain the integrity of the service. So ensure that is in your SSL bypass list for traffic originating from the Connector. This is necessary for allowing the Connector to resolve and reach ZPA ZENs. Also refer to if you need to whitelist additional Zscaler IP addresses.