Prisma Access: Components Deep Dive

This document provides an in-depth look at the primary components of Prisma Access: Mobile Users (via GlobalProtect), Remote Networks, and Service Connections. Understanding the configuration, capabilities, and interactions of these components is essential for leveraging the Prisma Access SASE solution effectively.

Part 1: Mobile Users (GlobalProtect)

Prisma Access secures mobile users connecting from anywhere using the Palo Alto Networks GlobalProtect client. This provides secure VPN access combined with Zero Trust principles and the full suite of Prisma Access security services.

Connection Methods: GlobalProtect Client

The GlobalProtect client is the agent software installed on endpoint devices (laptops, mobile phones) that establishes a secure connection to Prisma Access.

• Supported Operating Systems: Windows, macOS, Linux (CLI support varies), iOS, Android, Chrome OS. Always check the compatibility matrix for specific OS versions.
• Core Features:
  • Establishes secure tunnels (SSL VPN or IPSec) to Prisma Access Gateways.
  • Supports various authentication methods.
  • Collects Host Information Profile (HIP) data for posture assessment.
  • Enforces security policy based on user, device, and location.
  • Provides connection status and basic troubleshooting logs.
  • Supports features like pre-logon, Always On VPN, on-demand connections.
• Authentication Methods: GlobalProtect leverages configured authentication profiles. Common methods used with Prisma Access include:
  • SAML: Preferred method for integration with cloud Identity Providers (IdPs) like Okta, Azure AD, Ping Identity. Enables Single Sign-On (SSO) and Multi-Factor Authentication (MFA) enforced by the IdP.
  • LDAP: Connects directly to Active Directory or other LDAP servers for username/password validation.
  • Kerberos: For seamless authentication in domain environments (less common for remote users compared to SAML).
  • RADIUS: Integrates with RADIUS servers, often used for MFA integration via protocols like PAP, CHAP, MS-CHAPv2.
  • Local User Database: Can use a locally defined database on Panorama/Prisma Access (generally used for testing or specific admin accounts).
  • Multi-Factor Authentication (MFA): Can be enforced via SAML IdP integration or directly using RADIUS integration with MFA vendors (e.g., Duo, RSA SecurID). Palo Alto Networks also offers its own MFA service.

Portal Configuration

The GlobalProtect Portal serves as the initial contact point for the GlobalProtect client. It authenticates the user, provides the client configuration (list of gateways, agent settings), and optionally pushes the client software.

High-Level Configuration Steps (Panorama-Managed Example):

Cloud-Managed Configuration: Similar concepts apply but are configured within the Prisma SASE UI under Manage > Configuration > Mobile Users > GlobalProtect .

GlobalProtect Portal/Gateway Connection Flow

This diagram shows the typical sequence when a GlobalProtect client connects.

        sequenceDiagram
            participant Client as GP Client
            participant Portal as GP Portal (Prisma Access)
            participant IdP as SAML IdP (Optional)
            participant Gateway as GP Gateway (Prisma Access)

            Client->>Portal: 1. Connect to Portal Address
            activate Portal
            Portal->>Client: 2. Request Authentication
            Client->>IdP: 3. Redirect to IdP for Auth (if SAML)
            activate IdP
            Note over Client, IdP: User Authenticates (SSO/MFA)
            IdP-->>Client: 4. SAML Assertion
            deactivate IdP
            Client->>Portal: 5. Submit Auth Credentials/Assertion
            Portal->>Portal: 6. Validate Credentials / Assertion
            Portal-->>Client: 7. Send Agent Config (Gateway List, HIP settings etc.) & Auth Cookie
            deactivate Portal

            Client->>Client: 8. Select Best Gateway (Latency)
            Client->>Gateway: 9. Connect to Gateway
            activate Gateway
            Gateway->>Client: 10. Request Auth Cookie / Credentials
            Client->>Gateway: 11. Send Auth Cookie / Credentials
            Gateway->>Gateway: 12. Validate Cookie / Auth
            Gateway-->>Client: 13. Authentication Success
            Client->>Gateway: 14. Submit HIP Report (if configured)
            Gateway->>Gateway: 15. Evaluate HIP / Policies
            Gateway-->>Client: 16. Establish Secure Tunnel (SSL/IPSec)
            deactivate Gateway
            Note over Client, Gateway: Secure Connection Established
     

Gateway Configuration

GlobalProtect Gateways are the termination points for the GlobalProtect VPN tunnels. They enforce security policy and provide access to resources.

• Automatic Deployment: In Prisma Access, Gateways are automatically deployed across the compute locations you select during onboarding based on user geography or specified regions. You don't manually configure individual gateway appliances.
• Gateway Selection Logic: The GlobalProtect client automatically selects the "best" available gateway based on:
  • Lowest Latency: The primary factor. The client probes configured gateways to determine the one with the lowest round-trip time.
  • Source Region Mapping (Optional): Administrators can define source regions and map them to preferred Prisma Access locations to influence gateway selection, though latency usually prevails.
  • Gateway Priority: Can be configured in the portal, but latency is typically the overriding factor.
• Configuration Settings (Panorama/Cloud): While deployment is automatic, you configure gateway settings within the Prisma Access setup:
  • Regions: Select the global regions where gateways should be deployed.
  • IP Pool Assignment: Assign the pre-defined IP address pool(s) from which connecting mobile users will receive IP addresses.
  • Tunnel Settings: Define tunnel parameters (e.g., prefer IPSec over SSL, tunnel lifetimes).
  • Client IP/DNS Settings: Configure DNS servers, domain suffixes to be pushed to clients.

Split Tunneling

Split tunneling determines which traffic from the endpoint goes through the GlobalProtect tunnel (and thus through Prisma Access for inspection) and which traffic goes directly to the internet via the user's local network interface.

• Purpose: Balance security with performance and local resource access. Avoid sending non-critical, trusted traffic (like streaming media) through the tunnel if not necessary.
• Configuration Options: Configured within the GlobalProtect Agent settings (often via the Portal config or specific Gateway config).
  • Tunnel All Traffic (No Split Tunnel): All traffic from the client is forced through the tunnel. Most secure, but impacts performance for local/direct internet needs. Prisma Access becomes the sole path to the internet.
  • Include Traffic: Only traffic destined for specified applications, domains, or IP address ranges goes through the tunnel. All other traffic goes direct.
  • Exclude Traffic: All traffic goes through the tunnel *except* for traffic destined for specified applications, domains, or IP address ranges.
    • Exclude by Application: Use PAN-OS App-IDs (e.g., exclude `microsoft-teams`, `zoom-meeting`). Recommended method.
    • Exclude by Domain/FQDN: Exclude specific domain names (e.g., `*.netflix.com`, `youtube.com`). Requires client DNS resolution.
    • Exclude by IP Address/Range: Exclude specific destination IP addresses or subnets.
    • Exclude Video Streaming Apps: A specific checkbox often exists to easily exclude common video streaming services based on App-ID.
• Security Implications:
  • Traffic that is split tunneled (goes direct) bypasses Prisma Access security inspection (FWaaS, SWG, Threat Prevention, DLP).
  • Carefully consider which applications/destinations are safe to exclude. Typically used for high-bandwidth, trusted services or access to local network resources (like printers).
  • "Tunnel All" provides maximum visibility and security but may impact performance.
