5.1 Prisma Access Cloud Architecture & Multi-Tenant Fabric

5.1 Prisma Access Cloud Architecture & Multi-Tenant Fabric

SASE Architecture & The Cloud-Delivered Security Paradigm

Traditional enterprise network architectures relied on a hub-and-spoke topology. Branch offices and remote workers routed all traffic across costly private MPLS circuits or client-to-gateway VPN tunnels back to a centralized corporate data center. At the data center, an array of point security appliances—such as next-generation firewalls (NGFW), secure web gateways (SWG), intrusion prevention systems (IPS), and data loss prevention (DLP) engines—inspected the traffic before routing it outbound to the public Internet or software-as-a-service (SaaS) applications.

As applications migrated to multi-cloud environments (AWS, Microsoft Azure, Google Cloud Platform) and enterprise workforces transitioned to remote and hybrid models, this backhaul model introduced severe operational bottlenecks:

• Latency & Hairpinning (Tromboning): Forcing branch or teleworker traffic to traverse half the globe to reach a corporate data center simply to access a public SaaS application like Salesforce or Microsoft 365 introduces unacceptable latency, packet jitter, and degraded user experience.
• Bandwidth Saturation: On-premises data center internet ingress circuits quickly saturate under the load of encrypted enterprise video, collaboration tools, and cloud backups.
• Fragmented Policy Enforcement: Managing disparate standalone proxy solutions for web browsing, fragmented VPN concentrators for mobile users, and hardware firewalls for branches results in inconsistent security postures, visibility blind spots, and configuration drift.

Prisma Access solves these architectural flaws by delivering a cloud-native Secure Access Service Edge (SASE) fabric. Rather than forcing users to come to the security perimeter, Prisma Access moves the security perimeter directly to the user. Powered by the Palo Alto Networks PAN-OS operating system, Prisma Access unifies Firewall as a Service (FWaaS), Zero Trust Network Access (ZTNA 2.0), Cloud Access Security Broker (CASB), Secure Web Gateway (SWG), and Advanced Cloud-Delivered Security Services (CDSS) into a single, scalable global cloud infrastructure.

+-----------------------------------------------------------------------------------+
|                         PRISMA ACCESS CLOUD FABRIC                                |
|                                                                                   |
|  +---------------------+   AWS & GCP Global Backbone   +-----------------------+  |
|  | Mobile User SPNs    |<============================>| Remote Network SPNs   |  |
|  | (MU-SPN Gateways)   |       (Private Mesh)         | (Branch RN-SPNs)      |  |
|  +---------------------+                              +-----------------------+  |
|            ^                                                      ^               |
|            |                                                      |               |
|            +-----------------------+      +-----------------------+               |
|                                    v      v                                       |
|                        +-----------------------+                                  |
|                        |  Service Connections  |                                  |
|                        |       (SC-SPNs)       |                                  |
|                        +-----------------------+                                  |
+-----------------------------------|-----------------------------------------------+
                                    | Dedicated IPsec Tunnels
                                    v
                     +-----------------------------+
                     | Corporate Enterprise Core   |
                     | Data Centers & Headquarters |
                     +-----------------------------+

Unlike traditional proxy-based SASE vendors that inspect only web traffic (HTTP/HTTPS) and break or tunnel other protocols without inspection, Prisma Access provides true Layer 3 through Layer 7 stateful inspection across all ports, all protocols, and all applications using Palo Alto Networks proprietary Single-Pass Parallel Processing (SP3) engine.

---

Compute Locations vs. Security Processing Nodes (SPNs)

A foundational concept in Prisma Access is the architectural decoupling of geographic compute capacity from logical security processing instances.

1. Compute Locations

A Compute Location represents a regional cloud computing zone within the underlying hyperscaler infrastructure (e.g., US West, Europe Central, Asia Southeast). When an organization subscribes to Prisma Access, Palo Alto Networks provisions dedicated compute capacity in these chosen regions. Compute locations house the underlying virtualization and containerized infrastructure where security processing engines run.

2. Security Processing Nodes (SPNs)

A Security Processing Node (SPN) is a purpose-built, cloud-instantiated PAN-OS data plane instance that executes traffic classification, stateful inspection, cryptographic tunnel termination, and security policy enforcement. SPNs operate within compute locations and are segmented into three specialized architectural types:

