icon-unified.svg
Experience Center

App Connector Deployment Guide for Google Cloud Platform

This deployment guide provides information on prerequisites, how to deploy an App Connector on Google Cloud Platform (GCP), and post-deployment verification checks. For general information regarding App Connector deployment for Private Applications, see About Deploying App Connectors.

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

    • The following specifications are recommended by Zscaler for each App Connector:

      • Memory: 4 GB RAM

      For Digital Experience Monitoring deployments, Zscaler recommends App Connectors to have 8 GB of 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 an App Connector on AWS, Zscaler recommends using t3.xlarge (for non-production or low traffic App Connectors) or m5a.xlarge (for production or high traffic App Connectors)
            • To deploy an App 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 an App Connector on Azure, Zscaler recommends using Standard_F4s_v2 or Standard_D4s_v3

      For Digital Experience Monitoring deployments, Zscaler recommends App Connectors to have 4 CPU cores.

      For Privileged Remote Access connections, Zscaler recommends adjustments to the CPU cores and RAM on your App Connectors. To learn more, contact Zscaler Support.

      Privileged Remote Access is only supported on App Connectors running CentOS 7.8 and later.

      Using the PassMark Software Pty Ltd benchmark to verify the CPU Mark score, Zscaler recommends using a minimum CPU benchmark score of 2640 when choosing a CPU processor. The Intel Advanced Encryption Standard New Instructions (AES-NI) instruction set must also be enabled on the CPU processor.

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

      • Disk Space: 64 GB (thin provisioned) for all deployment platforms
      • Network Card: 1 NIC (minimum)

      For VMware platform deployment, the default configuration to allow the host to dynamically allocate VM resources is not recommended. Configure the VM setting to reserve the following memory and CPU allocations:

      • Memory: 8 GB RAM
      • CPU: total CPU GHz (the number of cores (2 or 4 cores) multiplied by the GHz per core)

      To learn more, see VMware Resource Allocation Reservation.

      Using these specifications, each App Connector supports up to 500 Mbps of throughput. To learn more, see Understanding App Connector Throughput in this article. Based on Zscaler's recommendations, determine the App Connector sizing requirements for your deployment. If disk space fills up in the App Connector, Zscaler recommends archiving files and creating more log space. To learn more, see Monitoring App Connector Performance.

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

      • Periodic keepalives to Public Service Edges or Private Service Edges
      • Application learning
      • Application health reporting
      • App Connector software upgrades (upgrades are completed based on a weekly schedule)

      You can deploy additional App Connectors at any time, using the same provisioning key to add them to the existing App Connector Group, while ensuring network and internet connectivity. App Connectors are designed to scale elastically. You can deploy additional App Connectors, in the same App Connector Group, to increase the total throughput as required by your deployment. Zscaler recommends you have a minimum of two healthy App Connectors to always ensure an available path. To learn more, see About Deploying App Connectors and Supported Platforms for App Connectors.

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

      Understanding App Connector Throughput

      Throughput numbers are aggregate (i.e., total inbound and outbound). The following best practices apply regarding App 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.
      • App Connectors communicate over the provided (default) gateway, which is most likely your ISP WAN broadband connection.
      • Using double encryption affects throughput. However, the effect 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 in the table to make sure that you have enough App Connectors to support the connection and room for failover (N+1). For example, with a 1 Gbps connection, you would need to deploy 2 to 3 App Connectors if your applications are not using double encryption, but 4 to 6 App Connectors if they are. To learn more, see About Double Encryption.

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

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

      It is possible to increase App Connector throughput up to 1 Gbps per App Connector by running the App Connector on hardware with more memory and CPUs along with increased network link speed. If you have a 10 Gbps connection (aggregate) in your data center, and you want to increase the App Connector throughput up to 1 Gbps per App Connector, you can increase the underlying VM spec as follows:

      • 8 vCPU cores for virtual machines or 4 CPU cores for physical machines
      • 8 GB RAM

      The exact throughput can vary and depends on other network factors such as your internal network setup, latency, and whether you have double encryption, App Protection, and/or Digital Experience Monitoring enabled. Make sure that you have enough App Connectors to support the connection and room for failover (N+1).

      Zscaler recommends that you have more App Connectors with lower specifications rather than fewer App Connectors with higher specifications in order to horizontally scale your deployment. For example, if you have fewer App Connectors with higher specifications and one fails, you could adversely affect more user application traffic/sessions than a smaller App Connector that fails.

      Close

    • Before you begin any procedures within the App 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

      • An App Connector provisioning key obtained from the Admin Portal

      • A static MAC address

      Close

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

      Zscaler recommends treating access to App Connectors as privileged, so only authorized personnel can access an App Connector's console. By limiting access, there is the added benefit of shielding inter-process communication within the App Connector from attack.

      Operating System Security

      The App Connector VMs distributed by Zscaler for use in private clouds are configured without any remotely accessible services running. Swap partitions are disabled on the App Connector VMs to ensure that memory growths do not have an impact on App Connector performance. For enhanced security, you must use the passwd command to change the credentials on the default admin account. To learn more, see the App Connector Deployment Guide for the platform you're using.

      Both the private and public cloud VM images provided by Zscaler are configured with minimal listening services to reduce the remotely exploitable attack surface. Because these are essentially unmodified operating systems (currently based on CentOS 7.x), you can patch these systems when necessary by using the standard yum OS update mechanism. To learn more, see Update App 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 App Connectors using firewall policies. Additionally, if you've installed the App 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 an App Connector in such an environment as long as the App Connector is able to reach all Zscaler data centers containing Public Service Edges. For firewall configuration information for your deployment, see config.zscaler.com/private.zscaler.com/zpa (for the private.zscaler.com cloud) or config.zscaler.com/zpatwo.net/zpa (for the zpatwo.net cloud).

      Firewall Requirements and Interoperability Guidelines

      All of the Zscaler data centers containing Public Service Edges must be allowed. A partial firewall configuration can 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.

      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. App Connectors do not function if the TLS certificates presented by the Public Service Edges or Private Service Edges 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 *.prod.zpath.net is in your SSL bypass list for traffic originating from the App Connector. This is necessary for allowing the App Connector to resolve and reach Public Service Edges or Private Service Edges. If you need to allowlist additional Zscaler IP addresses, see config.zscaler.com/private.zscaler.com/zpa (for the private.zscaler.com cloud) or config.zscaler.com/zpatwo.net/zpa (for the zpatwo.net cloud).

      For Private Application integration with Digital Experience Monitoring, App Connector firewall requirements must align with the respective Digital Experience Monitoring configuration. You must configure the firewall to allow egress traffic on the TCP, UDP, and ICMP protocols. App Connectors must be able to egress traffic to port 443 for Zscaler Service Edge connections and the ports of all configured applications (i.e., ports that are configured in all application segments that are registered on the App Connector).

      Close

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

    Close

  • For GCP, you must deploy App Connectors in your Virtual Private Clouds (VPCs). For each VPC, there must be at least a pair of App Connectors deployed for resilience and scalability. The App Connectors should be deployed across regions and zones to ensure continuity of service in the event of an incident. Zscaler automatically load balances across the App Connectors. Additional capacity can be handled by adding additional App Connectors into each region and zone.

    App Connectors should be configured with the right access to applications in the VPC. The VPC configuration should permit the App Connectors to connect to the application servers on the appropriate TCP/UDP ports, and enable ICMP reachability and DNS resolution to the applications. The App Connector's VPC configuration should permit outbound access to the internet to connect to the Zscaler cloud. Zscaler recommends deploying the App Connectors on a private subnet which connects to the internet through a NAT gateway.

    The following prerequisites must be met before deploying the App Connector instance:

    • To install the Google Cloud CLI, refer to the Google Cloud documentation.

      Close

    • To create a firewall rule:

      1. Log in to the GCP Management Console.
      2. In the left-side navigation, click Network Security.

      3. Go to Cloud NGFW > Firewall Policies.

        The Firewall policies window appears.

      4. In the Firewall policies window, click Create firewall rule.

        The Create a firewall rule window appears.

      5. In the Create a firewall rule window:

        • Name: Enter a name for the firewall rule.
        • Network: Select the network to which the firewall rule applies.
        • Direction of traffic: Select either Ingress (receiving traffic) or Egress (sending traffic).
        • Action on match: Select whether the action permits (Allow) or blocks (Deny) the connection.
        • Targets: Select the targets to which the firewall rule applies from the drop-down menu (All instances in the network, Specific target tags, or Specified service account).
        • Source filter: Select a source filter range (IPv4 ranges, IPv6 ranges, or Source tags). Enter the IP address range in the Source filter ranges text box that appears after selecting a source filter range using the network IP/subnet format. An example IPv4 range would be 0.0.0.0/0.
        • Protocols and ports: Select Specified protocols and ports and specify the protocol (TCP, UDP, Other) and ports. The App Connector must have ingress and egress traffic directions on TCP port 22 for SSH, and egress traffic directions on TCP port 443 to reach Private Applications.

      6. Click Create.

      If necessary, egress traffic directions can be restricted to hosts and ports for Private Applications. For details regarding required IP addresses, see config.zscaler.com/private.zscaler.com/zpa (for the private.zscaler.com cloud) or config.zscaler.com/zpatwo.net/zpa (for the zpatwo.net cloud).

      Close

    You can deploy the image on GCP using one of the following methods:

    • This procedure describes how to deploy in GCP for Private Applications using the Instance wizard, and assumes that you have created an SSH key pair and an image from a .vmdk (virtual disk).

      After you create an SSH key pair and an image from the virtual disk,

      To deploy an App Connector using an App Connector instance:

      1. Log in to the GCP Management Console.
      2. Create a project.
      3. Select your project (e.g., zpa-connector).

      4. Go to Compute Engine > Images.

        Navigating to the Images page

        Close

      5. Search for the custom image using a filter with the name of the image. An example of the custom name used for this step is zpa-connector-el9-2024-06-3c70f809-feature.

      6. Click the Menu icon, and then click Create Instance.

        The Create an instance window appears.

      7. In the Create an instance window, select New VM instance.

      8. In the New VM instance window for the Machine Configuration section, select the Machine type with preset amounts of vCPUs and memory that suit the workload. Zscaler recommends using the n2-standard-4 or n2-highcpu-4 machine types:

        • n2-standard-4: The supported specifications are 4 vCPU, 2 core, and 16 GB memory.
        • n2-highcpu-4: The supported specifications are 4 vCPU, 2 core, and 4 GB memory.

      9. (Optional) Pass the startup script to the VM instance.
        1. Click the Menu icon, and then click the Security tab.

        2. In the left-side navigation, go to Data Protection > Secret Manager.

          Viewing the Secret Manager page

          Close

        3. Click Create Secret.

          The Create secret window appears.

        4. In the Create secret window:

          1. Name: Enter the name of the secret (e.g., provisioning_key).
          2. Secret value: Enter the value for the secret (e.g., <your provisioning key>). You can acquire a provisioning key when creating an App Connector in the Admin Portal. To learn more, see About App Connector Provisioning Keys and Configuring App Connectors.

        5. Click Create Secret.
        6. For Access Scope, select Allow full access to all Cloud APIs. This allows access to the provisioning_key present in the secret manager.
        7. Expand the Advanced options section, and then expand the Management section.
        8. Add a description in the Description field.

        9. Enter the following script for the Automation field.

          #!/usr/bin/bash