• Use Cases:
  • Exclude: Allow direct access to streaming media, specific SaaS apps not requiring inspection, local network printers/devices.
  • Include: Ensure all corporate resource access (via Service Connections) and sensitive internet traffic goes through Prisma Access inspection.

HIP (Host Information Profile)

HIP allows Prisma Access to assess the security posture of the connecting endpoint and enforce policy based on that posture. It's a core component of Zero Trust Network Access (ZTNA).

• Data Collection: The GlobalProtect client collects various details about the endpoint, such as:
  • Operating System version and patch level.
  • Presence and status of Antivirus software (specific vendors, real-time protection status, definition versions).
  • Presence and status of Anti-Spyware software.
  • Presence and status of Disk Encryption (e.g., BitLocker, FileVault).
  • Firewall status (enabled/disabled).
  • Specific files, registry keys, or processes present on the system.
  • Domain membership.
  • Installed patches (via specific KB numbers).
  • Custom attributes defined by scripts.
• HIP Objects: Define the specific criteria you want to check (e.g., "Antivirus = Symantec", "Real-time Protection = Enabled", "OS = Windows 10 build X or later").
• HIP Profiles: Group multiple HIP Objects together logically (e.g., "Compliant Windows Devices" profile requires specific OS, AV, and Disk Encryption objects to match).
• Policy Enforcement: Use HIP Profiles as match criteria in Security Policy rules:
  • Allow compliant devices full access.
  • Allow non-compliant devices limited access (e.g., only to remediation resources).
  • Deny access to non-compliant devices.
  • Apply different Threat Prevention profiles based on compliance.
• Quarantine Actions (via Security Policy): While not a direct HIP action, security rules matching non-compliant HIP profiles can redirect users to a remediation portal or restrict access until the device meets compliance requirements.
• Configuration:
  1. Enable HIP Data Collection in the GP Agent settings (Portal/Gateway).
  2. Define HIP Objects (Panorama/Cloud Management > Objects > GlobalProtect > HIP Objects).
  3. Define HIP Profiles (Panorama/Cloud Management > Objects > GlobalProtect > HIP Profiles).
  4. Use HIP Profiles in Security Policy Rules (Panorama/Cloud Management > Policies > Security).
  5. Configure HIP Match Logs forwarding (part of standard log forwarding).

HIP Check and Enforcement Flow

This diagram illustrates how HIP information is collected and used in policy.

    
    
    
    
    
    



    
Prisma Access: Components Deep Dive

    
This document provides an in-depth look at the primary components of Prisma Access: Mobile Users (via GlobalProtect), Remote Networks, and Service Connections. Understanding the configuration, capabilities, and interactions of these components is essential for leveraging the Prisma Access SASE solution effectively.

    
    
Part 1: Mobile Users (GlobalProtect)
    
    
Prisma Access secures mobile users connecting from anywhere using the Palo Alto Networks GlobalProtect client. This provides secure VPN access combined with Zero Trust principles and the full suite of Prisma Access security services.

    
Connection Methods: GlobalProtect Client
    
The GlobalProtect client is the agent software installed on endpoint devices (laptops, mobile phones) that establishes a secure connection to Prisma Access.
    

        
Supported Operating Systems: Windows, macOS, Linux (CLI support varies), iOS, Android, Chrome OS. Always check the compatibility matrix for specific OS versions.
        
Core Features:
            

                
Establishes secure tunnels (SSL VPN or IPSec) to Prisma Access Gateways.
                
Supports various authentication methods.
                
Collects Host Information Profile (HIP) data for posture assessment.
                
Enforces security policy based on user, device, and location.
                
Provides connection status and basic troubleshooting logs.
                
Supports features like pre-logon, Always On VPN, on-demand connections.
            
        
        
Authentication Methods: GlobalProtect leverages configured authentication profiles. Common methods used with Prisma Access include:
            

                
SAML: Preferred method for integration with cloud Identity Providers (IdPs) like Okta, Azure AD, Ping Identity. Enables Single Sign-On (SSO) and Multi-Factor Authentication (MFA) enforced by the IdP.
                
LDAP: Connects directly to Active Directory or other LDAP servers for username/password validation.
                
Kerberos: For seamless authentication in domain environments (less common for remote users compared to SAML).
                
RADIUS: Integrates with RADIUS servers, often used for MFA integration via protocols like PAP, CHAP, MS-CHAPv2.
                
Local User Database: Can use a locally defined database on Panorama/Prisma Access (generally used for testing or specific admin accounts).
                
Multi-Factor Authentication (MFA): Can be enforced via SAML IdP integration or directly using RADIUS integration with MFA vendors (e.g., Duo, RSA SecurID). Palo Alto Networks also offers its own MFA service.
            
        
    

    
Portal Configuration
    
The GlobalProtect Portal serves as the initial contact point for the GlobalProtect client. It authenticates the user, provides the client configuration (list of gateways, agent settings), and optionally pushes the client software.

    
High-Level Configuration Steps (Panorama-Managed Example):
    

        

            
Navigate to Panorama > Cloud Services > Configuration > Mobile Users > GlobalProtect Portal.
            
Define Portal Settings: Name, Interface (usually loopback within Prisma Access template), IP address.
            
Configure Authentication: Create/select Authentication Profile(s) (e.g., SAML, LDAP) and Authentication Cookies for seamless gateway connection.
            
Configure Agent Settings: Define client behavior (connect method - Always-On, User-Logon, Pre-Logon, On-Demand), external gateways list (auto-populated by Prisma Access), trusted root CAs, split tunnel settings (if defined here), HIP notification settings.
            
Client Software Deployment (Optional): Upload and configure GP client versions to be deployed via the portal.
            
Assign to Template Stack: Ensure the Portal configuration is part of the relevant Template Stack applied to Mobile Users.
            
Commit and Push: Commit changes to Panorama and push to the Cloud Services plugin.
        
    
     
Cloud-Managed Configuration: Similar concepts apply but are configured within the Prisma SASE UI under Manage > Configuration > Mobile Users > GlobalProtect.

     
GlobalProtect Portal/Gateway Connection Flow
     
This diagram shows the typical sequence when a GlobalProtect client connects.
     
        sequenceDiagram
            participant Client as GP Client
            participant Portal as GP Portal (Prisma Access)
            participant IdP as SAML IdP (Optional)
            participant Gateway as GP Gateway (Prisma Access)

            Client->>Portal: 1. Connect to Portal Address
            activate Portal
            Portal->>Client: 2. Request Authentication
            Client->>IdP: 3. Redirect to IdP for Auth (if SAML)
            activate IdP
            Note over Client, IdP: User Authenticates (SSO/MFA)
            IdP-->>Client: 4. SAML Assertion
            deactivate IdP
            Client->>Portal: 5. Submit Auth Credentials/Assertion
            Portal->>Portal: 6. Validate Credentials / Assertion
            Portal-->>Client: 7. Send Agent Config (Gateway List, HIP settings etc.) & Auth Cookie
            deactivate Portal

            Client->>Client: 8. Select Best Gateway (Latency)
            Client->>Gateway: 9. Connect to Gateway
            activate Gateway
            Gateway->>Client: 10. Request Auth Cookie / Credentials
            Client->>Gateway: 11. Send Auth Cookie / Credentials
            Gateway->>Gateway: 12. Validate Cookie / Auth
            Gateway-->>Client: 13. Authentication Success
            Client->>Gateway: 14. Submit HIP Report (if configured)
            Gateway->>Gateway: 15. Evaluate HIP / Policies
            Gateway-->>Client: 16. Establish Secure Tunnel (SSL/IPSec)
            deactivate Gateway
            Note over Client, Gateway: Secure Connection Established
     


    
