Day 4 ZPA Bootcamp Slides - New Hire Version

Welcome To Day 4
ZPA Support/TAM Bootcamp Training 201

By: Davis Altamirano
Class Starts at 8:00 am PDT / 9:00 CDT / 11:00 am EDT
1 ©2021 Zscaler, Inc. All rights reserved. ZSCALER CONFIDENTIAL INFORMATION SECURING YOUR DIGITAL TRANSFORMATION
Components Overview (Connector/Private
Broker)
Module 4 Objectives
By the end of the module, you will be able to explain the use of connectors
and how they connect remote users to internal applications
Objectives
● Explain the role of App connectors
● Understand the main use cases for a private ZPA service edge
● Identify the main components of the mobile admin portal
CONNECTOR
CONNECTOR Supported Platforms
• List of Platforms Supported by ZPA
• Amazon Web Services (AWS)

• Centos, Oracle, and Redhat
• Microsoft Azure
• Microsoft Hyper-V
• VMware vCenter or vSphere Hypervisor (ESXi)
©2019 Zscaler, Inc. All rights reserved. ZSCALER CONFIDENTIAL INFORMATION Securing your cloud transformation
CONNECTOR PreRequisites
• App Connector Specifications and Sizing Requirements
• 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 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
• To deploy an App Connector on Azure, Zscaler recommends using Standard_F4s_v2 or
Standard_D4s_v3
• Disk Space
• 16 GB (thin provisioned) for the deployments in Microsoft Azure and AWS
• Network Card: 1 NIC (minimum)
• App Connector Platform 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 ZPA Admin Portal
• A static MAC address
• App Connector Security Guidance and Firewall Requirements
• 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 ZPA Public Service Edges
CONNECTOR ENROLMENT
CONNECTOR ENROLMENT
The Below File show how the connector enrolment works along with the upgrade path. Here is a
snippet
Oct 18 15:37:32 localhost zpa-connector-child[3432]: Enroll: Connecting to api.private.zscaler.com

via co2br.prod.zpath.net.
Oct 18 15:37:36 localhost zpa-connector-child[3432]: Connector has been successfully enrolled
Oct 18 15:37:36 localhost zpa-connector-child[3432]: Initializing assistant: 216196799570903075,
customer_id: 216196799570903040 belonging to customer domain: 216196799570903040.zpa-
customer.com
Oct 18 15:37:36 localhost zpa-connector-child[3432]: Assistant capability check passed
Oct 18 15:37:36 localhost zpa-connector-child[3432]: Waiting for connector to retrieve configuration
Oct 18 15:37:39 localhost zpa-connector-child[3432]: Log(event_log) successfully connected to
Zscaler Cloud: [10.20.30.141]:37158;broker4b.bom5.prod.zpath.net:[13.127.99.160]:443;4
How Connectors Contact Brokers
ZPA Connectors create two main types of connections to Brokers. Both of these are outbound
from the connector to the broker.
● Control connections are how the connector receives commands and sends telemetry to
the ZPA cloud. Every connector will establish exactly one control connection to one broker
at startup.
● Data connections allow connectors to serve internal application data to end users. Every
connector can establish multiple data connections to whichever brokers need them. A
connector will often end up establishing two connections to the same broker: one control,
one data.
Connector Control Connections
● On startup, connectors will contact the co2br subdomain for their cloud. (The production
cloud has the domain prod.zpath.net, meaning that the full domain for this example is
co2br.prod.zpath.net.)
● co2br is shorthand for "Connector to Broker". This subdomain helps Connectors find the
optimal Broker for its control connection.
● In commercial production environments, the co2br subdomain is served by Amazon AWS

GSLB. GSLB is a geographically-aware DNS resolution service.
● Control connections are only used for command and control traffic like:
● health reporting
● mtunnel requests
● restart commands
● application updates, and similar behaviour
● Control connections are not used by actual application traffic via ZCC or Browser Access.
Effects of High Control Connection Latency
● High latency or loss for Connector control connections may have the following effects:
● The connector may have a hard time sending accurate health data to the ZPA cloud. This
may sometimes prevent the connector from being selected by ZPA.
● If health checks are enabled, ZPA will attempt to route users through the first and closest
connector which can respond to an initial health probe. Control connection delay would
mean that other connectors can win that race.
● News of new applications, or updates to existing applications, may take a comparatively
long time to reach the affected connectors.
● The ZPA cloud uses control connections to command a connector to create a new
mtunnel. Initial mtunnel establishment may be delayed. Once that mtunnel is established,
data transfer rates between user and application will not be affected by the control
connection.
● When a connector needs to download a software update, it contacts our CDN at
dist.private.zscaler.com. This contact is established by proxying through whichever broker
holds its control connection. High latency (or loss) to the broker at co2br.prod.zpath.net
could prevent a connector from downloading updates.
13
● Control connections do not affect the data transfer rates of established mtunnels. The data
©2021 Zscaler, Inc. All rights reserved. ZSCALER CONFIDENTIAL INFORMATION SECURING YOUR DIGITAL TRANSFORMATION
connection, not the control connection, carries the established mtunnel.

