ZPA architecture vs VPN — broker one app, not a network

1. Why this replaces VPN

ZIA is egress: the user reaches the internet and a Public Service Edge inspects the session. ZPA is the opposite problem. The destination is your Jira, file server, or RDP host in a DC or VPC. The user should reach that one thing and nothing else.

A VPN concentrator solves that by becoming an inbound door. After auth, the laptop usually receives a route into a private subnet. Policy is then a pile of ACLs on that network. One concentrator CVE, one fat-fingered ACL, or one compromised laptop, and the attacker has a place to stand.

ZPA removes the door. The App Connector never listens. The private app has no NAT. The user never receives the subnet. The only path is a brokered microtunnel for the Application Segment the Access Policy allowed.

Hero · who talks to whom

2. Mental model — four parts, one broker

Memorise four named objects. Every ticket, every diagram, every “why is Jira dark” call maps back to these.

Hard words before the runbook

3. Packet path — the microtunnel

Do not start the whiteboard with menus. Start with the click. The two TLS sessions to the Service Edge are usually already up before the user opens Jira. The click is what asks the broker to stitch a stream.

Path · request → policy → stitch → app

On a managed laptop the usual hop list is:

1. The user opens https://jira.lab.example. Client Connector already holds an outbound session to a nearby ZPA Public Service Edge (or your Private Service Edge).
2. Client Connector matches the FQDN to an Application Segment the user is entitled to resolve, and hands the process a synthetic IP (CGNAT-space, not the real server address).
3. The SYN rides the existing Client Connector leg to the Service Edge. It does not hairpin through the corporate LAN.
4. The Service Edge evaluates Access Policy against the user, groups, posture (if you use it), and the Application Segment / Segment Group. No match → deny. That is the designed default.
5. On allow, ZPA selects a healthy App Connector from the App Connector Group bound through the Server Group, and signals that connector over its already-up outbound session.
6. The App Connector opens a normal local connection to Jira (internal DNS, internal IP). The Service Edge stitches the two streams into one microtunnel. Jira sees the connector’s source IP, not the user’s home IP.

4. How to choose — VPN vs ZPA vs clientless

Use this table in the design review and on the Monday ticket. The wrong tool is usually “we kept thinking in subnets.”

Client Connector vs Browser Access

Zscaler Client Connector is the default for employees. It intercepts the Application Segment (FQDN or IP), can carry more than HTTPS, and can feed device posture into Access Policy.

Browser Access is the official clientless path: the user authenticates in a browser and reaches a Browser Access–enabled web application over ZPA without installing Client Connector. The App Connector still has to resolve and reach the internal host — usually via internal DNS. If the connector uses public DNS for that name, you can loop or miss the app entirely.

Same Access Policy idea either way: define the users, then define which applications or Segment Groups they can access. Clientless is not a back door around default-deny.

5. Runbook Side A → B → C

Goal for a lab Jira that only Finance may reach: the object exists, two App Connectors in the same DC can reach it, and an Access Policy allow is the only reason the stitch happens.

Primary sources: Zscaler Help — Understanding the Private Access Architecture; About App Connectors; Configuring Access Policies; Configuring Defined Application Segments.

Side A — Define the application

1. Name the real destination

   Write the FQDN users type, the TCP/UDP ports, and the internal server (IP or hostname the App Connector can resolve). Lab: jira.lab.example, TCP 443, server 10.40.12.20. If DBAs bookmark the raw IP, that IP must be on the segment too — Client Connector’s FQDN intercept will not see https://10.40.12.20.

2. Create the Application Segment

   ZPA Admin → Resource Management → Application Management → Application Segments → Defined Application Segments → Add. Name Jira-Lab, status Enabled, domain jira.lab.example, TCP port 443. Place it in a Segment Group (example Corp-Private) so Access Policy can allow the group, not one hostname at a time.

3. Bind a Server Group + health

   On the same object, associate a Server Group that points at the App Connector Group that can actually route to 10.40.12.20. Turn health reporting on so a dead Jira is not advertised as healthy. If this is a web-only contractor app, enable Browser Access here — not as a second mystery product later.

Side B — App Connector next to the app

1. Create the App Connector Group first

   Configuration & Control → Private Infrastructure → App Connector Management → App Connector Groups. Name DC1-Connectors. This group is the failure domain (one DC, one VPC, one AZ pair) — not “one group per app.” Attach the group to the Server Group from Side A.