• Mobile User SPNs (MU-SPNs): Act as globally distributed GlobalProtect security gateways. MU-SPNs terminate incoming remote access tunnels from endpoint devices (laptops, mobile devices), perform User-ID authentication, inspect traffic against ZTNA security policies, and route approved packets across the cloud backbone.
• Remote Network SPNs (RN-SPNs): Act as site-to-site IPsec termination endpoints for branch offices, retail locations, and remote facilities. RN-SPNs maintain redundant IPsec tunnels with branch Customer Premise Equipment (CPE), run dynamic BGP routing, and enforce outbound QoS and firewall security policies.
• Service Connection SPNs (SC-SPNs): Serve as dedicated transit nodes connecting the Prisma Access cloud fabric directly to corporate data centers, colocation facilities, and headquarters. SC-SPNs enable access to internal corporate services such as Active Directory domain controllers, internal DNS, and private enterprise applications.

3. Compute Location vs. Gateway / Egress Location

A common point of confusion is the relationship between the physical compute site and the public egress point:

• The Compute Location is where policy inspection, SSL decryption, and threat scanning physically execute on the SPN CPUs.
• The Gateway Location / Egress Location is the geographic point of presence where the SPN presents its public IP address to the outside world.

In most global metropolitan areas, the compute location and egress location are identical. However, in regions where public cloud infrastructure does not offer native hyperscale compute facilities, Prisma Access supports localized egress: traffic is routed across the cloud backbone to a nearby regional compute location for inspection, and then egresses back through a localized public IP address matching the user's country. This preserves localized web experiences (e.g., preventing search engines or banking portals from redirecting users to the wrong language or country domain).

---

Multi-Tenant Hyperscale Cloud Footprint (AWS & GCP Backbones)

Prisma Access does not rely on proprietary, leased physical data centers or unmanaged third-party colocation facilities. Instead, it is built natively on top of the world's two largest hyperscale cloud backbones: Amazon Web Services (AWS) and Google Cloud Platform (GCP).

Architectural Benefits of Hyperscale Backbones

1. Massive Global Fiber Infrastructure: AWS and GCP operate extensive private undersea and terrestrial fiber-optic backbones spanning hundreds of thousands of route miles. When traffic enters a Prisma Access SPN in Tokyo destined for a corporate data center in Frankfurt, the packet does not traverse the public Internet. Instead, it enters the hyperscale cloud's private backbone.
2. Deterministic Latency & Minimal Jitter: By bypassing the congested public Internet transit mesh—which suffers from dynamic peering disputes, arbitrary ISP routing throttles, and BGP route flapping—Prisma Access provides highly predictable latency and packet delivery guarantees, vital for voice (VoIP), video conferencing, and interactive virtual desktop infrastructure (VDI).
3. Near-Zero Transit Loss: Hyperscale backbones maintain excessive private bandwidth headroom, virtually eliminating intermediate packet drops and buffer bloat.
4. Dynamic Elasticity: Hyperscale cloud integration allows Prisma Access to scale compute instances horizontally in minutes to meet sudden traffic surges without requiring physical hardware installation.

---

Architecture Overview: Node Types & Operational Characteristics

---

Service Connections (SC): Corporate Backbone Integration

A Service Connection (SC) is the critical link that transforms Prisma Access from an isolated cloud proxy into an integrated extension of the corporate enterprise WAN.

Primary Functions of Service Connections

• Access to Private Enterprise Applications: Connects remote users and branch offices to legacy internal applications, databases, ERP systems (SAP, Oracle), and internal web portals hosted in physical on-premises data centers.
• Reaching Central Infrastructure Services: Prisma Access SPNs require reachability to corporate Active Directory (AD) Domain Controllers for user group resolution, Kerberos/NTLM authentication, internal enterprise DNS servers for intranet domain resolution, RADIUS/TACACS+ servers for administrative access, and central Syslog/SIEM systems.
• Tenant Interconnect Transit: Functions as the default transit path for traffic flowing between branch offices (Remote Networks) and corporate headquarters.

Bandwidth Allocation & Redundancy

Each Service Connection is provisioned with dedicated, guaranteed bandwidth blocks—typically 300 Mbps or 1 Gbps. Unlike remote networks that use an aggregate pool, Service Connections have committed bandwidth allocations to ensure consistent data center replication and high-volume corporate transit.

Best practice mandates deploying at least two Service Connections for high availability: a Primary Service Connection terminating at the primary enterprise data center, and a Secondary Service Connection terminating at a secondary data center or disaster recovery (DR) facility. Dynamic routing protocols balance and steer traffic across these connections.

---

Infrastructure Subnet Design & Non-Overlapping IP Planning

When setting up Prisma Access, one of the most critical foundational design steps is defining the Infrastructure Subnet.

Purpose of the Infrastructure Subnet

