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

    Configure NGFW Connector Integration

    Table of Contents

    Configure NGFW Connector Integration

    Configure and manage NGFW as ZTNA Connectors in Prisma Access using Panorama or Strata Cloud Manager for automated, secure private application access.
    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Panorama)
    • NGFW (Hardware and VM-Series)
    • PAN-OS ® version 12.1.5 and later
    • Cloud Service Plugin (CSP) version 6.1 and later (Panorama-managed deployments only)
    • Prisma Access version 6.1 and later
    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. Your management interface 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.
    When multiple NGFW Connectors are grouped in a Connector Group, configuration removal is deferred until the last Connector in that Connector Group is explicitly deleted. This ensures configuration integrity during phased de-provisioning. Select the appropriate tab for your management interface to configure NGFW Connector.

    Configure NGFW Connector Integration (Panorama)

    Configure NGFW Connector in Panorama to use your existing next-generation firewalls as ZTNA Connectors for secure private application access.
    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Panorama)
    • 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 and later
    • Template stacks and device groups configured in Panorama
    • Prisma Access TSG ID and service account credentials
    When your NGFWs are managed by Panorama, use the Cloud Services Plugin (CSP) to register your NGFWs with Prisma® Access and deploy ZTNA Connector functionality. Panorama orchestrates configuration across your managed NGFWs using template stacks, and the CSP synchronizes configurations between Panorama and the Prisma Access cloud.
    1. Prepare templates and device groups in Panorama.
      1. Select PanoramaTemplatesCreate Templates and create a template.
      2. On Panorama, select TemplatesAdd Stack and create a new template stack. If required, create or modify the template variables.
      3. On Panorama, select 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, select Device Registration Auth KeyAdd and add a device registration authentication key. Select Copy Auth Key and Close.
      5. On Panorama, select Managed DevicesSummaryAdd, enter the device registration key you created, select 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, select Managed DevicesSummary and verify the connection status.
    2. Configure the WAN and LAN interfaces within your Panorama template.
      1. On Panorama, select 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. Select Add to 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, select 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, select 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.
    3. Connect your Prisma Access tenant to Panorama.
      1. On Panorama, select 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, select 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.
    4. Onboard the NGFW as an unclaimed connector.
      1. In Panorama, select 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.
    5. (Optional) Configure DNS 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, select 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. Select 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 a DNS server for private applications if you want to use a DNS server to resolve internal applications.
      1. In Panorama, select 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.

    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.
    • Management Interface— Your management interface (Panorama or Strata Cloud Manager) orchestrates the configuration and deployment of ZTNA Connector functionality to your managed NGFWs. For Panorama-managed NGFWs, the Cloud Services Plugin (CSP) is required for communication and configuration synchronization with Prisma Access. For Strata Cloud Manager-managed NGFWs, both Prisma Access and your NGFWs must belong to the same tenant for automatic registration.
    • 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.
    • 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 management interface, 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 the management interface.
    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 (for Panorama) only)

    Before you start, make sure that you have the following requirements:
    1. 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.
    2. 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.

    Create a Connector Group and Add Your NGFW (for Panorama) only)

    After completing the platform-specific setup, create a ZTNA Connector Group in Strata Cloud Manager and add your NGFW as a connector. These steps apply regardless of whether your NGFWs are managed by Panorama or Strata Cloud Manager.
    1. In Strata Cloud Manager, select ConfigurationZTNA ConnectorConnector Groups and select Create Connector Group.
    2. Add a Name, select NGFW Connector as the Group Type, and select Create.
    3. Select NGFW Connectors and Create NGFW Connector.
    4. Add a Name and select your NGFW Connector Group.
    5. Under NGFW Connector, select your NGFW's serial number from the list of available connectors.
    6. (Optional) Enable Server-Initiated Traffic.
      1. Configure the Destinations for server-initiated traffic:
        1. To enable server-initiated connections to GlobalProtect users, select the Mobile User Pools checkbox to allow access to all mobile user pools.
        2. 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. To enable 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. Select 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.
    7. Monitor the ZTNA Connector status to confirm tunnels are established and your NGFW is connected.

    Add Targets to a Connector Group (for Panorama) only)

    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 (for Panorama) only)

    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.