Gateway Configuration
    
GlobalProtect Gateways are the termination points for the GlobalProtect VPN tunnels. They enforce security policy and provide access to resources.
    

        
Automatic Deployment: In Prisma Access, Gateways are automatically deployed across the compute locations you select during onboarding based on user geography or specified regions. You don't manually configure individual gateway appliances.
        
Gateway Selection Logic: The GlobalProtect client automatically selects the "best" available gateway based on:
            

                
Lowest Latency: The primary factor. The client probes configured gateways to determine the one with the lowest round-trip time.
                
Source Region Mapping (Optional): Administrators can define source regions and map them to preferred Prisma Access locations to influence gateway selection, though latency usually prevails.
                
Gateway Priority: Can be configured in the portal, but latency is typically the overriding factor.
            
        
        
Configuration Settings (Panorama/Cloud): While deployment is automatic, you configure gateway settings within the Prisma Access setup:
            

                
Regions: Select the global regions where gateways should be deployed.
                
IP Pool Assignment: Assign the pre-defined IP address pool(s) from which connecting mobile users will receive IP addresses.
                
Tunnel Settings: Define tunnel parameters (e.g., prefer IPSec over SSL, tunnel lifetimes).
                
Client IP/DNS Settings: Configure DNS servers, domain suffixes to be pushed to clients.
            
        
    

    
Split Tunneling
    
Split tunneling determines which traffic from the endpoint goes through the GlobalProtect tunnel (and thus through Prisma Access for inspection) and which traffic goes directly to the internet via the user's local network interface.
    

        
Purpose: Balance security with performance and local resource access. Avoid sending non-critical, trusted traffic (like streaming media) through the tunnel if not necessary.
        
Configuration Options: Configured within the GlobalProtect Agent settings (often via the Portal config or specific Gateway config).
            

                
Tunnel All Traffic (No Split Tunnel): All traffic from the client is forced through the tunnel. Most secure, but impacts performance for local/direct internet needs. Prisma Access becomes the sole path to the internet.
                
Include Traffic: Only traffic destined for specified applications, domains, or IP address ranges goes through the tunnel. All other traffic goes direct.
                
Exclude Traffic: All traffic goes through the tunnel *except* for traffic destined for specified applications, domains, or IP address ranges.
                    

                        
Exclude by Application: Use PAN-OS App-IDs (e.g., exclude `microsoft-teams`, `zoom-meeting`). Recommended method.
                        
Exclude by Domain/FQDN: Exclude specific domain names (e.g., `*.netflix.com`, `youtube.com`). Requires client DNS resolution.
                        
Exclude by IP Address/Range: Exclude specific destination IP addresses or subnets.
                        
Exclude Video Streaming Apps: A specific checkbox often exists to easily exclude common video streaming services based on App-ID.
                    
                
            
        
        
Security Implications:
            

                
Traffic that is split tunneled (goes direct) bypasses Prisma Access security inspection (FWaaS, SWG, Threat Prevention, DLP).
                
Carefully consider which applications/destinations are safe to exclude. Typically used for high-bandwidth, trusted services or access to local network resources (like printers).
                
"Tunnel All" provides maximum visibility and security but may impact performance.
            
        
        
Use Cases:
            

                
Exclude: Allow direct access to streaming media, specific SaaS apps not requiring inspection, local network printers/devices.
                
Include: Ensure all corporate resource access (via Service Connections) and sensitive internet traffic goes through Prisma Access inspection.
            
        
    

    
HIP (Host Information Profile)
    
HIP allows Prisma Access to assess the security posture of the connecting endpoint and enforce policy based on that posture. It's a core component of Zero Trust Network Access (ZTNA).
    

        
Data Collection: The GlobalProtect client collects various details about the endpoint, such as:
            

                
Operating System version and patch level.
                
Presence and status of Antivirus software (specific vendors, real-time protection status, definition versions).
                
Presence and status of Anti-Spyware software.
                
Presence and status of Disk Encryption (e.g., BitLocker, FileVault).
                
Firewall status (enabled/disabled).
                
Specific files, registry keys, or processes present on the system.
                
Domain membership.
                
Installed patches (via specific KB numbers).
                
Custom attributes defined by scripts.
            
        
        
HIP Objects: Define the specific criteria you want to check (e.g., "Antivirus = Symantec", "Real-time Protection = Enabled", "OS = Windows 10 build X or later").
        
HIP Profiles: Group multiple HIP Objects together logically (e.g., "Compliant Windows Devices" profile requires specific OS, AV, and Disk Encryption objects to match).
        
Policy Enforcement: Use HIP Profiles as match criteria in Security Policy rules:
            

                
Allow compliant devices full access.
                
Allow non-compliant devices limited access (e.g., only to remediation resources).
                
Deny access to non-compliant devices.
                
Apply different Threat Prevention profiles based on compliance.
            
        
        
Quarantine Actions (via Security Policy): While not a direct HIP action, security rules matching non-compliant HIP profiles can redirect users to a remediation portal or restrict access until the device meets compliance requirements.
        
Configuration:
            

                
Enable HIP Data Collection in the GP Agent settings (Portal/Gateway).
                
Define HIP Objects (Panorama/Cloud Management > Objects > GlobalProtect > HIP Objects).
                
Define HIP Profiles (Panorama/Cloud Management > Objects > GlobalProtect > HIP Profiles).
                
Use HIP Profiles in Security Policy Rules (Panorama/Cloud Management > Policies > Security).
                
Configure HIP Match Logs forwarding (part of standard log forwarding).
            
        
    

    
HIP Check and Enforcement Flow
    
This diagram illustrates how HIP information is collected and used in policy.
    
flowchart TD
    A[GP Client Connects to Gateway] --> B{HIP Data Collection Enabled?}
    B -- Yes --> C[Client Collects HIP Data]
    B -- No --> G[Proceed without HIP Check]
    C --> D[Client Submits HIP Report to Gateway]
    D --> E{Gateway Evaluates HIP Report against HIP Profiles}
    E -- Match Compliant Profile --> F[Policy Rule Allows Access based on HIP Profile]
    E -- Match Non-Compliant Profile --> H[Policy Rule Blocks/Limits Access based on HIP Profile]
    E -- No Match --> I[Policy Rule Handles No Match - Default Allow/Deny]
    F --> J[User Granted Appropriate Access]
    H --> J
    I --> J
    G --> J
    

    
User-ID Integration
    
User-ID allows Prisma Access to enforce policy based on user identity and group membership, not just IP address. This is fundamental for Zero Trust and granular access control.
    

        
Information Gathering Methods for Mobile Users:
            

                
GlobalProtect Login: When users authenticate to the Portal/Gateway, Prisma Access automatically creates an IP-to-User mapping based on the successful authentication event (SAML assertion username, LDAP username, etc.). This is the primary method for MU.
                
