Prisma Access ZTNA Connector
Table of Contents
4.0 & Later
Expand all | Collapse all
-
- 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
- High Availability for Prisma Access
-
- 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
-
- 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
- View and Monitor Dynamic Privilege Access Users
- View and Monitor Dynamic Privilege Access Projects
- Automatic Tunnel Restoration in Dynamic Privilege Access Prisma Access Agents
- Manage Prisma SASE 5G
-
-
- Explicit Proxy Configuration Guidelines
- How Explicit Proxy Identifies Users
- Explicit Proxy Forwarding Profiles
- Explicit Proxy Best Practices
- Block Settings for Explicit Proxy
- Use Special Objects to Restrict Explicit Proxy Internet Traffic to Specific IP Addresses
- Configure Proxy Chaining with Blue Coat Proxy
- IP Address Optimization for Explicit Proxy Users- 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
- 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
- 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
- BGP Filtering and Route Metric Support on Service Connections in Prisma Access
-
- 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
- Manage Privileged Remote Access Connections
- Use Privileged Remote Access
Prisma Access ZTNA Connector
Describes what the ZTNA Connector is and how it works in Prisma Access.
Where Can I Use This? | What Do I Need? |
---|---|
|
|
The Zero Trust Network Access (ZTNA) Connector lets you connect Prisma Access to your
organization's private apps simply and securely. ZTNA Connector provides mobile users
and users at branch locations access to your private apps using an automated secure
tunnel. Because the ZTNA Connector sets up the tunnels automatically, you don't have to
manually set up IPSec tunnels and routing to the data center or headquarters locations,
public cloud locations, and partner networks where your private apps are located.
The ZTNA Connector VMs you deploy automatically connect to the closest Prisma Access
location ensuring the best possible latency, in addition to scaling bandwidth access up
to 2 Gbps per Connector.
Prisma Access denies all access by default, and an administrator must explicitly
allow access to a resource using a policy rule, based on our patented User-ID, App-ID,
and Device-ID constructs, helping you to reduce the attack surface and the security
risks. Once a connection is allowed, we continuously verify the trust of that
connection, continuously inspect for security threats, and continuously inspect for data
leakage. In addition, the private IP addresses of your applications are not exposed when
you use the Prisma Access ZTNA Connector.
ZTNA Connector Components
- Connectors—Connectors are the virtual machines that build tunnels to Prisma Access. ZTNA Connector automates tunnel management without you having to specify IPSec and IKE settings. You onboard Connectors in VMs, which you onboard in a cloud service (Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, or in a virtual server (VMware ESXi), or in a Kernel-based Virtual Machine (KVM). Palo Alto Networks recommends that you deploy the VM in the same subnet as the onboarded application to Prisma Access. You can also provide a different subnet, as long as there is a route to the applications from the Connector.After you deploy the Connector VM, Prisma Access manages the VM, including providing you with options to upgrade the VM version. After installing the ZTNA Connector VM, it discovers the nearest Prisma Access location and initiates a secure IPSec tunnel to Prisma Access.
- Connector Groups—A Connector Group is a logical grouping of connectors and apps. By adding multiple connectors in a Connector Group, you provide tunnel redundancy and increased bandwidth to the apps within the group. Each Connector Group supports up to four connectors.If you want to provide access to specific apps using different connectors, place the connectors in separate groups.
- Targets—The private apps that ZTNA Connector onboards to Prisma Access. You can define specific apps to which you want to provide access using FQDN (FQDN Targets), wildcards (Wildcard Targets), or IP addresses or subnets where the apps are located. Or, you can have ZTNA Connector automatically discover apps by pulling them from an IdP connected to CIE.
Use Cases for ZTNA Connector
Use ZTNA Connector in these scenarios:
- Connect to Private Apps—Use ZTNA Connector for all client-initiated
traffic that connects to private apps.
- Overlapped Private Networks—If you're a network administrator in a large enterprise that has acquired or merged with another organization, two networks might use address ranges that overlap (for example, RFC 1918 private network address space). To provide access to apps that are hosted in overlapped networks to your users, routing and NAT configuration can become tedious. ZTNA Connector simplifies app access in overlapped networks by allowing you to connect to apps using FQDNs, FQDN wildcards, and IP subnets, without you having to configure IP routing.ZTNA Connector provides your users secure access to the private apps using ZTNA-Connector Tunnel Terminators (ZTTs).When you activate a ZTNA Connector in a compute region, ZTT nodes are automatically onboarded. ZTNA Connector automatically forms IPSec tunnels with ZTTs. ZTT nodes in a region remain active for 24 hours after all connectors in that region are deleted. If a new connector is deployed within 24 hours after all connectors are deleted in the same region, it reuses the existing ZTT. If a new ZTNA Connector is activated after 24 hours, a new ZTT is created.
- Data Center to Cloud Migration—If your organization is migrating your on-premises apps to the cloud (either migrating your existing on-premises applications using "lift and shift" or developing cloud-native apps), you can host apps in cloud VPCs in AWS, GCP, Azure, or other cloud providers. If you have hundreds or thousands of VPCs, ZTNA Connector can accelerate the process of providing cloud-delivered app access.
- Access to Applications in Business Partner Networks—Some organizations
access apps hosted in their business partner’s networks. Using service
connections to connect these apps requires manual routing and NAT configuration.
ZTNA Connector allows you to connect to these apps without performing manual IP
routing configuration.
Supported Use Cases for Service Connections and ZTNA Connector
ZTNA Connector isn't a replacement for service connections. It can complement or
coexist with service connections, allowing you flexibility in how you secure private
apps. If you have already deployed service connections, you can continue to use
them, unless you want to move to a different application access model. The following
table shows the supported and unsupported use cases for service connections or ZTNA
Connector. A check mark indicates that the use case is supported; a dash (—)
indicates that it's not supported.
Use Case | ZTNA Connector Support | Service Connection Support |
---|---|---|
Access to applications in overlapped networks | √ | — |
Access to all ports and protocols for client-initiated application traffic | √ | √ |
Automatic tunnel establishment to Prisma Access | √ | — |
Automatic Prisma Access location discovery | √ | — |
Access to private apps using IP addresses and subnets | √ | √ |
Server-initiated traffic (such as a remote help desk) reaching out to a managed device (GlobalProtect mobile user or remote network). | — | √ |
Applications or services that require a unique client IP address | √ | √ |
Access to applications with dynamic ports (such as FTP Active mode or VoIP) | — | √ |
Hybrid deployments with on-premises next-generation firewalls where policy rules based on User-ID are applied | √ | √ |
ZTNA Connector 2.0 Principles
ZTNA Connector lets you connect your private apps to Prisma Access using the
following ZTNA Connector 2.0 principles:
- Device Posture and Risk—Using policy rules based on User-ID in Prisma Access, you can define a posture for users and devices (both mobile user and IoT devices) to prevent unauthorized access to the private apps. You can also create common policy rules between ZTNA Connector and Prisma Access.
- User Authentication and Least Privilege Access—Using user authentication and policy rules based on user or group, you can implement the principle of least privilege (PoLP) to provide users access to the apps they require, while blocking access to the apps they don't require.
- Threat and Data Loss Prevention—Prisma Access and ZTNA Connector use
advanced security features such as Advanced Threat Prevention, Advanced URL
Filtering, SaaS Security, Advanced WildFire, and Enterprise DLP to make sure
that your private apps and app data are secure.