Zscaler Private Access (ZPA): application access and segmentation
Brokering instead of exposing
ZPA replaces inbound VPN access with an outbound-only model. The App Connector, deployed close to the applications, opens outbound connections to the Zscaler cloud (public service edges, or private service edges you host). Nothing listens on the internet-facing perimeter. Users' Client Connectors reach the nearest service edge, authenticate through the identity provider via SAML, and are authorized per application.
The object model you must know
- App Segment - the definition of an application (domain, IP, ports, protocol); the unit of access.
- Segment Group and Server Group - logical grouping of segments and of connectors.
- App Connector Group - the connectors serving that server group.
- Access Policy - ordered allow/deny rules using user, group, SAML attributes, device posture, client type, and location.
Matching is by domain, port, and protocol, so a wrong port or a missing wildcard is a classic cause of 'app unreachable.'
Why segmentation matters
Because access is granted per app segment, a compromised session cannot scan the data-center subnet. Microtunnels mean the client never receives a network-level route into the LAN.
Traps
- Thinking App Connectors need inbound firewall holes - they do not.
- Assuming ZPA inspects content; it brokers. Content controls belong to ZIA.
- Forgetting that a deny rule placed above an allow rule wins.
- Confusing Browser Access (clientless) with Client Connector access when a posture check is required.
Worked example
One app in a server group works and a second does not. Verify the second app segment's domain and port exactly match what the client requests (including wildcards), that the segment belongs to a segment group bound to that connector group, and that no broader deny rule ranks above the allow.