SAML Assertion Attributes (IdP Integration): User identity and potentially group membership can be passed directly from the SAML IdP (like Azure AD, Okta) to Prisma Access during authentication. This requires configuring attribute mapping in the SAML Authentication profile.
            
        
        
Group Mapping: To use Active Directory or LDAP groups in policy, Prisma Access needs to map users to their groups. This is configured via:
            

                
Panorama LDAP Integration: Panorama connects directly to an LDAP server (e.g., AD Domain Controller) to query group memberships for authenticated users. (Common in Panorama-managed setups).
                
Cloud Identity Engine (CIE): A Palo Alto Networks cloud service that synchronizes user/group information from sources like Azure AD, Okta, or AD (via agents) and provides it to Prisma Access (Common in Cloud-managed setups, also usable with Panorama).
                
SAML Group Attributes: Group membership information can be included in the SAML assertion sent by the IdP.
            
        
        
User-ID Redistribution (Less Common for MU Directly): While possible, redistributing User-ID mappings learned by on-prem firewalls/agents to Prisma Access is more typical for traffic originating from Remote Networks or accessing internal resources via Service Connections, not the initial MU connection itself.
        
Policy Enforcement: Once IP-to-User-to-Group mappings exist, Security Policy rules can use usernames or group names in the `Source User` field for granular control.
    

     
User-ID Acquisition and Group Mapping (Conceptual)
     
This shows how User-ID and Group info come together for policy.
     
        graph TD
            subgraph Authentication & ID Sources
                A[GP Login (SAML/LDAP etc.)] --> C{User Authenticates};
                B[SAML Assertion Attributes] --> C;
            end

            subgraph Group Information Sources
                D[Panorama LDAP Query] --> F{Group Mapping Service};
                E[Cloud Identity Engine (CIE)] --> F;
                G[SAML Group Attributes] --> F;
            end

            subgraph Prisma Access / Policy Engine
                C -- Username --> H(IP-to-User Mapping);
                F -- Groups --> I(User-to-Group Mapping);
                H --> K{Security Policy Engine};
                I --> K;
                J[User Traffic] --> K;
                K -- Matched Rule --> L[Allow/Deny/Apply Profiles];
            end
     


    
Clientless VPN
    
Clientless VPN provides access to specific internal web applications through the GlobalProtect Portal web interface without requiring the full GlobalProtect client installation.
    

        
Use Case: Suitable for accessing simple, internal web applications (like intranets, wikis, specific web tools) from unmanaged devices or where client installation is not feasible/desired. Typically used for limited, specific application access.
        
Mechanism: Users log into the GP Portal via a web browser. The Portal acts as a reverse proxy, fetching the content from the internal web application (usually via a Service Connection) and presenting it to the user within their browser session.
        
Configuration: Enabled within the GlobalProtect Portal configuration. Requires defining the specific internal web applications (URLs, hostnames) that will be accessible via this method.
        
Limitations:
            

                
Only supports web-based protocols (HTTP/HTTPS).
                
May have compatibility issues with complex web applications using dynamic content, Java applets, or extensive JavaScript.
                
Does not provide full network-level access like the GP client.
                
No HIP check capabilities for the connecting endpoint.
            
        
    


    
    
Part 2: Remote Networks
    
    
Remote Networks connect entire branch offices or sites to Prisma Access using site-to-site VPN tunnels, typically IPSec. This allows all traffic from the branch to be secured by Prisma Access.

    
Onboarding Process
    
Adding a remote network involves configuring the connection parameters in Prisma Access and setting up the corresponding VPN tunnel on the branch office firewall or router.

    
High-Level Onboarding Steps (Panorama-Managed Example):
     

        

            
Gather Site Information: Branch public IP address, internal subnets, BGP ASN (if using BGP), desired bandwidth.
            
Panorama Configuration:
                

                    
Navigate to Panorama > Cloud Services > Configuration > Remote Networks.
                    
Click 'Add' to start the onboarding wizard.
                    
Enter Site Name, Location (for latency/PoP selection), Bandwidth Allocation.
                    
Configure Tunnel Settings: Select IKE/IPSec profiles (or use defaults), enter Pre-Shared Key (PSK) or configure certificate-based authentication. Define local and peer identification.
                    
Configure Routing: Select BGP or Static routing. If BGP, configure BGP peering IPs (Prisma Access side often auto-assigned), Peer ASN, local ASN. If Static, define routes to be advertised from Prisma Access to the site (less common).
                    
Define Subnets: Specify the internal subnets behind the branch device that Prisma Access needs to learn routes for (usually advertised via BGP).
                    
Assign to appropriate Template Stack and Device Group.
                
            
            
Branch Device Configuration: Configure a matching IPSec VPN tunnel on the branch firewall/router using the same parameters (PSK, crypto profiles, tunnel interface IPs, BGP settings).
            
Commit and Push (Panorama): Save changes and push to Prisma Access.
            
Verification: Monitor tunnel status in Prisma Access (Insights/Monitor tab) and on the branch device. Check BGP peering status and route propagation.
        
    
     
Cloud-Managed Configuration: Similar concepts, configured via the Prisma SASE UI under Manage > Configuration > Remote Networks.

     
Remote Network Onboarding & Connection Flow
     
flowchart TD
    A[Start: Define RN in Panorama/Cloud] --> B(Specify Location, Bandwidth, Subnets)
    B --> C(Configure IPSec Parameters - PSK/Cert, Crypto)
    C --> D{Configure Routing}
    D -- BGP --> E(Define BGP Peer IP/ASN)
    D -- Static --> F(Define Static Routes - Less Common)
    E --> G[Assign to Template/Device Group]
    F --> G
    G --> H(Commit & Push to Prisma Access)
    H --> I{Prisma Access Provisions Tunnel Endpoint}
    J[Configure Matching IPSec/BGP on Branch Device] --> K{Branch Initiates Tunnel / Prisma Access Initiates}
    I --> K
    K --> L{IPSec Phase 1 IKE SA Negotiation}
    L -- Success --> M{IPSec Phase 2 IPSec SA Negotiation}
    M -- Success --> N{Tunnel Established}
    N -- BGP Configured --> O{BGP Peering Established}
    O -- Routes Exchanged --> P[End: Secure Connectivity Established]
    N -- Static Configured --> P

     

    
IPSec Tunnel Configuration
    
Establishing a stable and secure IPSec tunnel is critical for Remote Network connectivity.
    

        
IKE Versions: Supports IKEv1 and IKEv2. IKEv2 is generally recommended due to improved security, reliability (built-in keepalives), and efficiency.
        
Phase 1 (IKE SA - Management Connection): Establishes a secure channel for negotiating the actual data tunnels.
            

                
Key Parameters: IKE Crypto Profile (Encryption: AES-128/256-GCM preferred; Authentication: SHA-256/384/512; DH Group: 14, 19, 20, 21 recommended), Authentication Method (Pre-Shared Key or Certificates), Lifetimes, NAT Traversal (if needed).
            
        
         
Phase 2 (IPSec SA - Data Connection): Defines how the actual user data is encrypted and authenticated.
            

                
Key Parameters: IPSec Crypto Profile (Encryption: AES-128/256-GCM preferred; Authentication: SHA-256/384/512 or None if using GCM; ESP - Tunnel Mode), Lifetimes (typically shorter than Phase 1), Perfect Forward Secrecy (PFS using DH Group matching Phase 1 or stronger recommended).
                
