>
    Strata Copilot
    NGFW ZTNA Connector Integration
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma Access
    3. Prisma Access Administration
    4. NGFW ZTNA Connector Integration
    Download PDF
    Prisma Access

    NGFW ZTNA Connector Integration

    Table of Contents

    NGFW ZTNA Connector Integration

    Automate secure application access to Prisma® Access using NGFW as ZTNA Connectors, simplifying setup, configuration, and management.
    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Panorama)
    • Prisma Access (Managed by Strata Cloud Manager)
    • NGFW (Hardware and VM-series)
    • PAN-OS ® version 12.1.5 and later (Panorama and NGFW)
    • Cloud Service Plugin (CSP) version 6.1 and later
    • Prisma ® Access version 6.1
    NGFW ZTNA Connector Integration leverages your Palo Alto Networks® NGFWs (VM-Series and Hardware NGFW) as ZTNA Connectors. This provides secure, automated connectivity to private applications for Prisma Access users. This feature enables automated connectivity to applications defined by Fully Qualified Domain Name (FQDN), IP address and port, IP subnet, or wildcard FQDN, supporting mobile, contractor, and branch users.
    This feature addresses challenges like manual tunnel configuration, complex Network Address Translation (NAT) management for overlapped networks. It integrates your NGFWs directly into the Prisma Access architecture, automating these processes and optimizing application access. This approach minimizes operational complexity and improves user experience by providing more direct application access.
    Your NGFW acts as a ZTNA Connector, establishing secure IPSec tunnels with Prisma Access ZTNA Tunnel Terminators (ZTTs) in relevant cloud regions. Panorama, through its Cloud Services Plugin (CSP), centrally manages your NGFWs, registering them with the Prisma Access ZTNA Connector which generates and applies necessary configurations (IPSec, Border Gateway Protocol (BGP), Network Address Translation (NAT), Loopback IP addresses) to your NGFW via the CSP.
    Your NGFWs establish External Border Gateway Protocol (eBGP) sessions with Prisma Access to advertise routes for private applications and networks, performing continuous path monitoring and FQDN discovery. For wildcard applications, Prisma Access notifies ZTNA Connector of new discoveries. Data plane traffic flows through these tunnels, with the NGFW applying NAT and security policies.
    A single Panorama instance can manage both on-prem NGFWs and serve as the management plane for a Prisma Access tenant. When multiple NGFW Connectors are grouped and share a common template, configuration removal from Panorama is deferred until the last Connector in that Connector Group is explicitly deleted. This ensures template integrity during phased de-provisioning.

    Architecture and Core Components

    This section describes the key components, modules, and services involved in enabling your Palo Alto Networks NGFWs to function as ZTNA Connectors for Prisma Access. These components interact to provide secure, automated connectivity to your private applications.
    Core Components and Their Roles
    • Palo Alto Networks NGFW— Your NGFW serves as the primary device securing private applications. Configured as a ZTNA Connector, it establishes secure tunnels to Prisma Access and enforces access policies. Supported platforms include VM-Series and Hardware NGFW.
    • Panorama— This centralized management system orchestrates the configuration and deployment of ZTNA Connector functionality to your managed NGFWs. CSP is required for communication and configuration synchronization with Prisma Access.
    • Prisma Access Cloud Management— This cloud-based control plane manages Prisma Access services, including ZTNA Connectors. It provides the UI for onboarding NGFWs, creating Connector Groups, and defining application access policies.
    • CSP on Panorama— An essential plugin on your Panorama instance. It acts as an intermediary between Panorama-managed NGFWs and the Prisma Access cloud.
      • Register your Panorama and NGFWs with Prisma Access.
      • Retrieves dynamic configuration (tunnel, BGP, NAT rules) from Prisma Access.
      • Applies and commits this configuration to your NGFWs.
      • Reports NGFW status (tunnel and application reachability) back to Prisma Access.
    • Applications— Private applications accessed through the connector (wildcard, FQDN and IP Subnets).
    Architectural Flow: Application Access
    This section details how your users gain secure access to private applications through NGFW Connector.
    Application Onboarding (Non-Wildcard)— This process defines and configures access for specific private applications using FQDNs or IP addresses and ports, enabling Prisma Access users to securely reach explicitly defined applications behind the NGFW Connector.
    • You specify the application's FQDN or IP address, port range, and probe type in the Prisma Access.
    • Prisma Access service generates NAT rules, DNS proxy rules, and application probe configurations.
    • For each NGFW Connector in the group, ZTNA Connector creates application-specific configuration, including static routes, application probes, and FQDN-based NAT rules.
    • This configuration is published to the Panorama CSP, which then pulls and commits it to your NGFW.
    • Your NGFW advertises the application's reachability to Prisma Access via BGP, based on continuous path monitoring results.
    Wildcard Application Discovery and Onboarding— This mechanism dynamically discovers and onboards applications within a specified wildcard domain (e.g., *.example.local), simplifying management for environments with numerous or frequently changing applications.
    • You configure Prisma Access to onboard wildcard-based applications.
    • Your NGFW enables a DNS Proxy on a dedicated loopback interface, created by the ZTNA Connector during Connector Onboarding.
    • DNS requests from Prisma Access users for wildcard applications are forwarded to this DNS Proxy on your NGFW.
    • Your NGFW resolves the DNS request and sends the reply back to the ZTT.
    • The ZTT intercepts the reply and notifies ZTNA Connector about the newly discovered application.
    • ZTNA Connector then onboards this application, generating and pushing necessary NAT, routing, and probe configurations to your NGFW via Panorama CSP.
    Handling Overlapped IP Networks— This feature provides secure access to private applications even when their IP addresses overlap with other networks in Prisma Access or other customer networks. This prevents IP address conflicts and ensures correct routing. For overlapped networks, only onboarding of FQDNs and Wildcard FQDNs is supported.
    • You indicate if an application is in an overlapped IP network during onboarding via a checkbox in Strata Cloud Manager.
    • Your NGFW uses NAT, including SNAT and Destination NAT (DNAT), to translate overlapping IP addresses, ensuring unique addressing within Prisma Access.
    • For overlapped IP addresses, your NGFW preserves the pre-NAT'd IP address and presents it in firewall logs.
    • SNAT is applied on the egress interface to attract return traffic back to your NGFW.
    Packet Flow for Private Application Access— This illustrates the journey of user traffic to a private application through NGFW Connector, ensuring secure inspection and policy enforcement.
    • Inbound (Prisma Access User to Application)
      • Traffic from a Prisma Access user arrives at a ZTT.
      • The ZTT forwards traffic through the IPsec tunnel to your NGFW Connector.
      • Your NGFW applies the configured DNAT rule.
      • Your NGFW performs a route lookup for the application's destination.
      • Traffic is forwarded out the appropriate LAN interface after security policy checks.
    • Outbound (Application to Prisma Access User)
      • Return traffic from the private application arrives at your NGFW's LAN interface.
      • Your NGFW performs security policy checks, if configured on the NGFW.
      • Your NGFW reverses the NAT (undoes DNAT) to find the NAT flow.
      • Your NGFW performs a route lookup for the Prisma Access user's IP address.
      • Traffic is forwarded through the IPsec tunnel interface back to the ZTT and then to the Prisma Access user.

    Prerequisites for NGFW ZTNA Connector Integration

    Before you start, make sure that you have the following prerequisites:
    1. Panorama Configuration
      • All target NGFWs must be registered with and managed by a Panorama instance.
      • Pre-configured Panorama template stacks and templates must be in place for yourNGFWs.
      • NGFWs must be organized into appropriate device groups within Panorama.
      • NGFWs must be added to a designated Prisma Access (PA) Connector Group.
      • Panorama variables must be used for unique configurations (for example, IP addresses) when managing multiple NGFWs with the same template.
    2. NGFW Network Configuration
      • At least one interface on your NGFW must be configured as a Layer 3 WAN interface.
      • Your WAN interface must be assigned to a security zone.
      • A routable loopback IP address must be configured in your data center network.
      • A default route must be configured on your NGFW to reach the internet via its WAN interface.
      • Your NGFW's WAN interface must have a public IP address or be behind a NAT device with a public IP address.
    3. DNS and Application Configuration
      • Your NGFW must be configured to resolve FQDNs for private applications in your data center, either through a local DNS server or by utilizing the DNS Proxy feature.
    4. CSP
      • The unique identifier for your Prisma Access tenant must be obtained.
      • A service account must be created in Strata Cloud Manager's Identity & Access Management.
      • The tenant secret must be obtained from the ZTNA Connector overview page in Strata Cloud Manager.
      • CSP must be installed and activated on your Panorama instance.
      • CSP must be configured with the Prisma Access TSG ID, Service Account credentials, and Tenant Secret.
      • A commit operation must be performed on Panorama after configuring the CSP.
    Perform the following steps to integrate NGFW ZTNA Connector:
    1. Ensure your Panorama is actively managing the NGFW devices intended to be ZTNA Connectors.
    2. Prepare necessary templates and device groups in your Panorama.
      1. Go to PanoramaTemplatesCreate Templates and create a template.
      2. On Panorama, go to TemplatesAdd Stack and create a new template stack. If required, create or modify the template variables.
      3. On Panorama, go to Device GroupAdd and add a device group for your NGFW and attach the template created to the device group.
        If managing multiple NGFWs with the same template, use variables for unique configurations, such as WAN IP and LAN IP.
      4. On Panorama, go to Device Registration Auth KeyAdd and add a device registration authentication key. Copy Auth Key and Close.
      5. On Panorama, go to Managed DevicesSummaryAdd, enter the device registration key you created, Generate Auth Key, and Commit and Push.
      6. Configure the Panorama settings for the firewall.
        1. Select DeviceSetupManagement and edit the Panorama Settings.
        2. Enter the Panorama IP address in the first field.
        3. Enter the Auth key, select OK, and Commit your changes.
      7. On Panorama, go to Managed DevicesSummary and verify the connection status.
    3. Configure the WAN and LAN interfaces within your Panorama template.
      1. On Panorama, go to NetworkInterfacesEthernet, select the appropriate template from the Template context drop-down, select a slot number, such as Slot1, and select an interface (for example, ethernet1/1). Select the Interface Type as Layer 3.
      2. On the Config tab, select a Virtual Router or create a new virtual router.
      3. Assign the Security Zone that is appropriate for the interface you're configuring.
      4. For an IPv4 interface, select IPv4 tab and select Static in the Type of address field. Add a WAN IP address.
      5. On the Advanced tab, create or attach a Management Profile. Enable PoE Enable, and select OK.
      6. On Panorama, go to NetworkZones and create a Zone. Add a Name and select the Type as Layer 3. Enable Packet Buffer Protection under Zone Protection and select OK.
      7. Create a Virtual Router.
        1. On Panorama, go to NetworkVirtual Routers and select the virtual router.
        2. Select Router SettingsInterfaces. In Static Routes tab, select default.
        3. (Optional) Configure BGP. If not configured, Prisma Access Service enables it when the Connector is onboarded.
        4. Select OK.
      8. Commit and Push to save the configuration.

    Connect an NGFW to your Prisma Access Tenant

    After preparing your NGFW environment, connect your Prisma Access tenant to your Panorama management server. This initial process links your Panoramainstance to your Prisma Access tenant, establishing a secure trust relationship and communication channel.
    1. On Panorama, go to Cloud ServicesConfigurationNGFW Connector and select the settings icon.
    2. Add Prisma Access TSG ID.
    3. Configure the Service Account credentials.
      1. Create a Service Account in Strata Cloud Manager under Identity & Access Management.
      2. Get the Client Secret for this Service Account.
      3. On Panorama, add this Client Secret.
      4. On Strata Cloud Manager, go to ConfigurationZTNA ConnectorOverview. Under NGFW Connector, copy the secret Key.
      5. Commit and Push to initiate the connection to Prisma Access.
      6. Verify the connection status on Panorama.

    Onboard a NGFW as an Unclaimed Connector

    After connecting your Prisma Access tenant to Panorama, onboard specific NGFW devices as ZTNA Connectors.
    1. In Panorama, go to Cloud ServicesConfigurationNGFW Connector and select Add.
    2. Add NGFW Connector details.
      1. Enter a descriptive Name for NGFW Connector.
      2. Choose the Template Stack and Template that manages this NGFW.
      3. Select the specific NGFW Device (identified by its serial number) from the dropdown list.
      4. Add a routable Loopback IP address for the NGFW.
      5. Select the WAN interface configured earlier in the prerequisites.
    3. Commit the changes from Panorama to NGFW and verify the NGFW Connector registration. You can see the NGFW's public IP address.

    Add an NGFW to a ZTNA Connector Group

    After your NGFW is registered as an unclaimed Connector, add it to a ZTNA Connector Group in Prisma Access.
    1. Create a new ZTNA Connector Group or select an existing one.
      1. In Strata Cloud Manager, go to ConfigurationZTNA ConnectorConnector Groups and select Create Connector Group.
      2. Add a Name and select NGFW Connector as the Group Type and Create the Connector Group.
      3. Go to NGFW Connectors and select Create NGFW Connector. Add a Name, select your NGFW Connector Group, and select your NGFW's serial number under NGFW Connector from the list of available or unclaimed Connectors.
      4. (Optional) Enable Server Initiated Traffic.
        1. Configure the Destinations for server-initiated traffic:
          1. If you want to enable server-initiated connections to GlobalProtect users, select the Mobile User Pools checkbox to allow access to all mobile user pools.
          2. If you want to enable server-initiated connections to hosts on remote networks, select the Remote Network Pools checkbox and enter the specific IP subnets within the remote network to allow access.
          3. If you want to server-initiated connections to destinations in another NGFW Connector group's IP subnet targets, select the ZTNA Connector Data Center checkbox, and then select the IP subnet(s) to allow access.
            Currently, there is no support for NGFW Connector FQDN targets.
        2. Go to Routing and select the settings icon. Under Connectors with Server Initiated Traffic Enabled, select the Connector for which you want to configure the data center routing.
          You can only select Static as Routing Type.
      5. In Strata Cloud Manager, monitor the ZTNA Connector status to confirm tunnels are established and your NGFW is connected.
      6. In Panorama, go to Manged Devices Summary and monitor the status of policy and template configuration pushes to ensure they are in synchronization.

    DNS Configuration for Private Applications

    Configure DNS Proxy for Private Applications
    Use this procedure only if you don't have a private DNS server capable of resolving your internal applications and choose to use Panorama's DNS Proxy for static entries or wildcard resolution.
    1. Select the proxy object in Panorama.
      1. In Panorama, go to DeviceSetupServices and then select the proxy object (for example, ztna_ngfw_proxy).
      2. Under DNS Settings, select the DNS Proxy Object, and then select ztna_ngfw_proxy.
    2. Go to NetworkDNS Proxy and add DNS Static Entries for your private applications. Map application FQDNs to their corresponding IP addresses and select OK.
    3. Commit to save the DNS Proxy configuration and changes to Panorama.
    (Optional) Configure DNS Server for Private Applications
    Use this procedure if you want to use a DNS server to resolve internal applications.
    1. In Panorama, go to TemplatesDeviceSetupServices and select the settings icon.
    2. Under DNS Settings, select Servers, add a Primary DNS Server, and a Secondary DNS Server.
    When an NGFW Connector is onboarded, Prisma Access service configures ztna_ngfw_proxy in NetworkDNS Proxy. If DNS server is configured, then ztna_ngfw_proxy uses the same DNS IP addresses.

    Add Targets to a Connector Group

    Set up targets to access the private apps in the data centers through your NGFW Connector Virtual Machines (VM). You can add targets based on FQDN wildcards, FQDNs, or IP subnets; NGFW Connector does the work of setting up the networking and DNS settings required for your mobile users and users at branch offices to reach the apps securely through Prisma Access.
    Wildcard Targets: When configuring the target for ZTNA Connector, you can use a wildcard (e.g., *.example.com). This enables the automatic onboarding of applications accessed by mobile and remote network users that match the wildcard pattern. For instance, if you set the wildcard as *.example.com, ZTNA Connector will automatically configure and onboard a specific child application, like app1.example.com, including its unique FQDN, protocol, and port, as soon as a user accesses it.
    1. Go to Wildcard Targets and Create Wildcard Target.
    2. Enter a unique Name for the target.
    3. Enter the Connector Group to associate with the target.
      The Group must be a type of FQDN/Wildcard.
    4. Enter the Wildcard to use with the target.
      Enter it in the format of .example.com or .my.example.com (the UI implicitly adds the asterisk to the front of the wildcard). Do not allow all sites by specifying a wildcard of *.*, example.*.com, or *.com.
    5. Select the Protocol (tcp, udp or both).
    6. (Optional) To enable ICMP protocol from a GlobalProtect user to a ZTNA Connector data center, select Allow ICMP Protocol.
    7. Select the Port to use for the app.
      Enter a single port, multiple ports using commas between the ports, a range of ports using dashes, or both. Do not add spaces after the commas. Select Any port to match any ports you specify, or select Match and enter the port or ports to match.
      If you have selected both under Protocol, you have to add ports to TCP Port and UDP Port
      When you enter a range in TCP Port field, under Advanced Settings, icmp ping and none Probing Type gets activated.
    8. Enter a Probing Type of tcp ping, icmp ping, or none, depending on the protocol you select. The tcp ping acts as none here.
      If you select icmp ping, ZTNA Connector performs an ICMP ping to the FQDN's resolved IP address. If a response is received to the ICMP ping, the app is considered Up.
      If you select none, no probing is performed and the application is always marked as Up.
    9. Select Activated and Create the target.
    FQDN Targets: To create an FQDN target, go to FQDN target and Create FQDN Target. You create an FQDN target the same as you create an FQDN wildcard, substituting the FQDN wildcard with a single FQDN.
    Applications that are discovered as the result of a wildcard target are also displayed here. When users access sites that match the wildcard, those apps are automatically onboarded for access from ZTNA Connector for your mobile users and remote network users. For example, given a wildcard of *.example.com, when users access the app at app1.example.com, ZTNA Connector automatically adds that app to the list of FQDN targets. After an FQDN application is discovered from a parent wildcard target, any changes to the wildcard target are not updated in the discovered application. In addition, the same discovered FQDN is not rediscovered. If the characteristics for the discovered FQDN application require updating, perform a manual update on the discovered application using these steps.
    IP Subnets: Create an IP subnet-based target to find apps based on IP subnets instead of FQDNs.
    1. Go to IP Subnets and Create Subnet Rule.
    2. Enter a unique Name for the target.
    3. Enter the Connector Group to associate with the target.
      The Group must be a type of IP Subnet.
    4. Specify the data center IP Subnets to which the connector in the group provides IP routing access.
      All connectors in the group provide routing access to the specified IP subnets. You can select a single IP address in the form of 10.1.1.1/32, a single subnet, or multiple subnets separated by commas. Enter a maximum of 16 subnets.
      The IP subnet must be routable within the tenant's IP Fabric and the IP subnets cannot overlap with any other IP subnets in the tenant, including:
    5. Create the IP Subnet target.

    Additional Considerations

    Review these additional requirements and operational constraints to ensure your NGFW Connector deployment functions correctly within your environment.
    • Advance routing mode is not supported on NGFW and on Prisma Access. Only default routing mode is supported.
    • High Availability (HA) mode is not supported, you can on-board multiple NGFWs separately with a different serial number and attach it to the same template or template stack and in a same Connector Group.
    • If NGFW connector is disconnected from Panorama, the configuration push fails. You might need to push the configuration again when it's connected.

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