The Infrastructure Subnet is a contiguous private IPv4 CIDR block (minimum /24, expandable to /23 or /22 for large enterprise deployments) dedicated exclusively to the internal operations of the Prisma Access tenant fabric. Prisma Access carves up this subnet to allocate:

1. Loopback IP Addresses: Assigned to every provisioned SPN (MU-SPNs, RN-SPNs, SC-SPNs) across all compute locations.
2. BGP Peering Tunnel Interfaces: Used as the point-to-point IP addresses for establishing eBGP routing sessions between Prisma Access SC-SPNs and on-premises firewalls/routers.
3. Internal Source NAT: Translates internal Prisma Access administrative queries (such as User-ID probes to Active Directory or internal DNS proxy forwarders) so they appear to originate from a known, routable IP address.
4. Interconnect Routing Anchors: Provides the next-hop IP addresses that stitch the multi-tenant fabric together across the hyperscale cloud backbone.

The Strict Non-Overlapping Rule

Exam Trap Alert: The Infrastructure Subnet must NEVER overlap with any IP address space used anywhere else in the enterprise ecosystem. This includes:

• Corporate data center and headquarters subnets.
• Remote branch office LAN subnets.
• Mobile User GlobalProtect IP address pools.
• Public or private cloud VPC/VNet subnets (AWS, Azure, GCP).

+-----------------------------------------------------------------------------------+
|                     ENTERPRISE ADDRESSING ISOLATION                               |
|                                                                                   |
|  [ Corporate Data Center ]       [ Branch Office LANs ]       [ Mobile User Pools]|
|    10.10.0.0/16                     10.20.0.0/16                 100.64.0.0/16    |
|             \                             |                             /         |
|              \                            |                            /          |
|               v                           v                           v           |
|    +------------------------------------------------------------------------+     |
|    |                 PRISMA ACCESS INFRASTRUCTURE SUBNET                    |     |
|    |                       172.16.254.0/24 (MANDATORY)                      |     |
|    |             * STRICTLY UNIQUE - ZERO OVERLAP PERMITTED *               |     |
|    +------------------------------------------------------------------------+     |
+-----------------------------------------------------------------------------------+

If an architect carelessly configures an Infrastructure Subnet that overlaps with an enterprise server subnet (e.g., using 10.1.1.0/24 when an internal database farm resides at 10.1.1.0/24), Prisma Access routing engines will prioritize the locally connected infrastructure routes. Consequently, all traffic destined for those internal corporate servers will be black-holed or misrouted within the cloud fabric, resulting in immediate service outages.

---

Tenant Interconnect Routing: The Global Mesh

Prisma Access includes an intelligent, cloud-native routing core known as the Tenant Interconnect. The Interconnect enables seamless, mesh-style routing between different tenant endpoints across the hyperscale cloud backbone:

1. Mobile User to Service Connection (MU -> SC): Enables remote teleworkers to seamlessly access private corporate data center workloads.
2. Remote Network to Service Connection (RN -> SC): Connects physical branch offices to headquarters and data center resources, replacing traditional MPLS circuits.
3. Remote Network to Remote Network (RN -> RN / Branch-to-Branch): Allows branch offices in different regions to communicate directly through the Prisma Access cloud backbone without backhauling through the corporate data center.
4. Mobile User to Remote Network (MU -> RN): Enables teleworkers to directly reach resources located at branch facilities (e.g., local branch servers, IoT management interfaces, or lab equipment).

Interconnect routing is enabled globally within the Prisma Access configuration and enforces security policy rules at each SPN ingress boundary, ensuring Zero Trust inspection even on internal interconnect transit.

---

Dynamic Routing (eBGP) vs. Static Routing for Service Connections

To exchange reachability information between the Prisma Access cloud fabric and corporate on-premises networks, administrators can implement either dynamic routing via External BGP (eBGP) or Static Routing.

Dynamic Routing with eBGP (Recommended Best Practice)

eBGP is the enterprise standard for Prisma Access Service Connections:

• Peering Architecture: An eBGP peering session is established across the IPsec tunnel interface between the Prisma Access SC-SPN (assigned the Prisma Access tenant ASN, default 65400) and the customer on-premises edge firewall/router (using the enterprise private ASN, e.g., 65001).
• Route Advertisement: The on-premises router advertises corporate data center subnets to Prisma Access. In return, Prisma Access advertises the Mobile User IP pools and Remote Network branch subnets to the on-premises network.
• Fast Convergence via BFD: Bidirectional Forwarding Detection (BFD) can be enabled on the eBGP session to detect sub-second tunnel or link degradation, allowing instantaneous failover before standard BGP hold timers (default 90 seconds) expire.
• Path Selection Control: Enterprises with redundant Service Connections can use standard BGP path manipulation attributes:
  • AS Path Prepending: Artificially lengthens the AS path on the secondary Service Connection, directing inbound return traffic from Prisma Access to prefer the primary Service Connection.
  • Multi-Exit Discriminator (MED): Advertised by the on-premises routers to influence inbound traffic entry points across multiple connections in the same autonomous system.