Proxy IDs / Traffic Selectors (Policy-Based VPN): Defines which source/destination subnets are allowed through the tunnel. **Note:** Prisma Access generally prefers **Route-Based VPNs** (using BGP/Static routes over a numbered tunnel interface) where Proxy IDs are typically set to 0.0.0.0/0 for both source and destination, allowing routing protocols to manage traffic flow. Avoid specific Proxy IDs unless required for interop with legacy policy-based VPN devices.
            
        
        
Authentication:
            

                
Pre-Shared Keys (PSK): Simpler to configure but requires secure key management. Use strong, unique keys per tunnel.
                
Certificates: More scalable and secure. Requires a Public Key Infrastructure (PKI) to issue and manage certificates for Prisma Access and the branch device.
            
        
        
Dead Peer Detection (DPD): Mechanism to detect if the VPN peer is unresponsive, allowing for faster failover. Recommended to enable.
        
Interoperability: Palo Alto Networks provides vendor-specific guides for configuring tunnels with common third-party firewall/router vendors. Ensuring matching parameters (crypto, lifetimes, DH groups, IKE version) is crucial.
    

     
Simplified IPSec Tunnel Establishment
     
        sequenceDiagram
            participant Initiator as Branch Device
            participant Responder as Prisma Access RN Endpoint

            Initiator->>Responder: 1. Initiate IKE Phase 1 (Propose Crypto, DH Key)
            activate Responder
            Responder->>Initiator: 2. Respond (Agree on Crypto, DH Key, Authenticate - PSK/Cert)
            activate Initiator
            Note over Initiator, Responder: IKE SA (Phase 1 Tunnel) Established
            Initiator->>Responder: 3. Initiate IKE Phase 2 (Propose IPSec Params, ProxyIDs/Selectors)
            Responder->>Initiator: 4. Respond (Agree on IPSec Params)
            deactivate Responder
            deactivate Initiator
            Note over Initiator, Responder: IPSec SA (Phase 2 Data Tunnel) Established
     


    
Routing: BGP vs Static
    
Routing determines how Prisma Access and the remote network site exchange information about reachable subnets.
    

        
BGP (Border Gateway Protocol):
            

                
Recommended Method: More dynamic, scalable, and resilient than static routing.
                
Mechanism: Prisma Access and the branch device become BGP peers over the IPSec tunnel. They dynamically advertise their local subnets to each other.
                
Configuration: Requires configuring BGP settings on both ends: Autonomous System Numbers (ASNs - Prisma Access typically uses a private ASN, branch uses its own public/private ASN), neighbor IP addresses (tunnel interface IPs), timers, route advertisement filters (optional).
                
Advantages: Automatic route updates if network topology changes, better support for redundant tunnels (ECMP or failover based on BGP metrics).
            
        
         
Static Routing:
            

                
Mechanism: Manually define static routes on both Prisma Access and the branch device.
                
Prisma Access Config: You define static routes pointing to the branch subnets via the tunnel interface.
                
Branch Device Config: You define static routes pointing to Prisma Access resources (e.g., default route or specific routes for mobile user pools/other connected sites) via the tunnel interface.
                
Disadvantages: Requires manual updates if network changes, less scalable, harder to manage redundancy (may require IP SLA tracking or similar mechanisms on the branch device).
                
Use Case: Simpler setups, branches with very few subnets, devices with limited BGP support.
            
        
    

    
Bandwidth Allocation
    

        
Per-Site Bandwidth: Assign a fixed bandwidth amount (e.g., 50 Mbps, 200 Mbps) during onboarding. This site cannot exceed this limit. Enforced by Prisma Access.
        
Aggregate Bandwidth Pool: Purchase a large pool (e.g., 1 Gbps, 10 Gbps) shared across multiple Remote Network sites. Sites can dynamically use bandwidth up to the aggregate limit. Requires monitoring aggregate usage via Prisma Access Insights.
        
Monitoring: Prisma Access Insights provides dashboards to track bandwidth utilization per site and for the aggregate pool. Set up alerts for high utilization.
    

    
High Availability (HA)
    
Ensuring continuous connectivity for Remote Networks is critical.
    

        
Redundant Tunnels: Configure two separate IPSec tunnels from the branch device to Prisma Access. This can be:
            

                
To the same Prisma Access compute location (provides PoP-level redundancy against tunnel/link failure).
                
To different Prisma Access compute locations (provides geographic redundancy against PoP failure).
            
        
         
Failover Mechanisms:
            

                
BGP-Based Failover: The preferred method. Use BGP metrics (e.g., AS-Path Prepending, MEDs, Local Preference) to prefer one tunnel over the other. If the primary tunnel fails, BGP reconverges and routes traffic over the secondary tunnel automatically. Can also support Equal-Cost Multi-Path (ECMP) if tunnels have equal BGP cost, load-sharing traffic.
                
Static Route + Monitoring: If using static routes, the branch device needs a mechanism (like IP SLA tracking, tunnel monitoring) to detect primary tunnel failure and switch traffic to the secondary tunnel's static route. Less reliable than BGP.
            
        
        
Branch Device Redundancy: For full site redundancy, use redundant firewalls/routers at the branch in an HA pair.
    

    
Integration with SD-WAN
    

        
Prisma Access as SD-WAN Hub: Branches using third-party SD-WAN can establish secure tunnels (IPSec) to Prisma Access. Prisma Access acts as a secure internet gateway and potentially an inter-branch communication hub (depending on topology). SD-WAN overlay tunnels typically run inside the Prisma Access IPSec tunnels.
        
Prisma SD-WAN Integration: Palo Alto Networks offers Prisma SD-WAN (formerly CloudGenix). When used together:
            

                
Integration is tighter, often managed via the unified Prisma SASE UI.
                
Prisma SD-WAN devices (ION) can automatically establish secure fabric links to the nearest Prisma Access PoPs.
                
Provides application-aware path selection, directing traffic optimally either directly to the internet, to Prisma Access for security, or over the SD-WAN fabric to other sites/datacenters.
            
        
        
Benefits: Combines application performance optimization (SD-WAN) with comprehensive cloud-delivered security (Prisma Access).
    

    
    
Part 3: Service Connections
    
    
Service Connections link your existing datacenters, headquarters, or IaaS environments (like AWS VPCs, Azure VNets) securely to the Prisma Access cloud fabric. They allow users connected to Prisma Access (Mobile Users, Remote Networks) to access internal corporate resources.

    
Purpose
    

        
Access Internal Resources: The primary goal is to provide Prisma Access users secure access to applications, servers, and services hosted within the corporate network (datacenters, private clouds).
        
Facilitate User-ID Redistribution: Allows Prisma Access to leverage User-ID information learned by agents or firewalls within the corporate network (requires specific configuration).
        
Hybrid Connectivity: Creates a secure bridge between the cloud-native Prisma Access environment and traditional network infrastructure.
    

    
Configuration
    
Configuration is very similar to Remote Networks but often involves higher bandwidth and redundancy requirements.
    

        
IPSec Tunnels: Use standard IPSec VPN tunnels (IKEv1/IKEv2) established between Prisma Access (specifically the CANs) and the firewall/router at the datacenter edge.
        
