Prisma Access
ZTNA Connector Requirements and Guidelines
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
5.2 Preferred and Innovation
- 5.2 Preferred and Innovation
- 5.1 Preferred and Innovation
- 5.0 Preferred and Innovation
- 4.2 Preferred
- 4.1 Preferred
- 4.0 Preferred
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
-
-
-
-
- Allocate Licenses for Prisma Access (Managed by Strata Cloud Manager)
- Plan Service Connections for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Add Additional Locations for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Enable Available Add-ons for Prisma Access (Managed by Strata Cloud Manager)
- Enable Dynamic Privilege Access for Prisma Access (Managed by Strata Cloud Manager)
- Search for Subscription Details
- Share a License for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Increase Subscription Allocation Quantity
-
- Activate a License for Prisma Access (Managed by Strata Cloud Manager) and Prisma SD-WAN Bundle
-
- Onboard Prisma Access
-
4.0 & Later
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
- Prisma Access China
-
- Set Up Prisma Access
- Configure the Prisma Access Service Infrastructure
- Remote Networks: IPSec Termination Nodes and Service IP Addresses
- Remote Networks: IP Address Changes Related To Bandwidth Allocation
- Remote Networks: Service IP Address and Egress IP Address Allocation
- API Examples for Retrieving Prisma Access IP Addresses
- Get Notifications When Prisma Access IP Addresses Change
- Prisma Access Zones
- DNS for Prisma Access
- High Availability for Prisma Access
-
- Enable ZTNA Connector
- Delete Connector IP Blocks
- Set Up Auto Discovery of Applications Using Cloud Identity Engine
- Private Application Target Discovery
- Security Policy for Apps Enabled with ZTNA Connector
- Monitor ZTNA Connector
- View ZTNA Connector Logs
- Preserve User-ID Mapping for ZTNA Connector Connections with Source NAT
-
- Enable Dynamic Privilege Access for Prisma Access Through Common Services
- Authorize User Group Mapping in Cloud Identity Engine for Dynamic Privilege Access
- Enable the Access Agent
- Set Up the Agent Infrastructure for Dynamic Privilege Access
- Create a Snippet
- Create a Project
- Traffic Steering for Dynamic Privilege Access
- Push the Prisma Access Agent Configuration
- Download the Dynamic Privilege Access Enabled Prisma Access Agent Package
-
- Install the Prisma Access Agent
- Log in to the Dynamic Privilege Access Enabled Prisma Access Agent
- Change Preferences for the Dynamic Privilege Access Enabled Prisma Access Agent
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Location
- Switch to a Different Project
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Server
- Disable the Dynamic Privilege Access Enabled Prisma Access Agent
- Switch Between the Prisma Access Agent and GlobalProtect App
- View and Monitor Dynamic Privilege Access Users
- View and Monitor Dynamic Privilege Access Projects
- App Acceleration in Prisma Access
-
-
- Planning Checklist for GlobalProtect on Prisma Access
- Set Up GlobalProtect Mobile Users
- GlobalProtect — Customize Tunnel Settings
- GlobalProtect — Customize App Settings
- Ticket Request to Disable GlobalProtect
- GlobalProtect Pre-Logon
- GlobalProtect — Clientless VPN
- Monitor GlobalProtect Mobile Users
- How the GlobalProtect App Selects Prisma Access Locations for Mobile Users
- Allow Listing GlobalProtect Mobile Users
-
- Explicit Proxy Configuration Guidelines
- GlobalProtect in Proxy Mode
- GlobalProtect in Tunnel and Proxy Mode
- Private IP Address Visibility and Enforcement for Agent Based Proxy Traffic
- SAML Authentication for Explicit Proxy
- Set Up Explicit Proxy
- Cloud Identity Engine Authentication for Explicit Proxy Deployments
- Proxy Mode on Remote Networks
- How Explicit Proxy Identifies Users
- Explicit Proxy Forwarding Profiles
- PAC File Guidelines
- Explicit Proxy Best Practices
- Monitor and Troubleshoot Explicit Proxy
- Block Settings for Explicit Proxy
- Use Special Objects to Restrict Explicit Proxy Internet Traffic to Specific IP Addresses
- Access Your Data Center Using Explicit Proxy
- App-Based Office 365 Integration with Explicit Proxy
- Configure Proxy Chaining with Blue Coat Proxy
- IP Address Optimization for Explicit Proxy Users- Proxy Deployments
- DNS Resolution for Mobile Users—Explicit Proxy Deployments
- View User to IP Address or User Groups Mappings
- Report Mobile User Site Access Issues
- Enable Mobile Users to Access Corporate Resources
-
-
- Planning Checklist for Remote Networks
- Allocate Remote Network Bandwidth
- Onboard a Remote Network
- Connect a Remote Network Site to Prisma Access
- Enable Routing for Your Remote Network
- Onboard Multiple Remote Networks
- Configure Remote Network and Service Connection Connected with a WAN Link
- Remote Networks—High Performance
- Integrate a Shared Desktop VDI with Prisma Access Using Terminal Server
-
- Multitenancy Configuration Overview
- Plan Your Multitenant Deployment
- Create an All-New Multitenant Deployment
- Enable Multitenancy and Migrate the First Tenant
- Add Tenants to Prisma Access
- Delete a Tenant
- Create a Tenant-Level Administrative User
- Sort Logs by Device Group ID in a Multitenant Deployment
-
- Add a New Compute Location for a Deployed Prisma Access Location
- How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote Network Connections
- Proxy Support for Prisma Access and Strata Logging Service
- Block Incoming Connections from Specific Countries
- Prisma Access for No Default Route Networks
-
-
- Default Routes With Prisma Access Traffic Steering
- Traffic Steering in Prisma Access
- Traffic Steering Requirements
- Default Routes with Traffic Steering Example
- Default Routes with Traffic Steering Direct to Internet Example
- Default Routes with Traffic Steering and Dedicated Service Connection Example
- Prisma Access Traffic Steering Rule Guidelines
- Configure Zone Mapping and Security Policies for Traffic Steering Dedicated Connections
- Configure Traffic Steering in Prisma Access
- Preserve User-ID and Device-ID Mapping for Service Connections with Source NAT
-
- Prisma Access Internal Gateway
-
- Configure Privileged Remote Access Settings
- Set Up the Privileged Remote Access Portal
- Configure Applications for Privileged Remote Access
- Set Up Privileged Remote Access Profiles
- Define Permissions for Accessing Privileged Remote Access Apps
- Configure Split Tunneling for Privileged Remote Access Traffic
- Manage Privileged Remote Access Connections
- Use Privileged Remote Access
-
- Integrate Prisma Access With Other Palo Alto Networks Apps
- Integrate Third-Party Enterprise Browser with Explicit Proxy
-
-
- Connect your Mobile Users in Mainland China to Prisma Access Overview
- Configure Prisma Access for Mobile Users in China
- Configure Real-Name Registration and Create the VPCs in Alibaba Cloud
- Attach the CEN and Specify the Bandwidth
- Create Linux Instances in the Alibaba Cloud VPCs
- Configure the Router Instances
- Onboard the GlobalProtect Gateway and Configure the Prisma Access Portal
-
-
-
- INC_CIE_AGENT_DISCONNECT
- INC_CIE_DIRECTORY_DISCONNECT
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_MU_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_MU_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_DNS_SERVER_UNREACHABLE_ PER_PA_LOCATION
- INC_RN_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_DNS_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_ECMP_TUNNEL_RTT_EXCEEDED_ BASELINE
- INC_RN_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SECONDARY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SITE_CAPACITY_PREDICTION
- INC_SC_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SITE_CAPACITY_PREDICTION
-
- INC_CERTIFICATE_EXPIRY
- INC_GP_CLIENT_VERSION_UNSUPPORTED
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_CAPACITY
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_THRESHOLD
- INC_PA_INFRA_DEGRADATION
- INC_PA_SERVICE_DEGRADATION_PA_LOCATION
- INC_PA_SERVICE_DEGRADATION_RN_ SITE_CONNECTIVITY
- INC_PA_SERVICE_DEGRADATION_SC_ CONNECTIVITY
- INC_RN_ECMP_BGP_DOWN
- INC_RN_ECMP_BGP_FLAP
- INC_RN_ECMP_PROXY_TUNNEL_DOWN
- INC_RN_ECMP_PROXY_TUNNEL_FLAP
- INC_RN_ECMP_TUNNEL_DOWN
- INC_RN_ECMP_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_BGP_FLAP
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_BGP_DOWN
- INC_RN_SECONDARY_WAN_BGP_FLAP
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_FLAP
- INC_RN_SITE_DOWN
- INC_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_RN_SPN_LONG_DURATION_CAPACITY_EXCEEDED _THRESHOLD
- INC_RN_SPN_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_SC_PRIMARY_WAN_BGP_DOWN
- INC_SC_PRIMARY_WAN_BGP_FLAP
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_PRIMARY_WAN_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_BGP_DOWN
- INC_SC_SECONDARY_WAN_BGP_FLAP
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_TUNNEL_FLAP
- INC_SC_SITE_DOWN
- INC_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_SC_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- INC_ZTNA_CONNECTOR_CPU_HIGH
- INC_ZTNA_CONNECTOR_MEMORY_HIGH
- INC_ZTNA_CONNECTOR_TUNNEL_DOWN
-
- AL_CIE_AGENT_DISCONNECT
- AL_CIE_DIRECTORY_DISCONNECT
- AL_MU_IP_POOL_CAPACITY
- AL_MU_IP_POOL_USAGE
- AL_RN_ECMP_BGP_DOWN
- AL_RN_ECMP_BGP_FLAP
- AL_RN_PRIMARY_WAN_BGP_DOWN
- AL_RN_PRIMARY_WAN_BGP_FLAP
- AL_RN_PRIMARY_WAN_TUNNEL_DOWN
- AL_RN_PRIMARY_WAN_TUNNEL_FLAP
- AL_RN_SECONDARY_WAN_BGP_DOWN
- AL_RN_SECONDARY_WAN_BGP_FLAP
- AL_RN_SECONDARY_WAN_TUNNEL_DOWN
- AL_RN_SECONDARY_WAN_TUNNEL_FLAP
- AL_RN_SITE_DOWN
- AL_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- AL_RN_SPN_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_PRIMARY_WAN_BGP_DOWN
- AL_SC_PRIMARY_WAN_BGP_FLAP
- AL_SC_PRIMARY_WAN_TUNNEL_DOWN
- AL_SC_PRIMARY_WAN_TUNNEL_FLAP
- AL_SC_SECONDARY_WAN_BGP_DOWN
- AL_SC_SECONDARY_WAN_BGP_FLAP
- AL_SC_SECONDARY_WAN_TUNNEL_DOWN
- AL_SC_SECONDARY_WAN_TUNNEL_FLAP
- AL_SC_SITE_DOWN
- AL_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_SITE_LONG_DURATION_EXCEEDED_CAPACITY
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- AL_ZTNA_CONNECTOR_CPU_HIGH
- AL_ZTNA_CONNECTOR_MEMORY_HIGH
- AL_ZTNA_CONNECTOR_TUNNEL_DOWN
- New Features in Incidents and Alerts
- Known Issues
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.
Supported Prisma Access Versions and Requirements
- Prisma Access 4.0 version with a compatible SaaS Agent.Upgrade any Prisma Access release earlier than 4.0, including any Innovation releases, to a minimum version of 4.0.A minimum Prisma Access version of 5.0 is required if you want to use FQDN wildcards or IP Subnets to access apps. In addition, Prisma Access 5.0 unlocks the use of the Dump Overview, Packet Capture, and Tech Support diagnostic tools.
- You must upgrade your connector versions to a minimum of 6-2-2-ztna-connector-b1 to use 5.0 functionality.
- For Prisma Access (Managed by Panorama), upgrade the Cloud Services plugin version to a minimum version of 4.0. Upgrade to the latest Cloud Services plugin to unlock the latest features.
App Support
ZTNA Connector provides access to all of your private app traffic, with the
following exceptions:
- ZTNA Connector does not support the following:
- Traffic originating from the data center (such as SCCM or remote help desk traffic).
- User-ID redistribution.
- Applications that perform port hopping (such as VoIP or Active Mode FTP).
- Application-level gateway (ALG) apps such as Active Mode FTP and SIP.
- Windows-integrated authentication for applications (such as NTLM or Kerberos) is only supported if you onboard the data center domain controllers and resources as IP address subnets. SAML, OAuth, and LDAP are supported.
- Communication between apps behind a service connection and apps
behind a ZTNA Connector. For example, you host a Windows Active Directory (AD) server behind a service connection (since AD servers are not supported behind a ZTNA Connector), and host an FTP (Filezilla) server behind a ZTNA Connector. If the FTP server requires authentication to the Windows AD server, authentication fails, because you can't use Prisma Access as a backbone between the Service Connection Corporate Access Node (SC-CAN) and the ZTNA Connector Tunnel Terminator (ZTT).
Feature and Functionality Restrictions
Keep in mind the following restrictions when setting up and configuring a ZTNA
Connector deployment:
- Don't use special characters, including < > ! @ # $ % ^ & and Chinese, Japanese, or Korean characters, in ZTNA object names.
- The following functionalities are not supported with the default Prisma
Access deployment; reach out to your Palo Alto Networks team to activate
them:
- Using RFC 6598 Addresses for your with ZTNA Connector
- Connector Group Guidelines—When adding connector groups, use the
following recommendations:
- All apps in a single Connector Group should use the same DNS server for DNS resolution.
- If you're accessing apps from a data center or headquarters location, all apps in the Connector Group should be from the same data center or headquarters location.
- Don't add connectors in two or more regions in a single Connector Group . All connectors in a Connector Group should be in the same region.
- Starting with Prisma Access 5.01, you can specify up to a four
connector groups per FQDN target or wildcard target (release 5.0 and
earlier support a single Connector Group per FQDN target or wildcard
target). Be sure that, when you assign connector groups per FQDN
target or wildcard target, you don't assign the same app to more
than four connectors per region. For example, you have assigned the same app (either an FQDN target or a wildcard target) to four connector groups, each group has a single connector, and all connectors are in the same region. This configuration is acceptable because you're not assigning more than four connectors per app in a single region.However, if you assign the same app (either an FQDN target or a wildcard target) to three connector groups, each group has two connectors, and all connectors are in the same region, that is an invalid configuration, because you're assigning six connectors to the same app in a single region.
- Some ZTNA Connectors such as AWS-based connectors or Azure-based connectors support autoscaling, where AWS or Azure monitors network bandwidth utilization on the connectors and automatically adjusts capacity to maintain app performance. When network bandwidth utilization on connectors drops, AWS or Azure triggers auto scale-in. If scale-in occurs in a ZTNA Connector, existing long-lived sessions handled by the ZTNA Connector marked for scale-in terminate prematurely. This behavior does not impact new traffic sessions initiated after scale-in. For long-lived sessions, such as SSH or RDP, ZTNA Connector terminates the session during scale-in, and you must reconnect that session.
Scale and Throughput Considerations
ZTNA Connector supports the following maximum values:
- 4,096 applications per tenant across all connector groups
- 200 Connectors per tenant
- 512 applications per Connector Group
- 4 connectors per Connector Group
- 200,000 concurrent sessions per ConnectorEach Connector can support 200,000 concurrent connections. A Connector Group can have a maximum of 4 connectors for up to 800,000 concurrent connections per Connector Group.
- 26 compute regions
- 1 Gbps throughput per connector, with a maximum of 10 Gbps per Prisma Access compute location
Supported Application Hosting Environments
You can deploy your ZTNA Connector VMs in the following data center environments
with the specified minimum requirements:
Cloud Provider | 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 |
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, GCP, and Azure have ZTNA Connectors you can acquire in their respective
Marketplaces. You can download the VMware ESXi Open Virtualization Application
(OVA) file and the KVM qcow file from the Palo Alto Customer Support Portal.
Network Requirements
The following networking requirements enable connectivity between ZTNA Connector
and Prisma Access:
- 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.
- UDP payload size, including headers, should not exceed an MTU size of 1,300 bytes on the path to the ZTNA application server. Palo Alto Networks recommends keeping packets at or below this MTU size.
- Allow outbound UDP port 4500 and UDP 500 from the WAN interface (port 1)
IP address for IPSec and IKE connectivity to the ZTNA Tunnel Terminator
(ZTT). If you want to limit enabling an outbound UDP port 500 and 4500
connection to a single IP address, enable it for the PA
Service IP address (under WorkflowsZTNA ConnectorConnectors) of the ZTNA Connector.
- If ZTNA Connector uses a public IP address for its internet interface, you must allow a IP/50 Encapsulating Security Payload (ESP).
- Allow outbound TCP port 443 from the WAN interface (port 1) IP address HTTPS connectivity to the ZTNA Connector Controllers.
- ZTNA Connector autoconfigures both the Prisma Access ZTT side of the IPSec tunnel and the ZTNA Connector side. The algorithms configured for DH Group/Encryption/Hash for both IKE and ESP are: ecp384/aes256/sha512.
- Don't terminate the IPSec tunnel that ZTNA Connector creates and uses to access the private apps.
- (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 server configuration. If you removed an application from ZTNA Connector, you must refresh the GlobalProtect app so mobile users can receive the updated DNS server configuration.
- 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; 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. 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 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).
- (ZTNA Connector versions 5.0 and later) 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.
- 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.
- 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.For example, if you're setting up a ZTNA Connector in the United States, add the following URLs to your organization's allow lists:
- https://controller.cgnx.net
- https://locator.cgnx.net
- https://controller.hood.cgnx.net
- https://vmfg.hood.cgnx.net
- https://sdwan-stats-hood-us.cgnx.net
- time.nist.gov (for NTP)
- 0.cloudgenix.pool.ntp.org (for NTP)
- 1.cloudgenix.pool.ntp.org (for NTP)
- 2.cloudgenix.pool.ntp.org (for NTP)
- 3.cloudgenix.pool.ntp.org (for NTP)
Limit DNS resolution of the previous FQDNs to IPv4 resolution. ZTNA Connector does not support establishing connection to the controller FQDNs using IPv6. - Disable the SSL decryption for sessions to the Controllers.
IP Addresses and FQDNs to Allow for ZTNA Connector
To ensure smooth functioning of ZTNA Connector, add the following URLs and IP
addresses to your allow lists.
Service Name | Port | Direction | Source Interface Internet Protocol | Destination and IP Addresses |
---|---|---|---|---|
ZTNA Connector access to Prisma Access | 443 | Outbound |
ZTNA Connector WAN port
| https://controller.cgnx.net Address:
52.8.93.87 Address:
52.8.25.40 https://locator.cgnx.net Address:
13.56.217.238 Address:
13.56.201.169 hood: 52.40.98.31 34.218.98.185 sugarloaf: 18.200.102.82 18.200.135.33 faber: 18.139.242.53 54.255.61.109 https://vmfg.cgnx.net Address:
52.53.122.104 Address:
52.53.102.7 https://controller.elcapitan.cgnx.net Address:
52.8.93.87 Address:
52.8.25.40 https://vmfg.elcapitan.cgnx.net Address:
52.53.122.104 Address:
52.53.102.7 https://controller.hood.cgnx.net Address:
52.32.167.5 Address:
54.70.168.33 https://vmfg.hood.cgnx.net Address:
50.112.136.184 Address:
34.210.34.87 https://controller.sugarloaf.cgnx.net Address:
108.128.176.192 Address:
18.200.144.58 https://vmfg.sugarloaf.cgnx.net Address:
99.81.179.99 Address:
99.80.52.255 https://sdwan-stats-hood-us.cgnx.net https://sdwan-stats-elcapitan-us.cgnx.net https://sdwan-stats-hood-jp.cgnx.net https://sdwan-stats-elcapitan-jp.cgnx.net https://sdwan-stats-hood-sg.cgnx.net https://sdwan-stats-elcapitan-sg.cgnx.net https://sdwan-stats-hood-au.cgnx.net https://sdwan-stats-elcapitan-au.cgnx.net https://sdwan-stats-hood-in.cgnx.net https://sdwan-stats-elcapitan-in.cgnx.net https://sdwan-stats-hood-ca.cgnx.net https://sdwan-stats-elcapitan-ca.cgnx.net https://sdwan-stats-sugarloaf-eu.cgnx.net https://sdwan-stats-sugarloaf-de.cgnx.net https://sdwan-stats-sugarloaf-uk.cgnx.net https://controller.bowfell.cgnx.net Address:
13.41.243.90 Address:
18.171.17.23 https://vmfg.bowfell.cgnx.net Address:
52.56.35.36 Address:
52.56.224.242 https://controller.faber.cgnx.net Address:
52.74.47.220 Address:
13.251.109.27 https://vmfg.faber.cgnx.net Address:
18.142.153.59 Address:
52.74.58.219 https://controller.townsend.cgnx.net Address:
13.55.31.41 Address:
3.106.168.215 https://vmfg.townsend.cgnx.net Address:
52.64.177.240 Address:
13.55.164.51 https://sdwan-stats-faber-sg.cgnx.net https://sdwan-stats-bowfell-uk.cgnx.net https://sdwan-stats-townsend-au.cgnx.net |
NTP | 123 | Outbound |
ZTNA Connector WAN and LAN ports
|
time.nist.gov
0.cloudgenix.pool.ntp.org
1.cloudgenix.pool.ntp.org
2.cloudgenix.pool.ntp.org
3.cloudgenix.pool.ntp.org
|
DNS | 53 | Outbound |
ZTNA Connector WAN and LAN ports
| Customer or Provider DNS servers |