>
    Strata Copilot
    ZTNA Connector Requirements and Guidelines
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma Access
    3. Prisma Access Administration
    4. Prisma Access ZTNA Connector
    5. ZTNA Connector Requirements and Guidelines
    Download PDF
    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?
    • Prisma Access (Managed by Strata Cloud Manager)
    • Prisma Access (Managed by Panorama)
    • We require a minimum version of Prisma Access 5.0 to enable ZTNA Connector support.
    • Prisma Access Base (ZTNA or Enterprise) license includes 10 Connectors.
    • Private App Access add-on license includes up to 200 Connectors.
    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 MetricsMaximum Value
    Bandwidth per ConnectorUp to 2 Gbps*
    Bandwidth per Connector Group (with 4 Connectors)6 Gbps*
    Applications per tenant across all Connector Groups
    40,000†
    Applications per Connector Group
    2,000
    Connectors per tenant200
    Connector per Connector Group4
    Concurrent sessions per Connector100,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 Group400,000
    Maximum IP subnets per tenant1024
    *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.
    †To achieve 40,000-application scale, you mustn't have more than 2 connectors in that specific Connector Group. Contact your accounts team before scaling up above 20,000 apps to ensure your tenant has enough capacity.

    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 a single Connector Group in the same subnet with equal access to application servers for consistent performance.
      • Make sure all the Connectors in a single Connector Group should use the same DNS server for DNS resolution.
      • 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.
      • Disaster Recovery—To protect application targets against data center outages, deploy your primary and standby Connector Groups in separate data centers. Connector Groups used for disaster recovery can be in the same or different Prisma Access compute locations — Prisma Access uses BGP path cost manipulation to route traffic through the primary Connector Group and automatically reroutes to the standby Connector Group when the primary becomes unavailable. Disaster Recovery requires ZTNA Connector version 6.2.9-ztna-connector-b1 or later. If the Connector Group version does not meet this requirement, an error occurs during configuration.

    Application Target Configurations

    When you assign application targets to Connector Groups, choose the deployment model that matches your availability and performance requirements:
    • Simple (Single Group)—Assign the target to one Connector Group. All traffic routes through the connectors in that group. Use for deployments where geographic distribution and redundancy are not required.
    • Disaster Recovery—Assign an FQDN, IP subnet, or wildcard target to a primary Connector Group and a standby Connector Group. Prisma Access uses BGP path cost manipulation to route traffic through the primary Connector Group. If the primary Connector Group becomes unavailable, Prisma Access automatically reroutes to the standby Connector Group. The standby Connector Group can be in the same or different Prisma Access compute location as the primary Connector Group. When you enable disaster recovery for an IP subnet target, the target is associated with both the primary and standby Connector Groups. Disaster Recovery requires ZTNA Connector version 6.2.9-ztna-connector-b1 or later.
    • Proximity-Based Routing—Assign an FQDN or wildcard target to Connector Groups, each deployed in a unique compute location. Prisma Access routes each user session to the nearest Connector Group, reducing latency and distributing load across data centers. Each Connector Group must be in a distinct compute location.

    Supported Application Hosting Platform

    You can deploy your ZTNA Connector VMs in the following data center environments with the specified minimum requirements:
    Cloud ProviderRecommended Cloud Instance SizeCPU SizeMemory SizeDisk Size
    Amazon AWSm5.xlarge per region4 vCPUs16 GB40 GB
    Google Cloud Platform (GCP)n2-standard-4 per region4 vCPUs16 GB40 GB
    Microsoft AzureStandard_D4_v3 per region4 vCPUs16 GB40 GB
    Oracle Cloud Infrastructure (OCI)VM.Standard.E5.Flex2 OCPUs (4 vCPUs)16 GB
    KVMUses qcow image4 vCPUs16 GB40 GB
    Hyper-VUses vhd image4 vCPUs8 GB memory40 GB
    VMware ESXiUses OVA image. Supported on vSphere and directly on ESXi Hosts 4 vCPUs8 GB memory40 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.
    ZTNA Connector supports two primary interface configurations:
    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.The internet and data center interfaces must be on different IP subnets.
    • 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:
    1. ZTNA Connector Application IP Blocks: The subnets where your target applications reside.
    2. 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 Servers 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).
    • 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).
    • (Mobile Users—GlobalProtect deployments only) When you first onboard an application in ZTNA Connector, you must refresh the GlobalProtect connection so mobile users receive the updated DNS proxy resolution. Otherwise the GlobalProtect client may use a stale DNS Cache resolution.

    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 NameSource IP AddressDestinationProtocol/PortActionNote
    Cloud ControllerConnector Port 1*.cgnx.net￥TCP 443AllowDisable SSL Decryption⁂
    ZTT IPSec фConnector Port 1Prisma Access Service IP addressesUDP 500, 4500AllowIKE and NAT-T
    ZTT-NTPConnector Port 1time.nist.gov, *.cloudgenix.pool.ntp.orgUDP 123AllowTime synchronization
    ZTT-Public-DNSConnector Port 1Public DNS (example 8.8.8.8)UDP and TCP 53AllowPublic FQDN resolution
    DiagnosticsConnector LAN IPping ZTT, traceroute to ZTT, ping app server, traceroute to app server, tcpping controller endpointICMP, UDP and TCPAllowFor ping, tccping, nslookup or traceroute tools
    фIf ZTNA Connector uses a public IP address for its internet interface, you must allow an IP/50 Encapsulating Security Payload (ESP). ESP must be allowed bi-directionally (both inbound and outbound traffic). There are no ports for ESP; it is a separate IP protocol (IP 50), not TCP or UDP. This requirement applies to all IPSec devices, not just ZTNA Connectors.
    ￥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.
    ⁂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 NameSource IP AddressDestinationProtocol/PortActionNote
    Internal-DNSConnector LAN IPInternal DNS ServersUDP and TCP/53AllowApp FQDN resolution
    App-ProbingConnector LAN IPInternal Application ServersHealth probe protocol and portAllowTCP Ping health check
    User-AccessConnector LAN IPInternal Application ServersApp Specific Protocols or PortsAllowProduction user traffic
    DiagnosticsConnector LAN IPtcpping app server, ping app server, traceroute to app server, ping DNS, traceroute to DNSICMP, UDP and TCPAllowFor 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 function properly.
      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 ElementRequirement / Best Practice
    Source ZoneTypically your "Untrust" or "Mobile User" zone.
    Destination ZoneThe zone associated with your ZTNA Connector Group.
    Destination AddressMust match the FQDN Targets (for example, crm.internal.local) or IP Subnets defined in your ZTNA Application settings.
    ServiceLimit to the specific application ports (for example, service-http, SSH).
    Security ProfilesApply 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.
    • Proximity-Based Routing Limits—For proximity-based routing, you can assign a single FQDN or wildcard target to Connector Groups, with each Connector Group deployed in a unique compute location.
    • IP Subnet and IPv6 Limits—IP Subnet targets can only be assigned to one Connector Group, except when disaster recovery is enabled — with disaster recovery, an IP Subnet target uses a primary Connector Group and a standby Connector Group. ZTNA Connector does not support establishing connections to 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.
    • App Deletion via API—If you need to delete multiple applications from a connector group using the API, space each delete operation at least 30 seconds apart. Mass deletion without adequate spacing between requests may result in unexpected behavior.
    • Configuration Changes After an Upgrade—Avoid making configuration changes within 30 minutes of a connector group upgrade. If an app appears as down in the Strata Cloud Manager UI after an upgrade, disable and then re-enable the app to restore connectivity.
    • FQDN and App TAG Updates—When you update an FQDN and an App TAG associated with that FQDN, you must perform a commit and push for Mobile Users, Remote Networks, and Explicit Proxy for the change to be reflected in security policies.
    • Apps with Multiple Connector Groups in the Same Region—Applications previously configured with multiple Connector Groups in the same compute location (non-DR mode) continue to function after a management server upgrade. However, if you edit one of these apps, the edit is blocked. To modify the app, reconfigure it using Disaster Recovery mode by assigning a primary and standby Connector Group.
    • 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.

    © 2026 Palo Alto Networks, Inc. All rights reserved.