ZPA App Connector Deployment — Deploy, Enrol & Survive the Auto-Update

① The App Connector, sized and placed right

An App Connector is not a firewall, not a VPN concentrator, not a server you publish. It is a small Linux VM whose only job is to sit next to your apps, dial out to the Zscaler cloud, and proxy authorised sessions back to the real server. Get its size, its OS, and — the one everyone misses — its MAC address right, and the rest of this lesson is plumbing. Get them wrong and you will chase a ghost for a day.

The minimum spec is deliberately tiny: 2 vCPU, 4 GB RAM, 8 GB disk, on a supported 64-bit Linux — RHEL, CentOS, Oracle Linux or a Zscaler-provided OVA. Each connector pushes roughly 0.3 to 0.5 Gbps, so you scale by adding VMs, not by buying a bigger box. But the spec line that bites freshers is not CPU — it is identity: a pinned static MAC.

Placement is the other half of sizing. A connector goes near the app, not near the user. ZPA does latency-based selection — it routes a user to whichever connector in the group can reach the app fastest — so a connector sitting in the same data centre as your SAP box is what makes the session quick. Put one in every site/VPC that hosts apps; do not centralise them.

Four deployment facts to lock in first

Tap each card — front is the fact most freshers get wrong, back is the correction you will need all lesson.

② Egress rules: what the firewall team needs to open (and what they must NOT)

This is the section that turns a two-week ticket into a ten-minute one. When the firewall team asks "what do we open for this Zscaler thing?", the honest, complete answer is short — and the most important part is what you tell them not to do.

• Outbound TCP 443 and UDP 443 to *.prod.zpath.net and *.zscaler.net — the Z-Tunnel (TLS, plus DTLS on UDP).
• Outbound UDP 123 (NTP) — the connector must hold accurate time or the short-lived enrolment certificate is rejected.
• Outbound DNS (UDP/TCP 53) to a resolver that can resolve the Zscaler cloud and your internal app FQDNs.
• Zero inbound. No NAT, no public IP, no DMZ. The connector is never a destination.

③ The provisioning key — a secret you can corrupt with a curly quote

A provisioning key is what turns a blank Linux VM into your enrolled connector. It is an OAuth enrolment token, and three facts about it decide whether enrolment works:

• It is bound to exactly one App Connector Group. A key minted for "Mumbai-DC-Group" can never enrol a connector into "Chennai-DC-Group".
• It has a Max Usage count — how many connectors it may enrol before it stops. Set it to the number of connectors you are deploying into that group.
• It is a secret. Anyone with the key can stand up a connector inside your trust boundary, so store it like a service-account password — never in clear text, never in a wiki.

You generate it in the portal, then drop it onto the VM at /opt/zscaler/var/provision_key. Two operational gotchas trip almost everyone the first time:

Here is the real Add Provisioning Key form — recreated so you recognise the actual screen and the fields that matter.

sudo systemctl stop zpa-connector
# paste the key into a PLAIN editor first (no smart quotes), then:
sudo install -o zscaler -g zscaler -m 600 provision_key.txt /opt/zscaler/var/provision_key
sudo systemctl start zpa-connector
sudo systemctl status zpa-connector --no-pager

● zpa-connector.service - Zscaler App Connector
     Active: active (running) since Wed 2026-06-03 09:14:02 IST
     Status: "Connected to broker bom2-vse-01, tunnel UP"

④ Enrolment & the mTLS handshake — why NTP skew = "Disconnected forever"

When you start the service with a valid key, the connector enrols: it presents the key, the ZPA cloud validates it, and the two sides complete a mutual TLS handshake. The cloud issues the connector a short-lived, timestamp-validated certificate, and from then on the connector holds an outbound Z-Tunnel to the broker.

That word timestamp-validated is the whole section. The certificate carries "not-before" and "not-after" times. If the connector's clock is wrong — even by a few minutes — it can present or validate a cert whose window has not opened yet, and the handshake fails with certificate is not yet valid. The connector then shows Disconnected and, because it never gets time-synced on its own, it stays that way forever. This is why UDP 123 (NTP) is not optional.

⑤ High availability — why one connector is an outage waiting for its own upgrade

Connectors auto-update on a schedule you set per group. That is good — patched agents, no manual work. But an update restarts the connector, and during that restart it cannot proxy traffic. With a single connector, your "maintenance window" is every time Zscaler ships an update, whether you planned it or not.

The fix is built into the product: deploy at least two connectors per App Connector Group. ZPA staggers their auto-updates in a round-robin — it upgrades one while the other keeps serving, then swaps. Two connectors means the group is always up; one connector means the group goes dark every upgrade.

Here is the real App Connectors health view — the screen where you confirm a group has its HA pair Connected before you trust it in production.

⑥ Operate it: CLI, SSL-bypass discipline, and patching (the real CVE)

A deployed connector is a Linux service you operate like any other — three commands cover almost every day-2 task. Memorise these; they answer "is it up, why not, and what does it see?"

sudo systemctl status zpa-connector          # is the service up?
sudo journalctl -u zpa-connector -n 50       # why did it fail / flap?
sudo zpa-connector troubleshoot connection   # can it reach the broker + the app?

[broker]   tunnel: UP   (edge: bom2-vse-01)   latency: 12ms
[time]     System clock synchronized: yes
[app]      10.20.4.30:443  reachable

If the tunnel is UP but the app line is unreachable, the problem is connector-to-app routing — not ZPA. If time is not synchronized, fix NTP before anything else.

Patch the agent — the client is the enforcement point