ZPA Part Two • App Connectors • Private Applications • Field Notes
Deploy application reachability, not another entrance into the network.
1. The question left by the previous article
This article continues Why ZPA Changes the Remote Access Model. The first article explained why users should access applications instead of networks. This one explains how ZPA reaches those applications.
The key difference was simple:
That leaves one practical question unanswered: if the user never joins the private network, how does ZPA reach the application?
The answer is the App Connector. And this is usually when the hosting or infrastructure team asks a perfectly reasonable question.
“Wait. Another VM to deploy? Wasn’t this supposed to be a cloud service?”
Fair question. ZPA is cloud-delivered, but private applications remain inside environments controlled by the customer. They may live in a physical data center, a VMware estate, Azure, AWS, Google Cloud, or a network inherited through an acquisition that everyone still calls temporary. Something must provide the Zero Trust Exchange with a secure path to those applications.
That component is not another internet-facing VPN concentrator, physical appliance or regional entrance into the network. It is a lightweight virtual component that provides application-side reachability.
Cloud does not mean topology disappears
A cloud architecture can still include a VPN Gateway, hub-and-spoke topology, VNet peering, gateway transit, route propagation and multiple network dependencies.
2. Business value: deploy reachability, not a network entrance
A cloud VPN can remove physical appliances while retaining a managed gateway, client profiles, address pools, authentication, certificates, VNets, peering, route tables, DNS and firewall policy. Cloud is an operating model. It is not an automatic simplification of every architecture deployed inside it.
The App Connector does not publish the application, accept inbound remote-user sessions, assign an internal address to the user or distribute private routes to the endpoint.
The organization is not deploying another network entrance. It is deploying controlled application reachability.
Cost, sizing and cloud egress
An Azure VPN Gateway is a managed network service. An App Connector is ZPA software running on customer-provided compute. They are different products and the ZPA subscription must be considered separately.
Sizing must begin with Zscaler’s current platform guidance. The documented baseline for virtual deployments is four CPU cores, eight gigabytes of memory and sixty-four gigabytes of thin-provisioned disk, on a processor with AES-NI enabled. At those specifications a single App Connector is rated for roughly 500 Mbps of throughput.
Requirements rise from there. Enabling AppProtection with the default profile calls for at least eight CPU cores and eight gigabytes of memory, and Zscaler advises keeping peak CPU and memory utilization below forty percent. Double encryption and ZDX also consume headroom.
Zscaler recommends more App Connectors with lower specifications rather than fewer App Connectors with higher specifications, plus room for failover on an N+1 basis.
So two connectors are a resiliency floor, not a universal sizing estimate. The required number depends on throughput, concurrent connections, application mix, health checks, ZDX, AppProtection, regions and failure domains.
Cloud egress must be included in the model. Application traffic traversing the App Connector path toward ZPA can incur internet egress, inter-zone or inter-region charges.
Compare total architecture cost, not only VM compute. Include ZPA licensing, cloud egress, storage, monitoring, availability, gateway charges, certificate management, routing effort and operational ownership.
Those constraints reveal something the shorter version of this story usually skips:
So the business advantage is not that the virtual machine is cheaper. Stated accurately, it is this:
A complete comparison must also weigh the ZPA subscription, gateway traffic and connection charges, reserved-instance or contractual discounts, the number of regions involved, required gateway capacity, certificate management, route and topology management, firewall and segmentation effort, availability requirements, operational ownership, and the additional services the same App Connector footprint can enable later.
An App Connector is not a discounted VPN Gateway. It is part of a different access architecture.
3. What an App Connector actually does
An App Connector is the private-side reachability component of ZPA. It establishes service connectivity, resolves private applications, verifies reachability and connects to an application after authorization.
It is not the policy engine. It does not independently decide whether a user is authorized. It is not the public broker, and it is not a remote-access VPN Gateway. It is the component that knows how to reach the private application.
When defining an Application Segment, administrators associate the application with the Server Groups hosting it and the App Connector Groups that can reach those servers.
A healthy App Connector status confirms that the connector can communicate with ZPA. It does not automatically prove that every private application is:
- Correctly resolved.
- Reachable from the connector.
- Listening on the configured port.
- Healthy.
- Associated with the correct Server Group.
- Authorized for the requesting user.
The App Connector is the road. It is not the person checking the guest list.
The application sees the App Connector, not the remote endpoint
In the standard user-to-application flow, the private application sees the source address of the App Connector interface that reached it, not the remote endpoint IP.
- Source-IP ACLs must be reviewed.
- Application logs can aggregate users behind a few connector addresses.
- Per-IP licensing can require validation.
- Internal geo-controls based on source IP may no longer represent user location.
- The application cannot identify the user from the source socket alone.
User identity exists in ZPA policy, session and activity logs. It does not arrive at the application as the original endpoint IP address.
Source IP Anchoring is a separate capability and should not be confused with preservation of the original user address.
Dynamic Server Discovery
Server Groups present a design choice between explicit server association and Dynamic Server Discovery.
The correct choice depends on governance, application ownership, DNS quality and frequency of change.
4. Not the same architecture with a different logo
A traditional point-to-site VPN, Azure Point-to-Site VPN and ZPA can all allow a remote user to open a private application. That is where the similarity ends.
Traditional point-to-site VPN
The endpoint establishes a tunnel toward an internet-facing firewall, appliance or VPN concentrator. The remote-access gateway terminates the tunnel, authenticates the connection and provides a routed path toward the private network.
After the tunnel is established, routing, firewall rules, access lists and network segmentation must determine what the connected endpoint can reach. The VPN does exactly what it was asked to do: it connects the user to the network.
Unfortunately, that is also where the interesting problems begin.
Azure Point-to-Site VPN
Azure Point-to-Site creates a secure connection from an individual client computer to an Azure virtual network. It removes the requirement for a customer-managed physical VPN appliance and can be provisioned and scaled as a cloud service. It still requires a route-based VPN Gateway and an appropriate combination of tunnel protocol, authentication method, VPN client and client profile.
The appliance disappeared. The gateway, client configuration and routed-connectivity model did not.
The concentrator moved to the cloud. The routing meeting followed it.
Certificate lifecycle
Azure P2S does not require certificate authentication in every design. When certificate authentication is selected, the organization must manage a compatible route-based VPN Gateway, the public key of a trusted root certificate uploaded to Azure, client certificates generated from that root, their installation on endpoints, issuance and distribution, expiration and renewal, replacement and revocation, root-certificate rotation and VPN client-profile management.
Certificates are excellent at proving identity. They are less enthusiastic about renewing themselves.
ZPA with App Connectors
ZPA does not reproduce the same architecture with a cloud logo in the middle. The endpoint does not receive routed presence inside the application network. The App Connector does not terminate a remote-user VPN. The user does not receive routes toward the surrounding private environment.
Client Connector establishes the user-side ZPA path. App Connector provides the private-side application path. The Service Edge enforces the applicable policy and manages the associated microtunnels.
ZPA still requires configuration. The difference is what that configuration constructs.
5. Who talks to whom
Central Authority
The Central Authority is the distributed control plane. It maintains configuration and policy, monitors the platform, distributes configuration and tracks application state. It is not normally in the application data path.
Public Service Edge
Public Service Edges are hosted by Zscaler and deployed in its data centers worldwide. They authenticate components, enforce policy and create, manage and terminate microtunnels.
Two properties are worth stating explicitly, because they answer the question most security teams ask first. In Private Access the Service Edge does not inspect the data flowing through it, and it never writes traffic to disk: packet data is held in memory, then forwarded or dropped according to policy. Service Edges run active-active for redundancy, and log data is compressed, tokenized and exported over TLS rather than retained in the path.
Private Service Edge
A Private Service Edge provides equivalent brokering functions in the organization’s environment. It can reduce latency, keep traffic local, support data-locality and continuity requirements, and serve on-premises users.
A Private Service Edge still registers with the Private Access Cloud and receives policy and configuration. A local data path is not automatically a fully air-gapped architecture.
Client Connector and App Connector
The client does not establish a direct routed network connection to the private application. The App Connector does not accept an inbound remote-user connection from the internet. The two sides are connected only when policy permits access to that specific application.
6. Synthetic IP: an application identity, not a network route
If the endpoint never receives a route to the private application network, what address does the operating system connect to? The answer is a Synthetic IP.
For FQDN-based private applications, Client Connector can return a Synthetic IP representing the application. The Synthetic IP is not assigned to the server, is not the server’s real address, is not announced inside the private network and is not a route to the application subnet. It is a local representation used by Client Connector to identify and intercept the application flow.
Synthetic IPs are allocated from RFC 6598 shared address space. The Client Connector default is 100.64.0.0/16, and the range is configurable anywhere between 100.64.0.0/16 and 100.127.0.0/16.
That configurability matters, because the default range collides more often than people expect. Check for overlaps with enterprise CGNAT, ISP addressing, local networks, other VPNs, SD-WAN underlays, Kubernetes overlays and developer environments. If you find a conflict, you move the synthetic range rather than renumbering the network.
The DNS-to-Synthetic-IP mechanism applies to FQDN-based flows. Application Segments defined directly by IP or CIDR do not use the same mechanism.
Two users, one application, different Synthetic IPs
A Synthetic IP is not a globally fixed DNS record for the private application. The mapping belongs to the local Client Connector and application-access context, so two users requesting the same private application can receive different Synthetic IP addresses.
Both addresses represent the same private application. The values do not need to match, because they are used locally to identify and intercept the flow. The App Connector never forwards either Synthetic IP to the application: it works with the real private FQDN, the real address and the configured port.
Synthetic IP is one of those infrastructure features users should never notice. The user enters the application name. The application opens. Nobody receives a route to the data center. Nobody asks where the real server lives. Nobody sends a thank-you email to DNS.
That is probably the highest compliment infrastructure can receive.
7. Application reachability has boundaries
Standard ZPA application access supports defined TCP and UDP flows. It is not a general-purpose Layer 3 extension.
- Broadcast and multicast are not standard application-access flows.
- ICMP is not a reliable proof of application reachability.
- Unsolicited server-to-client traffic requires separate validation or dedicated capability.
- Active FTP callbacks and dynamic secondary ports require testing.
- Legacy applications assuming network adjacency may need a different design.
Dedicated Server-to-Client and Client-to-Client capabilities exist for applicable scenarios and should not be confused with the standard user-to-application flow.
Adjacent capabilities carry their own requirements rather than inheriting the application path. ZDX, for example, needs its configured report protocols to egress the App Connector, which is a firewall conversation separate from the application ports. Assume nothing travels the connector path unless it has been designed to.
The ping false positive
A reply from a Synthetic IP does not prove the backend application is reachable. Client Connector can handle the synthetic destination locally.
Test the real application protocol. Do not declare victory because a Synthetic IP replied to ping.
8. Deploy where applications live and reuse the platform
App Connectors are commonly placed close to the applications they serve, minimizing connector-to-application latency and unnecessary network hairpinning. In some designs, however, traffic locality, Private Service Edge placement, on-premises users or regional requirements may justify placing them closer to user populations. They should be positioned according to the intended application path, not automatically wherever the old VPN concentrator happened to live.
This reduces connector-to-application latency and avoids unnecessary network hairpinning. An application in Azure can use an Azure-based Connector Group, an application in AWS an AWS-based one, and applications in physical data centers their local groups. The application does not need to be dragged back through a central VPN stack because the access architecture was designed before the application moved.
The same private-side footprint can then support a wider ZPA roadmap.
Browser Access and certificates
Browser Access can remove the endpoint-client requirement for supported web applications, which is useful for partners, suppliers, contractors and unmanaged devices. It does not remove web-server certificate lifecycle, DNS or CNAME design.
Browser Access removes the endpoint client requirement. It does not repeal certificate expiration.
PRA, third parties, AppProtection and Deception
The same application-side reachability can support contractors, privileged workflows, controlled RDP and SSH, AppProtection and the wider Zscaler Deception and containment ecosystem, depending on licensing and design.
9. A virtual appliance changes the deployment conversation
A physical VPN appliance brings procurement, shipping, rack space, cabling, power, hardware support, replacement planning and the traditional discovery that the correct transceiver was not included.
An App Connector is a virtual component deployable through:
- Cloud images.
- Virtual machine templates.
- Private-cloud images.
- Automation.
- Infrastructure as code.
- Cloud deployment pipelines.
- Supported operating-system packages.
The administrator selects an App Connector Group, creates a provisioning key and uses that bootstrap credential during deployment. The key is associated with one group and carries a configurable maximum reuse count, so it behaves like a scoped enrollment credential rather than a permanent secret.
The image itself is undemanding: four cores, eight gigabytes of memory and sixty-four gigabytes of thin-provisioned disk, on a processor with AES-NI enabled. On VMware, reserve the CPU and memory rather than letting the host allocate dynamically. What the platform does not supply is ownership: the customer remains responsible for the host on which the App Connector runs.
The organization still owns:
- Sizing.
- The virtual machine.
- The underlying operating system.
- DNS.
- Routing.
- Firewall policy.
- Application reachability.
It is still infrastructure. It just arrives without a rack-mount kit.
10. Deployment prerequisites that make or break the design
An App Connector needs two essential connectivity paths:
Nothing useful happens if either side is missing. The connector is not an internet-facing listener for remote users: its service communication is initiated from the application environment toward ZPA, which is fundamentally different from placing a VPN termination point at the internet edge.
DNS and application routing
App Connectors must resolve private FQDNs, reach real server addresses, connect to configured TCP or UDP ports and receive return traffic. DNS resolution must work from the App Connector’s own network context.
The design contains two distinct resolution contexts:
If Client Connector cannot recognize the application, the user-side flow cannot be created. If the App Connector cannot resolve the real application, the application-side flow cannot be completed.
DNS is not a minor dependency. DNS is the part everyone calls minor immediately before the troubleshooting bridge begins.
TLS inspection
App Connector service traffic toward ZPA must not be SSL-inspected. Certificate verification is deliberately not configurable, so certificate substitution does not degrade gracefully: it breaks authentication, enrollment and secure service communication outright.
Add *.prod.zpath.net to the SSL bypass list for traffic originating from the App Connector. Without it the connector cannot resolve and reach Public or Private Service Edges.
The connector needs to egress toward the configured application port on the private side, and toward the Service Edge on port 443 on the service side. If ZDX is in scope, its report protocols must also be allowed to egress the connector.
Time synchronization
Reliable NTP is mandatory. Clock skew can break certificate validation, enrollment and service authentication even when DNS and TCP connectivity appear correct.
Provisioning keys and enrollment certificates
Provisioning keys are sensitive credentials associated with an App Connector Group and have a configurable maximum usage count.
Protect provisioning keys, do not publish them in templates or logs, and disable or replace them when they are no longer required. Enrollment-certificate lifecycle and expiry must be considered separately from provisioning-key usage.
11. Connector Groups, sizing and failure domains
Connector Groups provide scale, availability, geographic placement, update scheduling and association with compatible application environments. Every App Connector belongs to exactly one group, and every group needs at least one provisioning key or enrollment token and at least one Server Group before it can serve anything.
Grouping is also what makes path selection work. Depending on the design, App Connectors can be placed closer to users or closer to applications. The Connector Group defines the set of eligible App Connectors that ZPA can use to provide the application path, based on availability, application reachability and service path selection. A group is therefore not merely a redundancy container If more capacity is required, deploy additional connectors rather than transforming one VM into a mythical creature with unlimited CPU and memory.
Two connectors on the same host, availability zone, DNS service or network path can still share one failure domain.
Where the application architecture allows it, distribute App Connectors across:
- Hypervisor hosts.
- Availability zones.
- Power domains.
- Network paths.
- DNS services.
- Cloud fault domains.
- Data centers or regions.
Redundancy is not created by drawing two connector icons. Both connectors need working DNS, routing, policy, application reachability and capacity.
12. Updates are managed, but maintenance is still real
Zscaler coordinates App Connector software updates through the App Connector Group schedule. The selected App Connector restarts, while new application access is directed toward other eligible components.
Do not assume active application sessions migrate transparently. An App Connector restart can interrupt sessions using that connector, so schedule updates as real maintenance events.
The host operating system remains the customer’s responsibility, including hardening, patching and replacement of outdated instances. This is not “nothing to manage”. It is still significantly lighter than purchasing, exposing and maintaining physical VPN appliances across multiple environments.
The practical consequence is a sizing one. A group running at its capacity ceiling has no room to lose a member to a restart, which is why N+1 is a scheduling requirement and not only an availability preference. Size the group so that it still carries the load while one connector is away, and the maintenance window stops being an event anyone has to announce.
13. Failure becomes a group problem, not a company announcement
Traditional VPN Gateways can become critical choke points. They terminate tunnels for large user populations and sit at an important network boundary. App Connector architecture is distributed.
If one connector fails:
- Other eligible connectors can serve new sessions.
- The failed virtual machine can be repaired or replaced.
- The application remains private.
- The user is not redirected directly to the backend application.
- Capacity can be expanded horizontally.
Failure of one VM should be an infrastructure event. It should not become a company-wide remote-access announcement.
That outcome depends on correct design. All connectors expected to serve the same application path need consistent:
- DNS resolution.
- Routes toward private applications.
- Application-port permissions.
- ZPA service connectivity.
- Time synchronization.
- Application health visibility.
- Available compute and memory capacity.
14. Reachability is not authorization
An App Connector may reach hundreds of private servers. That does not mean every user can access them. ZPA evaluates identity, device context, posture and policy before creating an authorized path.
This is the difference that matters, and it is a difference in starting position:
The distinction is not rhetorical. In the first model, every control is subtractive: routes exist, and firewall rules, access lists and segmentation are the effort of taking reachability away again. Anything the subtraction misses remains reachable, and nobody finds out until an audit or an incident does the finding.
In the second, reachability and authorization live at different granularities on purpose. The connector’s reachability is deliberately coarse: it can talk to a whole environment. Authorization is deliberately fine: one identity, one device posture, one application, evaluated per session. The coarse layer never becomes the user’s reachability, because the two are only joined where policy says so.
This is also where “Zero Trust” stops being a slogan and becomes something you can verify. Ask what a user reaches when policy fails to match. Under a VPN the honest answer is usually the network. Under ZPA it is nothing.
The App Connector makes the road possible. Policy decides whether the road exists for that user, device and application.
15. Operational value: complexity moves somewhere better
ZPA does not eliminate complexity. Nothing involving private applications, DNS, identity, routing and real users eliminates complexity. The advantage is that complexity moves somewhere it can be governed.
It moves from route distribution, split tunnels, VPN address pools, gateway capacity and network segmentation toward App Connector placement, Application Segments, Server Groups, application health, identity, posture and policy.
That is a healthier question. It is also much closer to the business requirement.
The responsibility boundary
| Zscaler manages | The organization manages |
|---|---|
| ZPA cloud and Public Service Edges | Application hosting environments |
| App Connector software releases | Virtual machines and host operating-system lifecycle |
| Policy distribution and enforcement | DNS, routing and application ports |
| Microtunnels and service brokering | Sizing, placement and failure-domain design |
| ZPA service telemetry | Application logs and backend health |
Reach the private application without placing the remote endpoint on the private network.
Final thought: reachable does not mean exposed
App Connectors are not flashy. They do not sit on the user desktop, terminate remote-user VPNs, publish private applications to the internet or bring users into the private network. They quietly provide ZPA with application-side reachability.
So yes, the hosting team still deploys another VM.
But that VM is easier to automate, enroll, scale and replace than a physical VPN appliance, and its value can expand into Browser Access, Privileged Remote Access, AppProtection and the wider Zscaler ecosystem.
A VPN Gateway makes a network reachable.
An App Connector makes an application reachable without making the network reachable.
That is why App Connectors are the quiet heroes of private access.
Sources and references
- Zero Trust Navigator: Why ZPA Changes the Remote Access Model
- Zscaler Help: Understanding the Private Access Architecture
- Zscaler Help: About App Connectors
- Zscaler Help: About App Connector Groups
- Zscaler Help: App Connector Deployment Prerequisites
- Zscaler Help: App Connector Deployment and Operations Guide
- Zscaler Help: App Connector Deployment Guide for Microsoft Azure
- Zscaler Help: About App Connector Provisioning Keys
- Zscaler Help: Configuring App Connector Provisioning Keys
- Zscaler Help: Understanding Service Edges
- Zscaler Help: About Private Service Edges
- Zscaler Help: Enabling Dynamic Server Discovery
- Zscaler Help: Configuring the Zscaler Client Connector Synthetic IP Range
- Zscaler Help: Step-by-Step Configuration Guide for Private Access
- Zscaler Private Access Platform Demo
- Microsoft Learn: VPN Gateway Transit
- Microsoft Learn: About Azure Point-to-Site VPN
- Figures 1 to 4: original Zero Trust Navigator diagrams.