# Sleep to allow the system to initialize
sleep 15
curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-cli-linux-x86_64.tar.gz
tar -xf google-cloud-cli-linux-x86_64.tar.gz
export PATH=$PATH:$PWD
sudo ./google-cloud-sdk/install.sh
# Install App Connector packages
yum install -y zpa-connector
# Stop the App Connector service which was auto-started at boot time
systemctl stop zpa-connector
# Fetch the secret from Secret Manager
SECRET_NAME="Provision_key"
SECRET_VALUE=$(gcloud secrets versions access latest --secret="$SECRET_NAME")
 
# Use the secret in your application or script
echo "The secret value is: $SECRET_VALUE"
# Example: Export the secret as an environment variable
export MY_SECRET="$SECRET_VALUE"
# Create a file from the App Connector provisioning key created in the ZPA Admin Portal
# Make sure that the provisioning key is between double quotes
echo "$SECRET_VALUE" > /opt/zscaler/var/provision_key
chmod 644 /opt/zscaler/var/provision_key
# Start the App Connector service to enroll it in the ZPA cloud
systemctl start zpa-connector
# Wait for the App Connector to download the latest build
sleep 60
# Stop and then start the App Connector for the latest build
systemctl stop zpa-connector
systemctl start zpa-connector
# Run a yum update to apply the latest patches
yum update -y
      10. Click Create.

      11. In the left-side navigation, go to Compute Engine > Virtual Machines > VM instances to verify that you created your instance. The instance name is displayed when creating the instance.

      12. SSH access is required to configure the GCP Private Key to the App Connector.
        1. Log in to the App Connector console using your GCP Private Key.
        2. Using a standard SSH client, enter the following command to connect to the GCP instance:
        ssh -i <GCP Private Key> admin@<App Connector Private Hostname or IP Address>

        In the following example, the private key for the GCP instance is gcp_key and the App Connector IP address is 172.31.255.255:

        ssh admin@172.31.255.255 -i ~/.ssh/gcp_key

        1. When you are asked if you want to continue connecting, enter yes.

          Connecting to gcp_key

        Close
      1. Apply the App Connector provisioning key.
        1. Stop running the zpa-connector service using the following command. If the provisioning key is not detected when the App Connector first started, then the App Connector is in a sleep cycle and looks for the key again every 24 hours.
        sudo systemctl stop zpa-connector
        1. Create a provisioning key file with 644 permissions at /opt/zscaler/var/provision_key. For example:
        sudo touch /opt/zscaler/var/provision_key
