Prisma Access
ZTNA Connector Requirements and Guidelines
Table of Contents
ZTNA Connector Requirements and Guidelines
Learn about the requirements and guidelines for using ZTNA Connector.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
|
Before you configure ZTNA Connector, be sure that you understand the Connector
requirements and limits, as well as the guidelines you should follow when deploying
it.
Scale and Throughput Considerations
| Connector and Application Metrics | Maximum Value |
|---|---|
| Bandwidth per Connector | Up to 2 Gbps* |
| Bandwidth per Connector Group (with 4 Connectors) | 6 Gbps* |
| Applications per tenant across all Connector Groups |
20,000
|
| Applications per Connector Group | 1000 |
| Connectors per tenant | 200 |
| Connector per Connector Group | 4 |
| Concurrent sessions per Connector | 100,000 Each Connector can support
100,000 concurrent connections. A Connector Group can have a
maximum of 4 connectors for up to 400,000 concurrent
connections per Connector Group. |
| Concurrent sessions per Connector Group | 400,000 |
| Maximum IP subnets per tenant | 1024 |
*Performance metrics are based on the internal testing. The observed
performance might vary and is dependent on the traffic type, customer-specific
equipment, ISP performance, and environmental network factors that are external
to the Prisma Access service.
ZTNA Connector Deployment Design
Review these architecture and design considerations to optimize your ZTNA
Connector group placement within your data center before selecting a deployment
platform:
- Connector Group Guidelines—When adding Connector Groups, use the
following recommendations:
- Deploy at least 2 Connectors in a single Connector Group for redundancy.
- Co-locate all the Connectors in a single Connector Group in the same data center.
- Co-locate all the Connectors in in a single Connector Group in the same subnet with equal access to application servers for consistent performance.
- Prisma Access automatically selects a Connector Group's region when you deploy the first ZTNA Connector in that group. The geolocation of the ZTNA Connector's NAT gateway to the public internet determines the assigned region. All connectors in a Connector Group establish IPsec tunnels with Prisma Access ZTTs in the region; therefore, do not deploy connectors within a single Connector Group across multiple regions.
- Server-initiated traffic establishes server-to-client flows; for optimal organization and management. Palo Alto Networks recommends that the client-initiated flows and server-initiated traffic flows should be configured in separate ZTNA Connector Groups.
- Each Connector Group must contain unique Connector types. Prisma® Access doesn’t support mixing NGFW Connectors and ZTNA Connectors in a single Connector Group.
Supported Application Hosting Platform
You can deploy your ZTNA Connector VMs in the following data center environments
with the specified minimum requirements:
| Cloud Provider | Recommended Cloud Instance Size | CPU Size | Memory Size | Disk Size |
|---|---|---|---|---|
| Amazon AWS | m5.xlarge per region | 4 vCPUs | 16 GB | 40 GB |
| Google Cloud Platform (GCP) | n2-standard-4 per region | 4 vCPUs | 16 GB | 40 GB |
| Microsoft Azure | Standard_D4_v3 per region | 4 vCPUs | 16 GB | 40 GB |
| Oracle Cloud Infrastructure (OCI) | VM.Standard.E5.Flex | 2 OCPUs (4 vCPUs) | 16 GB | |
| KVM | Uses qcow image | 4 vCPUs | 16 GB | 40 GB |
| Hyper-V | Uses vhd image | 4 vCPUs | 8 GB memory per VM | 40 GB |
| VMware ESXi | Uses OVA image. Supported on vSphere and directly on ESXi Hosts | 4 vCPUs per VM | 8 GB memory per VM | 40 GB disk (Thick Provisioned) |
|
For VMware ESXi, vMotion, VM snapshots, or migrations are not
supported for Connector VMs.
For KVM, Live Migrations and snapshots are not supported on
Connector VMs.
| ||||
It's your responsibility to host the VMs and ensure that
they can connect to the internet.
AWS, Azure, GCP and OCI have ZTNA Connectors you can acquire in their respective
Marketplaces. You can download the VMware ESXi Open Virtualization Application
(OVA) file, the KVM qcow file and the Hyper-V vhd file from the Palo Alto
Customer Support Portal.
Network Topologies
ZTNA Connector have to make connections to:
- Internet: HTTPS to cloud controller, IPSec connections to ZTTs, time sync with NTP servers, and DNS resolution with public DNS servers.
- Data Center: Private DNS servers for DNS resolution, application
probing of data center application servers, and user sessions to data
center app servers.
![]()
One-Arm Connector (1-interface): For one-arm, you have just one interface
so the security policy on the interface must permit both internet and data
center access.
- Interface: Port 1 only.
- Function: A single interface handles control connection, the ZTT
tunnel, DNS queries (public or private DNS), and application
traffic.
![]()
Two-Arm Connector (2-interfaces): For two-arm, you have 2 separate
internet and data center interfaces that can specific security policies based on
access to internet and data center separately.
- Port 1 (WAN): Access to public internet and private DNS (if the private DNS server is reachable on Port 1).
- Port 2 (LAN): Access to internal Data Center DNS and Application
servers.
![]()
The IP subnets where the ZTNA Connector interfaces are deployed
must not conflict with:
- ZTNA Connector Application IP Blocks: The subnets where your target applications reside.
- Connector IP Blocks: The internal IP pools assigned within Prisma Access for connector-to-service routing.
DNS Server Infrastructure
ZTNA Connector requires specific DNS
capabilities to function. After you enable ZTNA Connector Prisma Access
sets up a DNS proxy for DNS requests
using the DNS rules set up for Remote Networks and Mobile Users—GlobalProtect.
You must configure DNS
servers such that:- Public Resolution: At least one DNS server must resolve public FQDNs (e.g., locator.cgnx.net) to establish the control connection to Prisma Access Cloud Controllers.
- Private Resolution: At least one DNS server must resolve your internal private application FQDNs.
- Parallel Query Mechanism: ZTNA Connector queries all configured DNS servers in parallel for every request (both public and private). The first successful response received is the one used.
- Make sure you have configured DNS entries on the local interfaces to allow ZTNA Connector to resolve the app FQDNs, and that ZTNA Connector and access the DNS server at UDP port 53 (the port used for DNS resolution).
- (Mobile Users—GlobalProtect deployments only) When you first onboard an application in ZTNA Connector, you must refresh the GlobalProtect app so mobile users receive the updated DNS proxy resolution. If you removed an application from ZTNA Connector, you must refresh the GlobalProtect app so mobile users can receive the updated DNS proxy resolution.
- CNAME and Load Balancing: If a private application FQDN resolves via CNAME to multiple IPv4 A records, ZTNA Connector will automatically load balance traffic across those IP addresses—provided they are successfully passed by the Application Probe (health check).
- If you need to restrict the list of IP addresses and FQDNs that you add to your organization's allow lists, add the ones listed in IP Addresses and FQDNs to Allow for ZTNA Connector.
Security Policy: Local Firewall (On-Prem/IaaS)
Configure your firewalls to permit the following flows based on your
selected topology.
Public Internet Access (Port 1)
| Rule Name | Source IP Address | Destination | Protocol/Port | Action | Note |
|---|---|---|---|---|---|
| Cloud Controller | Connector Port 1 | *.cgnx.net | TCP 443 | Allow | Disable SSL Decryption |
| ZTT IPSec ф | Connector Port 1 | Prisma Access Service IPs | UDP 500, 4500 | Allow | IKE and NAT-T |
| ZTT-NTP | Connector Port 1 | time.nist.gov, pool.ntp.org | UDP 123 | Allow | Time synchronization |
| ZTT-Public-DNS | Connector Port 1 | Public DNS (example 8.8.8.8) | UDP and TCP 53 | Allow | Public FQDN resolution |
| Diagnostics | Connector LAN IP | ping ZTT, traceroute to ZTT, ping app server, traceroute to app server, tcpping controller endpoint | ICMP, UDP and TCP | Allow | For ping, tccping, nslookup or traceroute tools |
ф If ZTNA Connector uses a public IP address for its internet interface,
you must allow a IP/50 Encapsulating Security Payload (ESP).
The Connector to controller connection uses certificates for authentication and
therefore SSL decryption must be disabled.
Data Center Access (Port 1 for 1-Arm; Port 2 for 2-Arm)
| Rule Name | Source IP Address | Destination | Protocol/Port | Action | Note |
|---|---|---|---|---|---|
| Internal-DNS | Connector LAN IP | Internal DNS Servers | UDP and TCP/53 | Allow | App FQDN resolution |
| App-Probing | Connector LAN IP | Internal Application Servers | App Specific Protocols or Ports | Allow | TCP Ping health check |
| User-Access | Connector LAN IP | Internal Application Servers | App Specific Ports | Allow | Production user traffic |
| Diagnostics | Connector LAN IP | tcpping app server, ping app server, traceroute to app server, ping DNS, traceroute to DNS | ICMP, UDP and TCP | Allow | For ping, tccping, nslookup or traceroute tools |
The following requirements enable connectivity between ZTNA Connector and Prisma Access:
- If there is a firewall between the ZTNA Connector and the private app,
the firewall must allow access to the app from the ZTNA Connector (that
is, you must allow access to the app server's resolved IP addresses,
protocols, and ports for the private app). In addition, you need to allow the protocol (either TCP or ICMP) that you configured for the application target health probes to the app. The connector application probes the app server to determine if it can provide access to the app, and you can configure the Probing Type for the Application Target to be tcp ping, icmp ping, or none (no probing). If you specify tcp ping, the firewall must allow TCP access to the app for a TCP 3-way handshake; if you specify icmp ping, the firewall must allow ICMP echo request and reply for the app.
- Be sure that you allow ICMP in your data center before using the ping and traceroute diagnostic tools (ping uses
ICMP and traceroute uses UDP ports). Some cloud environments have ICMP
disallowed for security concerns; in this case, these tools don't
display any activity.The traceroute diagnostic tool also uses random UDP ports, so you must allow all UDP and ICMP error replies for the traceroute tool to function.
- Make sure that you have configured security rules in your network to permit ZTNA Connectors to perform application probes into your data center. ZTNA Connectors use their data center interface IP address as the source IP address of the application probing to the application servers. If the application probing is successful, the Application Status is Up and user sessions to ZTNA Connector have the same data center interface IP address as the source IP address. If the application probing is unsuccessful, the Application Status is Down; in this case, you can use the ping and tcp ping diagnostic tools to test connections to the application. ZTNA Connector must have an IPSec tunnel Up or all the Application Status are Down.
Security Policy: Prisma Access (Cloud)
Once the tunnel is Up, you must authorize user traffic within the Prisma Access (Managed by Strata Cloud Manager) or Prisma Access (Managed by Panorama) security policy. Without these rules,
the "Zero Trust" default-deny policy will block all user sessions.
Authorizing ZTNA Connector App Traffic
You must create Mobile User or Remote Network security rules that allow traffic
from your users to the specific ZTNA targets.
| Rule Element | Requirement / Best Practice |
|---|---|
| Source Zone | Typically your "Untrust" or "Mobile User" zone. |
| Destination Zone | The zone associated with your ZTNA Connector Group. |
| Destination Address | Must match the FQDN Targets (for example, crm.internal.local) or IP Subnets defined in your ZTNA Application settings. |
| Service | Limit to the specific application ports (for example, service-http, SSH). |
| Security Profiles | Apply Threat Prevention, URL Filtering, and File Blocking to inspect the traffic decrypted at the Prisma Access cloud. |
If you defined your application using a wildcard FQDN
(for example, *.corp.local), ensure your Security Policy destination address
object matches that wildcard or includes the specific subnets the wildcard
resolves to.
Additional Considerations
Review these additional requirements and operational constraints to ensure your
ZTNA Connector deployment functions correctly within your environment.
- GlobalProtect Clientless VPN.
- MTU Size: Ensure the network path supports a maximum UDP payload of 1,300 bytes (including headers) to avoid fragmentation.
- Object Naming: Do not use special characters (< > ! @ # $ % ^ &) or Chinese, Japanese or Korean (CJK) characters in ZTNA object names.
- When you assign targets to Connector Groups, ensure that no single FQDN or wildcard target is associated with more than four total Connectors in one region. Also, IP Subnets can only be a part of 1 Connector Group. Limit DNS resolution of the previous FQDNs to IPv4 resolution. ZTNA Connector does not support establishing connection to the controller FQDNs using IPv6.
- SNAT: For FQDN and IP Subnet Target access, ZTNA Connector performs Source NAT; application servers will see ZTNA Connector’s internal IP as the source of all user traffic. ZTNA Connector performs NAT between the Prisma Access IP address network and the data center network; therefore, do not use it for applications that do not tolerate NAT, as it might not function properly.
- Using RFC 6598 Addresses for your with ZTNA Connector is not supported with the
default Prisma Access deployment; reach out to your
Palo Alto Networks team to activate them.If you use RFC 6598 shared addresses within your network, you must specify blocks of IP addresses that ZTNA Connector can use for routing between Prisma Access and your connectors and between Prisma Access and your private apps.
- Interoperability with Service Connections—You can use service connections and ZTNA
Connector in the same tenant; however, make sure that subnets advertised
from the data center to the service connection do not overlap with any
subnets used by ZTNA Connector for the same purpose. For example, make
sure that subnets advertised from a data center to Prisma Access
service connections using static routes or BGP do not
overlap with subnets used in ZTNA Connector IP subnet-based application
targets.When you configure service connection interoperability, account for the lack of direct connectivity between service connections and ZTNA connectors. Prisma Access requires an intermediate access method, such as a GlobalProtect® gateway, to route traffic between these components.
- Make sure all the Connectors in a single Connector Group should use the same DNS server for DNS resolution.