• Dynamic Failure Recovery: If a specific subnet behind an on-premises data center distribution switch fails, the on-prem router immediately sends a BGP route withdrawal (UPDATE message) to Prisma Access. Traffic to that specific failed subnet is halted or rerouted, preventing multi-hop traffic blackholing.

Static Routing

In simpler network environments, administrators can define static routes:

• Configuration: The administrator manually defines the corporate subnets reachable via each Service Connection directly in the Prisma Access management interface.
• Operational Limitations: Static routing provides zero dynamic visibility into the health of downstream networks behind the customer premise firewall. If an internal link fails three hops deep within the data center while the local IPsec tunnel remains UP, Prisma Access continues forwarding traffic into the tunnel, dropping packets.

---

End-to-End Traffic Flows: Detailed Path Tracing

1. Mobile User to Service Connection (Corporate Data Center Access)

[Mobile User Device (GlobalProtect)]
                |
                v (1. Encrypted IPsec ESP/SSL Tunnel over Public Internet)
[Local MU-SPN (e.g., Singapore Compute Location)]
  - Authenticates User-ID & Evaluates Device HIP Posture
  - Enforces Security Policy & Decrypts/Scans Packet
  - Consults Cloud FIB: Destination matches Corporate DC Subnet
                |
                v (2. Forwarded across AWS/GCP Private Hyperscale Backbone)
[Target SC-SPN (e.g., Frankfurt Compute Location)]
  - Encapsulates packet into Service Connection IPsec Tunnel
                |
                v (3. Dedicated Route-Based IPsec Tunnel)
[Corporate Enterprise Border Firewall (Frankfurt HQ Data Center)]
  - Decrypts IPsec packet & applies on-premises firewall policies
                |
                v (4. Internal Routed LAN Transit)
[Internal Enterprise Application Server (10.10.50.25)]

2. Remote Network to Service Connection (Branch-to-HQ Access)

1. A workstation on a branch LAN (10.50.1.100) sends a packet destined for an internal ERP server (10.10.10.50).
2. The branch CPE router matches an eBGP-learned route and encapsulates the packet into the primary IPsec tunnel to the local RN-SPN.
3. The RN-SPN performs App-ID identification, scans for threats, and evaluates QoS rules.
4. Matching a route learned via the tenant interconnect, the RN-SPN routes the packet across the hyperscale cloud backbone to the SC-SPN.
5. The SC-SPN forwards the packet over the Service Connection IPsec tunnel into the corporate headquarters data center.

3. Remote Network to Internet (Direct Internet Access / FWaaS)

1. A branch user navigates to https://www.salesforce.com.
2. The branch CPE default route (0.0.0.0/0) directs all non-local traffic into the primary IPsec tunnel toward the RN-SPN.
3. The RN-SPN terminates the IPsec tunnel and performs full PAN-OS inspection:
   • Decrypts SSL/TLS using an SSL Forward Proxy profile.
   • Executes App-ID (classifies application as salesforce-base).
   • Scans payload with Threat Prevention (Anti-Spyware, Antivirus, Vulnerability Protection) and Advanced URL Filtering.
4. The RN-SPN applies Source NAT (SNAT), replacing the branch private IP with the Prisma Access compute location's public egress IP address.
5. Clean, inspected traffic egresses the cloud node directly to the Salesforce SaaS servers over high-speed peering links.

---

CLI & Panorama Verification Commands

# Verify the status and operational health of the Cloud Services plugin
admin@panorama> show plugins cloud_services info

# Check the operational status of all provisioned Service Connections
admin@panorama> show plugins cloud_services status service-connection

# Inspect BGP peering states and learned prefixes across Service Connection tunnels
admin@panorama> show plugins cloud_services status bgp

# View detailed IPsec tunnel security associations (IKE SA and IPsec SA) for cloud nodes
admin@panorama> show plugins cloud_services vpn-status

# Verify active Infrastructure Subnet allocation and assigned internal loopback ranges
admin@panorama> show plugins cloud_services status infrastructure-subnet