BGP Routing: BGP is **highly recommended** (and often implicitly required) for Service Connections to dynamically exchange routes between Prisma Access and the corporate network. Static routes are generally not suitable for the dynamic nature of datacenter environments.
        
High Bandwidth: Service Connections typically require significantly more bandwidth allocation than individual Remote Networks, as they aggregate traffic from potentially many users/sites accessing internal resources. Bandwidth is purchased as part of the Prisma Access subscription.
        
Redundancy: Configuring redundant Service Connections (multiple tunnels, potentially to different Prisma Access PoPs and/or different datacenter firewalls) is critical for high availability. BGP is used for failover or ECMP load sharing across these tunnels.
        
Key Parameters (Panorama/Cloud): Similar to Remote Networks - Specify location, bandwidth, IPSec settings (PSK/Cert, Crypto Profiles), and BGP configuration (Peer/Local ASN, neighbor IPs).
    

    
Routing Considerations
    

        
Route Exchange via BGP:
            

                
Prisma Access Advertises: Advertises the IP pools allocated to Mobile Users and potentially subnets from connected Remote Networks (if configured) to the corporate network via BGP.
                
Corporate Network Advertises: The datacenter firewall/router advertises internal corporate subnets (e.g., server VLANs, internal application networks) to Prisma Access via BGP.
            
        
        
Route Filtering & Summarization: Use BGP route maps or prefix lists on the datacenter firewall (and potentially within Prisma Access BGP config) to:
            

                
Filter which specific routes are advertised in each direction.
                
Summarize routes to reduce the size of the routing table and improve stability.
            
        
        
Traffic Flow: When a mobile user requests an internal IP, Prisma Access routes the traffic through the SPN, then internally to the CAN, over the appropriate Service Connection tunnel to the datacenter firewall, and finally to the internal resource. Return traffic follows the reverse path.
    

    
Service Connection Traffic Flow & Routing (Conceptual)
     
        graph LR
            subgraph Prisma Access User/Site
                A[MU/RN User Request for Internal IP]
            end
            subgraph Prisma Access Cloud Fabric
                B(SPN - Security Policy Applied)
                C{Routing Decision};
                D(CAN - Corporate Access Node);
                E[Service Connection IPSec Tunnel];
            end
            subgraph Corporate Datacenter
                F(Datacenter Edge Firewall/Router);
                G{Internal Routing};
                H[Internal Server/Resource];
                I(BGP Peer);
            end

            A --> B;
            B --> C;
            C -- Route Learned via BGP --> D;
            D --> E;
            E --> F;
            F -- Decrypt & Route --> G;
            G --> H;

            %% Link BGP components
            D -. BGP Peering .- I;
            I --> F; %% BGP runs on the FW/Router

            %% Return Path (Simplified)
             H --> G;
             G --> F;
             F --> E;
             E --> D;
             D --> C;
             C --> B;
             B --> A;
     

    
Use Cases
    

        
Accessing Internal Web Apps & Databases: Securely connect mobile users to internal portals, ERP systems, file shares, etc.
        
Hybrid Cloud: Connect Prisma Access users to resources running in IaaS environments (AWS, Azure, GCP) that are linked to the corporate network.
        
User-ID Redistribution Point: Configure the datacenter firewall connected via the Service Connection to redistribute User-ID mappings (learned from internal agents like Domain Controllers) to Prisma Access. This helps identify users accessing internal resources even if the initial mapping was lost.
        
Centralized Services: Access internal DNS servers, authentication servers (e.g., internal RADIUS), or other shared services located in the datacenter.
    
    

        Important: Proper IP address planning is critical. Ensure Mobile User IP pools do not overlap with internal corporate subnets advertised over Service Connections.
    

    
    
Part 4: Clean Pipe Service (Optional)
    
    
The Clean Pipe service is a specific Prisma Access offering targeted primarily at **Service Providers (SPs)**.
    

        
Purpose: Allows SPs to offer managed security services to their downstream customers. The SP routes their customer traffic through Prisma Access for security inspection (threat prevention, URL filtering, etc.) before delivering it to the internet or the customer's network.
        
Architecture: Involves specific onboarding and routing configurations where the SP establishes high-bandwidth connections (often using Service Connections or specialized links) to Prisma Access. Prisma Access acts as a centralized "scrubbing center" for the SP's customer traffic.
        
Management: Typically managed by the Service Provider, who then offers security packages to their end customers.
        
Details: Specific architecture, configuration, and licensing differ from the standard enterprise Prisma Access model and require consultation with Palo Alto Networks.
    




    

User-ID Integration

User-ID allows Prisma Access to enforce policy based on user identity and group membership, not just IP address. This is fundamental for Zero Trust and granular access control.

• Information Gathering Methods for Mobile Users:
  • GlobalProtect Login: When users authenticate to the Portal/Gateway, Prisma Access automatically creates an IP-to-User mapping based on the successful authentication event (SAML assertion username, LDAP username, etc.). This is the primary method for MU.
  • SAML Assertion Attributes (IdP Integration): User identity and potentially group membership can be passed directly from the SAML IdP (like Azure AD, Okta) to Prisma Access during authentication. This requires configuring attribute mapping in the SAML Authentication profile.
• Group Mapping: To use Active Directory or LDAP groups in policy, Prisma Access needs to map users to their groups. This is configured via:
  • Panorama LDAP Integration: Panorama connects directly to an LDAP server (e.g., AD Domain Controller) to query group memberships for authenticated users. (Common in Panorama-managed setups).
  • Cloud Identity Engine (CIE): A Palo Alto Networks cloud service that synchronizes user/group information from sources like Azure AD, Okta, or AD (via agents) and provides it to Prisma Access (Common in Cloud-managed setups, also usable with Panorama).
  • SAML Group Attributes: Group membership information can be included in the SAML assertion sent by the IdP.
• User-ID Redistribution (Less Common for MU Directly): While possible, redistributing User-ID mappings learned by on-prem firewalls/agents to Prisma Access is more typical for traffic originating from Remote Networks or accessing internal resources via Service Connections, not the initial MU connection itself.
• Policy Enforcement: Once IP-to-User-to-Group mappings exist, Security Policy rules can use usernames or group names in the `Source User` field for granular control.

User-ID Acquisition and Group Mapping (Conceptual)

This shows how User-ID and Group info come together for policy.

graph TD
    subgraph Authentication_ID_Sources
        A[GP Login SAML/LDAP etc.] --> C{User Authenticates};
        B[SAML Assertion Attributes] --> C;
    end

    subgraph Group_Information_Sources
        D[Panorama LDAP Query] --> F{Group Mapping Service};
        E[Cloud Identity Engine CIE] --> F;
        G[SAML Group Attributes] --> F;
    end

    subgraph Prisma_Access_Policy_Engine
        C -- Username --> H(IP-to-User Mapping);
        F -- Groups --> I(User-to-Group Mapping);
        H --> K{Security Policy Engine};
        I --> K;
        J[User Traffic] --> K;
        K -- Matched Rule --> L[Allow/Deny/Apply Profiles];
    end

     

Clientless VPN

Clientless VPN provides access to specific internal web applications through the GlobalProtect Portal web interface without requiring the full GlobalProtect client installation.