2. Issue a provisioning key and deploy two VMs

   Generate a provisioning key bound to DC1-Connectors. Bootstrap two App Connector images (OVA / marketplace image / supported Linux package — follow the current platform guide). The VMs need outbound TLS to ZPA Public Service Edges or to your Private Service Edges. They do not need inbound firewall holes. Deploy two. One VM is a single point of failure.

3. Prove the connector can reach the app

   Portal status Active only proves the VM reached ZPA. From the connector itself, resolve and connect to jira.lab.example:443 (or 10.40.12.20:443). If that local dial fails, every user will fail even though the connector is green. That is the classic “no healthy connector” after a clean registration.

Side C — Access Policy (the actual allow)

1. Remember the default

   Official Access Policy behaviour: ZPA blocks access to applications and Segment Groups until you write a rule that explicitly allows. Creating Jira-Lab and turning it Enabled does not entitle Finance.

2. Add the allow

   Policy → Access Policy → Add Rule (wording may appear under Policies → Access Control). Criteria: users or groups first (SCIM group Finance), then applications or Segment Group Corp-Private. Action Allow. If you use posture, require the managed Client Connector posture profile. Optionally pin the rule to DC1-Connectors so a stray group cannot serve this app.

3. Pilot one user, then open the group

   Assign one Finance pilot. From Client Connector, confirm ZPA is authenticated. Open https://jira.lab.example. In ZPA Diagnostics / user trace, you want: SAML (or IdP) success, Access Policy rule name, selected App Connector, successful local dial, bytes. Then widen the group. Contractors without ZCC get a separate Browser Access–enabled segment plus their own allow — not a public VIP.

6. Runtime path after go-live

Once Side A/B/C is saved, the live path is short. Use it as the first five minutes of every Sev-2.

1. Is Client Connector (or Browser Access) actually in a ZPA session? If ZCC ZPA is disconnected, you are not in this product yet.
2. Did the request match an Application Segment? FQDN intercept vs raw IP. Clientless only matches Browser Access–enabled apps.
3. Which Access Policy rule hit? No rule → default deny. Wrong group or missing SCIM group → looks like “ZPA is broken.”
4. Which App Connector was chosen, and is it healthy for this app? VM Active ≠ app health. Policy can also pin a group that has nobody live.
5. Did the connector dial the real server? Local DNS, security group, and route on the connector subnet. Jira sees the connector IP.

user:            finance.pilot@lab.example
client:          Zscaler Client Connector · ZPA authenticated
application:     jira.lab.example:443  (Application Segment Jira-Lab)
policy:          Finance-Jira-Allow · action Allow
connector_group: DC1-Connectors
connector:       connector-02 · Active · health for Jira-Lab = Up
app_dial:        10.40.12.20:443  connect=ok  bytes>0
public_check:    jira.lab.example NXDOMAIN from internet

7. Traps + proof

Proof · close the ticket with a named field

Sources

• Zscaler Help — Understanding the Private Access Architecture (Client Connector, App Connector, Public Service Edge, microtunnel)
• Zscaler Help — About App Connectors (outbound-only interface to the ZPA cloud)
• Zscaler Help — Understanding Service Edges (Public vs Private Service Edge role)
• Zscaler Help — Understanding the ZPA Cloud Architecture (Service Edges stitch Client Connector and App Connector; connectors never accept inbound)
• Zscaler Help — Configuring Access Policies (default block until an allow exists)
• Zscaler Help — About Access Policy (define users, then applications or Segment Groups)
• Zscaler Help — Configuring Defined Application Segments (Resource Management → Application Management → Application Segments)
• Zscaler Help — About App Connector Groups (Configuration & Control → Private Infrastructure → App Connector Management)
• Zscaler Help — About Browser Access (clientless web access without Client Connector)
• Zscaler Help — Understanding Health Reporting
• Zscaler Help — Access Policy Deployment and Operations Guide (“No App Connector Available”)
• Zscaler reference architecture — Universal ZTNA with ZPA Private Service Edge (PDF)

Related: Lesson 10 · App Connectors · Lesson 11 · ZPA policies · ZPA troubleshooting · Zscaler authentication · Exchange factory