Connector Data Connections
● Each Connector will typically establish a data connection to a Broker only when:
● A user belonging to that customer is on the Broker,
● The user has requested an internal application available to that Connector, and
● The ZPA Dispatcher has selected that Connector to serve the application.
● Once the Connector has one data connection established to a Broker, it will recycle that
existing connection for any mtunnels that require it.
● All ZPA components establish TLS tunnels to communicate with other components. A
Connector's data connection is one such TLS tunnel.
● Within that data connection, the Connector uses TLS tags to manage multiple mtunnels to
internal applications.
● This is why ZPA's mtunnels, or microtunnels, are called microtunnels: they are small tunnels
within the main TLS tunnel.
Effects of High Data Connection Latency
● Data connections carry user traffic to internal applications.
● If a Connector's data connection has high latency or loss to a given Broker, then it will affect
the users who:
● Have client connections to that specific Broker, and are accessing internal applications
through that specific Connector.
● A Connector may deliver optimal performance to multiple users, but degraded performance
to users at a specific location. This may be because the Connector is having trouble with its
data connections to that specific location.
ZPA - PRIVATE SERVICE EDGE
(Private Brokers)
Understanding the Private Service Edge
• Private Service Edge is intended to function as a preferred local path for ZPA.
• If a user cannot establish a connection to a Private Edge, then the client will fail over to a Public
Edge instead.
• If a user is connected to a Private Edge, but the internal application isn't available locally, then the
Private Edge will hand the application request upstream to a Public Edge for fulfillment.
• Let's say a customer has used the ZPA Admin UI to create a new Private Service Edge group and
provisioning key. The provisioning key has been copied to the Private Edge virtual machine, and the
Private Edge has completed enrollment. The newly-enrolled Private Edge service is starting.
ZPA Service Edge (Private Broker) Introduction
• All the same functionality offered by Zscaler Enforcement Nodes deployed closest to the user in
customers’ DC/premise
• Monitored, managed, maintained by Zscaler as an extension of the Zscaler Cloud Enforcement
plane in customer’s premise
• Consistent Policy follows the user – no separate configuration required
• The ZPA – Pbs, can be divided into 3 parts based on the Trusted Network Conditions setup.
● 2 pvt pvt brokers
2 pub pvt brokers
2 public Brokers
● MTN present and Public access disabled,
● only the pvt pvt boxes are offered
● MTN Present and Public access enabled
2 pvt pvt brokers are offered
2 pub pvt brokers are offered
● MTN Disabled and Public access disabled
we do not offer any brokers.
only public brokers are offered
● MTN is disabled and Pub access enabled
18
Pub Pvt brokers based on geo proximity
©2021 Zscaler, Inc. All rights reserved. ZSCALER CONFIDENTIAL INFORMATION SECURING YOUR DIGITAL TRANSFORMATION
Mobile Portal
Posture Profile
Using the posture profile...
• Use of posture profiles to determine the various options based on the OS.
• Based on the posture profiles, we can create policies to allow or block the access to applications.
Lab Exercise #14
Setup Posture Profiles
• If ZPA Posture Profile is already setup on your Mobile portal tenants, review the settings
• If ZPA Posture Profile is not setup already on your Mobile Portal then, proceed with the setup of
the same
• Configure Posture Profile and make sure the Profiles are showing up in the portal.
• Check if the Posture Profile validation is seen in the ZSATunnel Logs.
• Setup Access Policies based on the validation of Device Postures, and make sure they are
working as expected.
Help Portal Link : https://help.zscaler.com/z-app/configuring-device-posture-profiles-zpa
Multi-Trusted Network Profiles
Using the MTN profile...
• Use of multi- trusted network profiles to determine the type of network based on the various
options present.
• Based on the multi-trusted network profiles, we can create policies for selecting PSE, selecting
CFP etc.
Lab Exercise #15
Setup Multi-Trusted Network Profiles
• If Multi Trusted Networks is already setup on your Mobile Portal tenants, review the settings
• If Multi Trusted Networks is not setup on your Mobile Portals already then, proceed with the setup
of the same
• Configure the multi-trusted network and associate them with a forwarding Profile.
• Check if the ZCC is able to move to the configured Trusted Network condition once it is
satisfied.
• Look at the ZSATunnel logs to check if the condition matching is the correct one.
Help Portal Link :

https://help.zscaler.com/zpa/trusted-network-use-cases
https://help.zscaler.com/z-app/configuring-trusted-networks-zscaler-app
Thank You
For Attending
Day 4

Day 4 ZPA Bootcamp Slides - New Hire Version

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Day 4 ZPA Bootcamp Slides - New Hire Version

Uploaded by

Copyright:

Available Formats

Welcome To Day 4

ZPA Support/TAM Bootcamp Training 201

• List of Platforms Supported by ZPA

• Amazon Web Services (AWS)

• App Connector Platform Prerequisites

• Intel x86_64/AMD64 based architecture

• It is possible to deploy an App Connector in such an environment as long as the App

Oct 18 15:37:32 localhost zpa-connector-child[3432]: Enroll: Connecting to api.private.zscaler.com

● In commercial production environments, the co2br subdomain is served by Amazon AWS

connection, not the control connection, carries the established mtunnel.

● Data connections carry user traffic to internal applications.

Help Portal Link : https://help.zscaler.com/z-app/configuring-device-posture-profiles-zpa

Help Portal Link :

You might also like