• Use Case: Suitable for accessing simple, internal web applications (like intranets, wikis, specific web tools) from unmanaged devices or where client installation is not feasible/desired. Typically used for limited, specific application access.
• Mechanism: Users log into the GP Portal via a web browser. The Portal acts as a reverse proxy, fetching the content from the internal web application (usually via a Service Connection) and presenting it to the user within their browser session.
• Configuration: Enabled within the GlobalProtect Portal configuration. Requires defining the specific internal web applications (URLs, hostnames) that will be accessible via this method.
• Limitations:
  • Only supports web-based protocols (HTTP/HTTPS).
  • May have compatibility issues with complex web applications using dynamic content, Java applets, or extensive JavaScript.
  • Does not provide full network-level access like the GP client.
  • No HIP check capabilities for the connecting endpoint.

Part 2: Remote Networks

Remote Networks connect entire branch offices or sites to Prisma Access using site-to-site VPN tunnels, typically IPSec. This allows all traffic from the branch to be secured by Prisma Access.

Onboarding Process

Adding a remote network involves configuring the connection parameters in Prisma Access and setting up the corresponding VPN tunnel on the branch office firewall or router.

High-Level Onboarding Steps (Panorama-Managed Example):

Cloud-Managed Configuration: Similar concepts, configured via the Prisma SASE UI under Manage > Configuration > Remote Networks .

Remote Network Onboarding & Connection Flow

        graph TD
            A[Start: Define RN in Panorama/Cloud] --> B(Specify Location, Bandwidth, Subnets);
            B --> C(Configure IPSec Parameters - PSK/Cert, Crypto);
            C --> D{Configure Routing (BGP/Static)};
            D -- BGP --> E(Define BGP Peer IP/ASN);
            D -- Static --> F(Define Static Routes - Less Common);
            E --> G[Assign to Template/Device Group];
            F --> G;
            G --> H(Commit & Push to Prisma Access);
            H --> I{Prisma Access Provisions Tunnel Endpoint};
            J[Configure Matching IPSec/BGP on Branch Device] --> K{Branch Initiates Tunnel / Prisma Access Initiates};
            I --> K;
            K --> L{IPSec Phase 1 (IKE SA) Negotiation};
            L -- Success --> M{IPSec Phase 2 (IPSec SA) Negotiation};
            M -- Success --> N{Tunnel Established};
            N -- BGP Configured --> O{BGP Peering Established};
            O -- Routes Exchanged --> P[End: Secure Connectivity Established];
            N -- Static Configured --> P;
     

IPSec Tunnel Configuration

Establishing a stable and secure IPSec tunnel is critical for Remote Network connectivity.

• IKE Versions: Supports IKEv1 and IKEv2. IKEv2 is generally recommended due to improved security, reliability (built-in keepalives), and efficiency.
• Phase 1 (IKE SA - Management Connection): Establishes a secure channel for negotiating the actual data tunnels.
  • Key Parameters: IKE Crypto Profile (Encryption: AES-128/256-GCM preferred; Authentication: SHA-256/384/512; DH Group: 14, 19, 20, 21 recommended), Authentication Method (Pre-Shared Key or Certificates), Lifetimes, NAT Traversal (if needed).
• Phase 2 (IPSec SA - Data Connection): Defines how the actual user data is encrypted and authenticated.
  • Key Parameters: IPSec Crypto Profile (Encryption: AES-128/256-GCM preferred; Authentication: SHA-256/384/512 or None if using GCM; ESP - Tunnel Mode), Lifetimes (typically shorter than Phase 1), Perfect Forward Secrecy (PFS using DH Group matching Phase 1 or stronger recommended).
  • Proxy IDs / Traffic Selectors (Policy-Based VPN): Defines which source/destination subnets are allowed through the tunnel. **Note:** Prisma Access generally prefers **Route-Based VPNs** (using BGP/Static routes over a numbered tunnel interface) where Proxy IDs are typically set to 0.0.0.0/0 for both source and destination, allowing routing protocols to manage traffic flow. Avoid specific Proxy IDs unless required for interop with legacy policy-based VPN devices.
• Authentication:
  • Pre-Shared Keys (PSK): Simpler to configure but requires secure key management. Use strong, unique keys per tunnel.
  • Certificates: More scalable and secure. Requires a Public Key Infrastructure (PKI) to issue and manage certificates for Prisma Access and the branch device.
• Dead Peer Detection (DPD): Mechanism to detect if the VPN peer is unresponsive, allowing for faster failover. Recommended to enable.
• Interoperability: Palo Alto Networks provides vendor-specific guides for configuring tunnels with common third-party firewall/router vendors. Ensuring matching parameters (crypto, lifetimes, DH groups, IKE version) is crucial.

Simplified IPSec Tunnel Establishment

        sequenceDiagram
            participant Initiator as Branch Device
            participant Responder as Prisma Access RN Endpoint

            Initiator->>Responder: 1. Initiate IKE Phase 1 (Propose Crypto, DH Key)
            activate Responder
            Responder->>Initiator: 2. Respond (Agree on Crypto, DH Key, Authenticate - PSK/Cert)
            activate Initiator
            Note over Initiator, Responder: IKE SA (Phase 1 Tunnel) Established
            Initiator->>Responder: 3. Initiate IKE Phase 2 (Propose IPSec Params, ProxyIDs/Selectors)
            Responder->>Initiator: 4. Respond (Agree on IPSec Params)
            deactivate Responder
            deactivate Initiator
            Note over Initiator, Responder: IPSec SA (Phase 2 Data Tunnel) Established
     

Routing: BGP vs Static

Routing determines how Prisma Access and the remote network site exchange information about reachable subnets.

• BGP (Border Gateway Protocol):
  • Recommended Method: More dynamic, scalable, and resilient than static routing.
  • Mechanism: Prisma Access and the branch device become BGP peers over the IPSec tunnel. They dynamically advertise their local subnets to each other.
  • Configuration: Requires configuring BGP settings on both ends: Autonomous System Numbers (ASNs - Prisma Access typically uses a private ASN, branch uses its own public/private ASN), neighbor IP addresses (tunnel interface IPs), timers, route advertisement filters (optional).
  • Advantages: Automatic route updates if network topology changes, better support for redundant tunnels (ECMP or failover based on BGP metrics).
• Static Routing:
  • Mechanism: Manually define static routes on both Prisma Access and the branch device.
  • Prisma Access Config: You define static routes pointing to the branch subnets via the tunnel interface.
  • Branch Device Config: You define static routes pointing to Prisma Access resources (e.g., default route or specific routes for mobile user pools/other connected sites) via the tunnel interface.
  • Disadvantages: Requires manual updates if network changes, less scalable, harder to manage redundancy (may require IP SLA tracking or similar mechanisms on the branch device).
  • Use Case: Simpler setups, branches with very few subnets, devices with limited BGP support.

Bandwidth Allocation

• Per-Site Bandwidth: Assign a fixed bandwidth amount (e.g., 50 Mbps, 200 Mbps) during onboarding. This site cannot exceed this limit. Enforced by Prisma Access.
• Aggregate Bandwidth Pool: Purchase a large pool (e.g., 1 Gbps, 10 Gbps) shared across multiple Remote Network sites. Sites can dynamically use bandwidth up to the aggregate limit. Requires monitoring aggregate usage via Prisma Access Insights.
• Monitoring: Prisma Access Insights provides dashboards to track bandwidth utilization per site and for the aggregate pool. Set up alerts for high utilization.