sudo chmod 644 /opt/zscaler/var/provision_key
        1. Copy the provisioning key from the Admin Portal, paste it into the file, and save. Use an editor, such as vi.
        sudo vi /opt/zscaler/var/provision_key

        If you are using vi, make sure it is in insert mode before you paste the key into the file.

        If you are unfamiliar with the vi editor, you can also use the following echo and tee commands to paste in the provisioning key:

        echo "<App Connector Provisioning Key>" | sudo tee /opt/zscaler/var/provision_key

        Make sure that the key is within double quotes (").

        1. Enter the following command to verify the file's content:
        sudo cat /opt/zscaler/var/provision_key

        The output should return the provisioning key you entered in the previous step.

        1. Start the zpa-connector service using the following command.
        sudo systemctl start zpa-connector
        1. Stop and disable the sshd using the following commands.
        sudo systemctl stop sshd
sudo systemctl disable sshd
        Close

      1. After the App Connector provisioning key is applied, verify that the deployed App Connector is running using the following commands:

        sudo su
ps aux | grep zpa-connector

        For example:

        # ps -aux | grep zpa-connector
root         1258  0.1  0.2 524684 21880 ?        Ssl 06:36    0:01 /opt/zscaler/bin/zpa-connector
root         7154  0.0  0.0   3880 2048 pts/1     S+  06:57    0:00 grep --color=auto zpa-connector

        To learn more, see Managing Deployed App Connectors.

      2. Zscaler highly recommends updating the App Connector system software before proceeding.
      Close

      Close

    • This procedure describes how you can deploy in GCP for Private Applications through Launch Templates and Auto Scaling configurations to create a scalable and supportable infrastructure.

      To deploy an App Connector on GCP using a Launch Template with Auto Scaling:

      1. Log in to the GCP Management Console.
      2. Click Compute Engine.
      3. In the left-side navigation, go to Instance Groups > Instance Groups.
      4. Click Create Instance Group.

      The Create Instance Group window appears.

      1. In the Create Instance Group window:
        1. Enter an Instance group name.
        2. Enter a Description.
        3. On the Instance template tab, click the drop-down menu and select the existing instance template, or click Create a New Instance Template to create a new instance template. If you click Create a New Instance Template,
          1. Enter the instance template Name.
          2. Enter the Machine configuration details.
          3. Under Boot disk, click Change.
          4. Select the customized zpa-connector.
          5. For Access scope:
            1. Select Allow full access to all cloud APIs to access the provisioning key that is present in the secret manager.
            2. Expand the Advanced options section, and then expand the Management section.
            3. In the Management section:
              1. Provide a description in the Description field.

              2. Add the following script in the Automation field.

                #!/usr/bin/bash
# Sleep to allow the system to initialize
sleep 15
curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-cli-linux-x86_64.tar.gz
tar -xf google-cloud-cli-linux-x86_64.tar.gz
export PATH=$PATH:$PWD
sudo ./google-cloud-sdk/install.sh
# Install App Connector packages
yum install -y zpa-connector
# Stop the App Connector service which was auto-started at boot time
systemctl stop zpa-connector
# Fetch the secret from Secret Manager
SECRET_NAME="Provision_key"
SECRET_VALUE=$(gcloud secrets versions access latest --secret="$SECRET_NAME")
 
# Use the secret in your application or script
echo "The secret value is: $SECRET_VALUE"
# Example: Export the secret as an environment variable
export MY_SECRET="$SECRET_VALUE"
# Create a file from the App Connector provisioning key created in the ZPA Admin Portal
# Make sure that the provisioning key is between double quotes
echo "$SECRET_VALUE" > /opt/zscaler/var/provision_key
chmod 644 /opt/zscaler/var/provision_key
# Start the App Connector service to enroll it in the ZPA cloud
systemctl start zpa-connector
# Wait for the App Connector to download the latest build
sleep 60
# Stop and then start the App Connector for the latest build
systemctl stop zpa-connector
systemctl start zpa-connector
# Run a yum update to apply the latest patches
yum update -y
              3. Click Create.
          Close
      2. Select the region and zone from the drop-down menu.
      3. On the Autoscaling tab:
        1. Select a minimum and maximum number of instances as 2 and 4, respectively.
        2. Select CPU utilization for the Signal type drop-down menu.
        3. Enter 80 in the Target CPU utilization field.
        4. Enter 300 in the Initialization period field.
      4. Click Create.
      Close
    Close

  • After you have deployed the App Connector on a supported platform, you can complete the following networking configurations:

    • If necessary, additional interfaces can be configured by creating additional files in /etc/sysconfig/network-scripts.

      1. Log in to the App Connector console using your admin credentials.
      2. Copy the /etc/sysconfig/network-scripts/ifcfg-eth0 file to /etc/sysconfig/network-scripts/ifcfg-eth1, for example:
      [admin@zpa-connector ~]$ sudo cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1
      1. Edit the new /etc/sysconfig/network-scripts/ifcfg-eth1 file with the network configuration information required for the interface. Use an editor, such as vi.
      [admin@zpa-connector ~]$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth1

      The content within the new file should be similar to the following:

      IPADDR="104.129.193.254"
    NETMASK="255.255.254.0"
    GATEWAY=104.129.192.1
      1. To apply the changes, restart the networking subsystem using the following command:
      [admin@zpa-connector ~]$ sudo systemctl restart network
      Close

    • The proxy setting on the App Connector is used to proxy the traffic between the App Connector and the Private Service Edge. It is not used to proxy the traffic between the App Connector and internal applications.

      If your traffic is going through a proxy (i.e., traffic between the App Connector and the Public Service Edges or Private Service Edges), you must manually configure the App Connector to work through that proxy. The following procedure allows the App Connector to communicate with the broker by using CONNECT requests through a standard HTTP proxy server.

      To configure the App Connector to work through an explicit proxy:

      1. Log in to the App Connector console using your admin credentials.
      2. Create a file named /opt/zscaler/var/proxy. Use an editor, such as vi.
      [admin@zpa-connector ~]$ sudo vi /opt/zscaler/var/proxy

      Enter the proxy information using the following format: <Proxy Hostname or IP Address>:<Proxy Port> (e.g., 192.0.2.0:0).

      1. To apply the changes, restart the App Connector using the following command:
      [admin@zpa-connector ~]$ sudo systemctl restart zpa-connector

      The App Connector attempts to create a TLS session through the proxy specified in step 2.

      Close

    • By default, virtual machine-based App Connectors are configured to use DHCP networking on their primary interface. If necessary, you can configure a static IP address for the App Connector.

      Close

    • DNS resolution is critical for the successful operation of the App Connector. App Connectors use DNS to discover applications as well as enumerate each of the IP addresses that an application DNS name resolves to as a separately tracked and load balanced server. During dynamic application discovery, DNS is used as the initial reachability check from each App Connector in an App Connector group. It is possible for App Connectors to function in partitioned environments where a subset of App Connectors are able to resolve a given DNS name without additional configuration. App Connectors must also be able to resolve external DNS names, such as those of the cloud infrastructure.

      1. Log in to the App Connector console using your admin credentials.
      2. Edit the /etc/resolv.conf file. Use an editor, such as vi.
      [admin@zpa-connector ~]$sudo vi /etc/resolv.conf

      Replace the example nameserver IP addresses and search domains with your company-specific configuration, for example:

      nameserver 8.34.34.34
    nameserver 8.35.35.35 
    search myexampledomain.com
      Close

    • You cannot configure NTP servers for App Connectors running on the Amazon Web Services (AWS) or Microsoft Azure platforms.

      To configure App Connectors to use internal NTP servers:

      1. Log in to the App Connector console using your admin credentials.
      2. Edit the /etc/chrony.conf file. Use an editor, such as vi.
      [admin@zpa-connector ~]$sudo vi /etc/chrony.conf

      Add your internal NTP servers to the list, for example:

      server 0.zscaler.pool.ntp.org iburst
    server 1.zscaler.pool.ntp.org iburst
    server 2.zscaler.pool.ntp.org iburst
    server 3.zscaler.pool.ntp.org iburst
      1. To apply the changes, restart the chrony daemon using the following command:
      [admin@zpa-connector ~]$ systemctl restart chronyd
      1. To verify the NTP servers, check that NTP is working successfully using the following command:
      [admin@zpa-connector ~]$ chronyc sources
      Close

    • If an App Connector is configured to send traffic to a proxy, you can set up a proxy bypass on it for the traffic that needs to be exempted from the proxy (i.e., traffic between the App Connector and the Public Service Edges or Public Service Edges). To use a proxy bypass for an App Connector, a proxy bypass file needs to be added to the App Connector.

      To configure the App Connector to do a proxy bypass:

      1. Log in to the App Connector console using your admin credentials.
      2. Create a file named opt/zscaler/var/proxy-bypass. Use an editor, such as vi. For example:
      [admin@zpa-connector ~]$sudo vi /opt/zscaler/var/proxy-bypass
      1. Enter the necessary bypass entries using IP addresses, subnets, domains, or domains with a prefix wildcard. For example:
      1.2.3.4
    111.222.33.0/24
    myexampledomain.com
    *.internal.local
      1. To apply the changes, restart the App Connector using the following command:
      [admin@zpa-connector ~]$ sudo systemctl restart zpa-connector
      Close

    • If DHCP is not available, you can configure a static IP address on a VM-based App Connector.

      1. Log in to the App Connector console using your admin credentials.
      2. Edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file. Use an editor, such as vi.
      [admin@zpa-connector ~]$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

      If your network does not support DHCP, disable DHCP in the App Connector using the value BOOTPROTO="none". In the following example, the edited file is using an App Connector IP address of 104.129.193.254, highlighted in green:

      BOOTPROTO="none"
    IPADDR="104.129.193.254"
    NETMASK="255.255.254.0"
    GATEWAY="104.129.192.1"
      1. The /etc/sysconfig/network file requires no modifications.
      2. To apply the changes, restart the networking subsystem using the following command:
      [admin@zpa-connector ~]$ sudo systemctl restart network
      Close

    • To add static routes to the interface control files for an App Connector:

      1. Log in to the App Connector console using your admin credentials.
      2. Edit the /etc/sysconfig/network-scripts/route-eth0 file. Use an editor, such as vi.
      [admin@zpa-connector ~]$sudo vi /etc/sysconfig/network-scripts/route-eth0

      Add additional static routes using the following format: <CIDR> via <GATEWAY> dev <INTERFACE>. For example:

      192.168.0.0/16 via 192.0.2.1 dev eth0
    172.16.0.0/12 via 192.0.2.1 dev eth0
    10.0.0.0/8 via 192.0.2.2 dev eth0
      1. To apply the changes, restart the networking subsystem using the following command:
      [admin@zpa-connector ~]$ sudo systemctl restart network
      Close

    • To temporarily configure TCP communication sockets using the profs interface and the SO_KEEPALIVE socket option for an App Connector, you must:

      1. Enable Tcp Keepalive for your segment group in the Admin Portal. To learn more, see Configuring Defined Application Segments.

      The socket used for TCP communication is set to SO_KEEPALIVE and establishes an App Connector-to-Server connection. Communication using this socket looks at the system value corresponding to SO_KEEPALIVE and performs the action according to the parameters.

      1. Tune your App Connector's kernel to configure the TCP parameters and choose how the keepalive packets are sent using the following commands:
      # echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
    # echo 60 > /proc/sys/net/ipv4/tcp_keepalive_intvl
    # echo 20 > /proc/sys/net/ipv4/tcp_keepalive_probes

      Default values are used if no system parameters are chosen. The values in red represent examples of values that can be configured.

      Changes to the App Connector's kernel to configure the TCP parameters using the profs interface are temporary and return to default after reboot.

      To permanently configure TCP communication sockets using the sysctl interface:

      1. Enable TCP Keepalive for your segment group in the Admin Portal. To learn more, see Configuring Defined Application Segments.
      2. Edit your /etc/sysctl.conf using the following command:
      # vi /etc/sysctl.conf
      1. Tune your App Connector's kernel to configure the TCP parameters and choose how the keepalive packets are sent using the following commands:
      net.ipv4.tcp_keepalive_time = 60
    net.ipv4.tcp_keepalive_intvl = 10
    net.ipv4.tcp_keepalive_probes = 6

      Default values are used if no system parameters are chosen. The values in red represent examples of values that can be configured.

      1. To load the settings, enter the following command:
      # sysctl -p

      The keepalive packets have the following parameters:

      ParameterDefinitionDefault Value
      tcp_keepalive_timeThe interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the connection is marked to need keepalive, this counter is not used any further.7,200 seconds (two hours)
      tcp_keepalive_intvlThe interval between subsequent keepalive probes, regardless of what the connection has exchanged in the meantime.75 seconds
      tcp_keepalive_probesThe number of unacknowledged probes to send before considering the connection dead and notifying the application layer. The tcp_keepalive_probes value is a pure number9

      For example:

      • If the tcp_keepalive_time value is one hour, the keepalive routines wait for one hour before sending the first keepalive probe, and then resend it at a 75 second interval according to the tcp_keepalive_intvl value.
      • If the tcp_keepalive_intvl value is 60 seconds, the keepalive probes are sent every 60 seconds after the initial tcp_keepalive_time value.
      • If the tcp_keepalive_probes value is 7, and no ACK response is received after 7 consecutive times, then the connection is marked as broken.

      If there is no data communication within the tcp_keepalive_time value, it sends out a keepalive probe to the app server:

      • If ACK is returned, another keepalive probe is sent after 2 hours (tcp_keepalive_time) if no data communication happens in between.
      • If RST is returned, then the socket closes.
      • If there is no reply, it resends the keepalive every 75 seconds (tcp_keepalive_intvl) for a reply, and it retries 9 times (tcp_keepalive_probes). If there is no reply after 9 probes, the socket closes.

      To learn more about configuring a kernel, see The Linux Documentation Project's how-to article.

      Close

    • If you want to configure yum to communicate through an HTTP proxy server, refer to the CentOS and Red Hat documentation.

      Close

    • To see which TCP sessions have keepalive enabled and what their current timer is, run the ss command on the App Connector with the -t (tcp only) and -o (show timers) options:

      # ss -to
    State  Recv-Q  Send-Q  Local Address:Port  Peer Address:Port
    ESTAB  0       0       10.18.4.210:42452   10.251.33.110:https  timer:(keepalive,29sec,0)

      For sessions that have keepalive enabled, timer information (timer:(<timer_name>,<expire_time>,<retrans>)) indicates when keepalive will be sent. To learn more, refer to the Linux manual page.

      Close

  • Step 4: Verify that the deployed App Connector is running and healthy. Also, check that it is meeting your sizing requirements.

After you have verified your deployment, you can perform additional tasks to maintain the system (i.e., changing your App Connector console admin credentials or performing system software updates). To learn more, see Managing Deployed App Connectors.

After App Connectors are deployed, you can:

Related Articles
About Deploying App ConnectorsApp Connector Software by PlatformApp Connector Deployment PrerequisitesApp Connector Deployment Guide for Amazon Web ServicesApp Connector Deployment Guide for LinuxApp Connector Deployment Guide for DockerApp Connector Deployment Guide for Google Cloud PlatformApp Connector Deployment Guide for Microsoft AzureApp Connector Deployment Guide for Nutanix AHVApp Connector Deployment Guide for OpenShiftApp Connector Deployment Guide for VMware PlatformsRed Hat Enterprise Linux 9 Migration for App ConnectorsNetworking Deployed App ConnectorsConfiguring a Split DNS Zone for App ConnectorsCentOS 7 Configuration for Long-Term Zscaler Support