High Availability (HA)

Ensuring continuous connectivity for Remote Networks is critical.

• Redundant Tunnels: Configure two separate IPSec tunnels from the branch device to Prisma Access. This can be:
  • To the same Prisma Access compute location (provides PoP-level redundancy against tunnel/link failure).
  • To different Prisma Access compute locations (provides geographic redundancy against PoP failure).
• Failover Mechanisms:
  • BGP-Based Failover: The preferred method. Use BGP metrics (e.g., AS-Path Prepending, MEDs, Local Preference) to prefer one tunnel over the other. If the primary tunnel fails, BGP reconverges and routes traffic over the secondary tunnel automatically. Can also support Equal-Cost Multi-Path (ECMP) if tunnels have equal BGP cost, load-sharing traffic.
  • Static Route + Monitoring: If using static routes, the branch device needs a mechanism (like IP SLA tracking, tunnel monitoring) to detect primary tunnel failure and switch traffic to the secondary tunnel's static route. Less reliable than BGP.
• Branch Device Redundancy: For full site redundancy, use redundant firewalls/routers at the branch in an HA pair.

Integration with SD-WAN

• Prisma Access as SD-WAN Hub: Branches using third-party SD-WAN can establish secure tunnels (IPSec) to Prisma Access. Prisma Access acts as a secure internet gateway and potentially an inter-branch communication hub (depending on topology). SD-WAN overlay tunnels typically run inside the Prisma Access IPSec tunnels.
• Prisma SD-WAN Integration: Palo Alto Networks offers Prisma SD-WAN (formerly CloudGenix). When used together:
  • Integration is tighter, often managed via the unified Prisma SASE UI.
  • Prisma SD-WAN devices (ION) can automatically establish secure fabric links to the nearest Prisma Access PoPs.
  • Provides application-aware path selection, directing traffic optimally either directly to the internet, to Prisma Access for security, or over the SD-WAN fabric to other sites/datacenters.
• Benefits: Combines application performance optimization (SD-WAN) with comprehensive cloud-delivered security (Prisma Access).

Part 3: Service Connections

Service Connections link your existing datacenters, headquarters, or IaaS environments (like AWS VPCs, Azure VNets) securely to the Prisma Access cloud fabric. They allow users connected to Prisma Access (Mobile Users, Remote Networks) to access internal corporate resources.

Purpose

• Access Internal Resources: The primary goal is to provide Prisma Access users secure access to applications, servers, and services hosted within the corporate network (datacenters, private clouds).
• Facilitate User-ID Redistribution: Allows Prisma Access to leverage User-ID information learned by agents or firewalls within the corporate network (requires specific configuration).
• Hybrid Connectivity: Creates a secure bridge between the cloud-native Prisma Access environment and traditional network infrastructure.

Configuration

Configuration is very similar to Remote Networks but often involves higher bandwidth and redundancy requirements.

• IPSec Tunnels: Use standard IPSec VPN tunnels (IKEv1/IKEv2) established between Prisma Access (specifically the CANs) and the firewall/router at the datacenter edge.
• BGP Routing: BGP is **highly recommended** (and often implicitly required) for Service Connections to dynamically exchange routes between Prisma Access and the corporate network. Static routes are generally not suitable for the dynamic nature of datacenter environments.
• High Bandwidth: Service Connections typically require significantly more bandwidth allocation than individual Remote Networks, as they aggregate traffic from potentially many users/sites accessing internal resources. Bandwidth is purchased as part of the Prisma Access subscription.
• Redundancy: Configuring redundant Service Connections (multiple tunnels, potentially to different Prisma Access PoPs and/or different datacenter firewalls) is critical for high availability. BGP is used for failover or ECMP load sharing across these tunnels.
• Key Parameters (Panorama/Cloud): Similar to Remote Networks - Specify location, bandwidth, IPSec settings (PSK/Cert, Crypto Profiles), and BGP configuration (Peer/Local ASN, neighbor IPs).

Routing Considerations

• Route Exchange via BGP:
  • Prisma Access Advertises: Advertises the IP pools allocated to Mobile Users and potentially subnets from connected Remote Networks (if configured) to the corporate network via BGP.
  • Corporate Network Advertises: The datacenter firewall/router advertises internal corporate subnets (e.g., server VLANs, internal application networks) to Prisma Access via BGP.
• Route Filtering & Summarization: Use BGP route maps or prefix lists on the datacenter firewall (and potentially within Prisma Access BGP config) to:
  • Filter which specific routes are advertised in each direction.
  • Summarize routes to reduce the size of the routing table and improve stability.
• Traffic Flow: When a mobile user requests an internal IP, Prisma Access routes the traffic through the SPN, then internally to the CAN, over the appropriate Service Connection tunnel to the datacenter firewall, and finally to the internal resource. Return traffic follows the reverse path.

Service Connection Traffic Flow & Routing (Conceptual)

 graph TD
    subgraph Prisma Access User/Site
        A[MU/RN User Request for Internal IP]
    end
    subgraph Prisma Access Cloud Fabric
        B(SPN - Security Policy Applied)
        C{Routing Decision}
        D(CAN - Corporate Access Node)
        E[Service Connection IPSec Tunnel]
    end
    subgraph Corporate Datacenter
        F(Datacenter Edge Firewall/Router)
        G{Internal Routing}
        H[Internal Server/Resource]
        I(BGP Peer)
    end

    A --> B
    B --> C
    C -- Route Learned via BGP --> D
    D --> E
    E --> F
    F -- Decrypt & Route --> G
    G --> H

    %% Link BGP components
    D -. BGP Peering .- I
    I --> F

    %% BGP runs on the FW/Router
    %% Return Path (Simplified)
    H --> G
    G --> F
    F --> E
    E --> D
    D --> C
    C --> B
    B --> A

     

Use Cases

• Accessing Internal Web Apps & Databases: Securely connect mobile users to internal portals, ERP systems, file shares, etc.
• Hybrid Cloud: Connect Prisma Access users to resources running in IaaS environments (AWS, Azure, GCP) that are linked to the corporate network.
• User-ID Redistribution Point: Configure the datacenter firewall connected via the Service Connection to redistribute User-ID mappings (learned from internal agents like Domain Controllers) to Prisma Access. This helps identify users accessing internal resources even if the initial mapping was lost.
• Centralized Services: Access internal DNS servers, authentication servers (e.g., internal RADIUS), or other shared services located in the datacenter.

Part 4: Clean Pipe Service (Optional)

The Clean Pipe service is a specific Prisma Access offering targeted primarily at **Service Providers (SPs)**.

• Purpose: Allows SPs to offer managed security services to their downstream customers. The SP routes their customer traffic through Prisma Access for security inspection (threat prevention, URL filtering, etc.) before delivering it to the internet or the customer's network.
• Architecture: Involves specific onboarding and routing configurations where the SP establishes high-bandwidth connections (often using Service Connections or specialized links) to Prisma Access. Prisma Access acts as a centralized "scrubbing center" for the SP's customer traffic.
• Management: Typically managed by the Service Provider, who then offers security packages to their end customers.
• Details: Specific architecture, configuration, and licensing differ from the standard enterprise Prisma Access model and require consultation with Palo Alto Networks.