5.3 Mobile Users (MU) Architecture, Locations & Dedicated IPs

5.3 Mobile Users (MU) Architecture, Locations & Dedicated IPs

Prisma Access Mobile Users Architecture: Cloud-Native GlobalProtect

The modern enterprise workforce is predominantly mobile, distributed across home offices, airports, client sites, and international locations. Historically, securing remote employees required deploying and maintaining banks of physical or virtual on-premises VPN concentrators at corporate headquarters. During unexpected regional disruptions or shifts to remote work, these hardware gateways suffered severe session table exhaustion, CPU saturation, and inbound bandwidth throttling.

Prisma Access for Mobile Users delivers GlobalProtect as a cloud-native service, decoupling remote access security from physical infrastructure limitations. The architecture separates management and connection routing into two primary cloud-delivered components:

                                  PRISMA ACCESS GLOBAL CLOUD
                                              |
                     +------------------------+------------------------+
                     |                                                 |
                     v                                                 v
        [ GlobalProtect Portal ]                           [ Mobile User SPN Gateways ]
        - User Authentication (SAML/MFA)                   - Elastic Auto-Scaling
        - Client Config Distribution                       - IPsec (ESP) / SSL Termination
        - Dynamic Gateway List Provisioning                - Layer 7 PAN-OS Inspection (CDSS)
        - HIP Inspection Policy Engine                     - Distributed User-ID Generation
                     |                                                 |
                     +------------------------+------------------------+
                                              |
                                              v
                                   [ Remote Mobile User ]
                                (GlobalProtect Agent Client)

1. Prisma Access GlobalProtect Portal: A cloud-hosted configuration and authentication authority. When a mobile user opens the GlobalProtect app, it establishes an initial HTTPS connection to the portal FQDN (e.g., portal.company.com). The portal authenticates the user, evaluates initial endpoint compliance, and delivers an encrypted configuration profile containing authorized gateway locations, split-tunneling policies, and security settings.
2. Mobile User Security Processing Nodes (MU-SPNs / Gateways): Globally distributed PAN-OS instances that terminate the encrypted user tunnel (using IPsec ESP or SSL/TLS). MU-SPNs assign virtual adapter IP addresses, execute User-ID mapping, perform single-pass Layer 7 inspection (App-ID, Content-ID, Threat Prevention, SSL Decryption), and route inspected traffic out to the Internet, SaaS, or corporate data centers.

---

Worldwide Security Processing Locations & Elastic Auto-Scaling Mechanics

Prisma Access operates dozens of Mobile User compute locations distributed across the Americas, Europe, Middle East, Africa, and Asia-Pacific.

Elastic Auto-Scaling Architecture

Unlike physical hardware firewalls with rigid hardware capacity limits, MU-SPNs leverage the elastic orchestration of hyperscale cloud infrastructure:

• Continuous Metric Monitoring: The Prisma Access cloud control plane continuously tracks three core telemetry metrics on every provisioned gateway node:
  1. Active concurrent tunnel connections.
  2. Data plane CPU and memory consumption.
  3. Tunnel bandwidth throughput and packet processing queue depths.
• Dynamic Scale-Out: When aggregate user demand crosses dynamic scaling thresholds (e.g., during morning login surges between 8:00 AM and 9:30 AM in a specific time zone), Prisma Access automatically provisions additional gateway instances in the local compute location within minutes.
• Load Balancing: New client connections are transparently distributed across the expanded pool of active gateway nodes.
• Graceful Scale-In: During evening and off-peak hours, when user counts decline, Prisma Access marks underutilized nodes for drain, allowing active sessions to conclude before decommissioning instances, thereby optimizing cloud resources without dropping active user connections.

---

Location Selection Algorithms: Probing, Priority & Internal Host Detection

When a mobile user launches GlobalProtect, the client dynamically determines which gateway to connect to using intelligent selection algorithms.

1. Latency-Based Probing (Default & Recommended)

To guarantee the best application performance, the GlobalProtect client executes real-time latency-based probing:

1. Upon receiving the gateway list from the portal, the client transmits simultaneous ICMP echo requests (or SSL probes if ICMP is blocked) to all eligible external gateways.
2. The client records the Round-Trip Time (RTT) for each responsive gateway.
3. The gateway exhibiting the lowest RTT (lowest latency) is selected, and the client immediately initiates tunnel negotiation.
4. Continuous Telemetry: The client maintains periodic background probes. If an ISP routing shift degrades the current gateway's latency or causes packet loss, the client can initiate a seamless transition to the next best responsive gateway.

2. Manual Gateway Selection

Administrators can configure client settings to allow users to override automatic selection and manually choose a specific gateway from a drop-down list. This is useful for roaming executives, IT administrators diagnosing regional connectivity, or testing geo-restricted content.

3. Gateway Priority and Region Weighting

In enterprise environments with strict regulatory compliance or data sovereignty requirements, administrators configure Priority Rules:

• Gateways can be ranked numerically (e.g., Priority 1 for local country gateways, Priority 2 for neighboring countries, Disallowed for countries outside the compliance boundary).
• The client only probes and connects to secondary priority gateways if all primary priority gateways fail to respond.

4. Internal Host Detection (Internal vs. External Detection)

Before attempting to connect to an external Prisma Access gateway, the GlobalProtect app evaluates whether the device is already physically connected to the corporate LAN or trusted enterprise Wi-Fi:

• Mechanism: The client performs a reverse DNS lookup or sends an HTTPS GET request to a designated internal server IP address and hostname specified in the portal configuration.
• Result:
  • If the internal host responds with the expected cryptographic certificate or IP match, the client concludes it is Internal. The external tunnel is suppressed, or the client switches to an Internal Gateway mode for local User-ID registration without tunnel encryption.
  • If the check fails or times out, the client concludes it is External and immediately proceeds with external gateway selection and tunnel establishment.

---

IP Address Pool Planning & The RFC 1918 Conflict Challenge

Proper IP address pool design is critical for mobile user deployments. A misconfigured IP pool can paralyze mobile connectivity.

Pool Sizing Principles

• Concurrency Overhead: IP pools must be sized to accommodate at least 2.5x to 3x peak concurrent user headcounts.
• Why Oversizing is Mandatory: Mobile users frequently roam between networks (e.g., transitioning from home Wi-Fi to mobile 5G hotspot to office Wi-Fi). When a client abruptly disconnects, its previously leased virtual IP remains reserved in the gateway DHCP table until the lease decay timer expires (typically 30 to 60 minutes). Sizing too tightly causes pool exhaustion, resulting in connection rejections.

The RFC 1918 Residential Subnet Conflict

Exam Trap Alert: The most pervasive failure mode in enterprise remote access is allocating common RFC 1918 subnets—specifically 192.168.0.0/24, 192.168.1.0/24, or 10.0.0.0/24—to the Mobile User IP pool.

[ Teleworker Home Wi-Fi Router ] ---- Assigns Local IP: 192.168.1.50
(Local Subnet: 192.168.1.0/24)            |
                                          v
                               [ Laptop Physical NIC ]
                                          |
                                          +--- ROUTING TABLE COLLISION!
                                          |    Both physical NIC and virtual adapter
                                          |    claim the 192.168.1.0/24 subnet!
                                          v
                               [ GlobalProtect Virtual NIC ]
                               Assigns Cloud Pool IP: 192.168.1.120
                                          |
                                          v
                      [ Prisma Access Mobile User Gateway ]

When a teleworker's home router assigns 192.168.1.50 to their physical Wi-Fi adapter, and the Prisma Access gateway assigns 192.168.1.120 from a matching 192.168.1.0/24 pool to the GlobalProtect virtual adapter, the client operating system routing table encounters identical, overlapping destination routes. The workstation cannot determine whether to send packets out the physical interface or down the tunnel. Consequently, local network printing fails, corporate intranet access drops, and DNS resolution breaks.

Industry Best Practice: RFC 6598 Shared Address Space

To completely eliminate residential subnet collisions, Palo Alto Networks strongly recommends allocating Mobile User IP pools from RFC 6598 Shared Address Space (Carrier-Grade NAT: 100.64.0.0/10):

• Specifically, ranges such as 100.64.0.0/16 through 100.127.0.0/16 are non-routable on the public Internet and are virtually never deployed on residential consumer Wi-Fi routers.
• Alternatively, administrators can allocate uncommon, high-order private subnets, such as 172.28.0.0/14 or 10.240.0.0/13.
• Mobile User IP pools must strictly never overlap with corporate data center subnets, branch LANs, or the Prisma Access Infrastructure Subnet.

---

Dedicated Egress IP Addresses for IP-Allowlisted SaaS & Partner Portals

By default, mobile user traffic exiting Prisma Access to the public Internet utilizes shared public IP addresses.

Shared Egress IPs vs. Dedicated Egress IPs

• Default Shared Egress IPs: Every Prisma Access compute location maintains a dynamic pool of shared public IP addresses. When a mobile user accesses a general website (e.g., Wikipedia or cnn.com), their traffic is translated via Source NAT to one of these shared IPs. These IPs are shared among multiple Prisma Access tenants and can rotate dynamically as gateways scale or during hyperscaler maintenance.
• Dedicated Egress IPs: Many third-party SaaS vendors, financial platforms, supply-chain extranets, and B2B partner portals enforce strict IP Allowlisting (Whitelisting). Connections originating from unrecognized or changing IP addresses are immediately blocked.

To solve this, Prisma Access offers Dedicated Public Egress IPs:

• Palo Alto Networks reserves dedicated, static public IPv4 address blocks permanently assigned to the customer's specific tenant in designated compute locations.
• Granular Policy Steering: Through Security Policy rules, administrators define specific destination FQDNs or IP prefixes (e.g., api.partnerportal.com or banking.corp.net).
• When traffic matches these rules, the MU-SPN applies Source NAT using the Dedicated Egress IP, providing a consistent, immutable public IP address for external verification.

---

Comparison: Shared Egress IPs vs. Dedicated Egress IPs

---

GlobalProtect Agent Onboarding Flow & Authentication Lifecycle

[Mobile User Endpoint]       [GlobalProtect Portal]       [Identity Provider (IdP)]     [Prisma Access MU-SPN]
         |                              |                              |                            |
         |--- 1. HTTPS Connect -------->|                              |                            |
         |    (portal.company.com)      |                              |                            |
         |                              |--- 2. SAML Auth Request ---->|                            |
         |<=============================|==== 3. SAML / MFA Challenge =|                            |
         |--- 4. SAML Assertion Response (Token Auth Successful) ----->|                            |
         |                              |                              |                            |
         |<-- 5. Encrypted Client Config Download ---------------------|                            |
         |    (Gateway List, Split Tunneling, HIP Profile)             |                            |
         |                                                                                          |
         |--- 6. Latency Probing (ICMP/SSL) to Candidate Gateways --------------------------------->|
         |                                                                                          |
         |--- 7. IPsec ESP Tunnel Negotiation (UDP 4501 / Fallback SSL 443) ----------------------->|
         |<-- 8. Assign Virtual IP (100.64.10.45) & DNS Settings ----------------------------------|
         |                                                                                          |
         |--- 9. Host Information Profile (HIP) Report Submission --------------------------------->|
         |<== 10. Established Secure ZTNA Session (Layer 7 Active Inspection) =====================>|

Step-by-Step Lifecycle

1. Portal Discovery: The user launches the GlobalProtect agent, which queries DNS for the portal FQDN and initiates an SSL/TLS handshake on port 443.
2. Authentication via IdP: The portal redirects the user to the enterprise Identity Provider (e.g., Microsoft Entra ID, Okta, Ping Identity) using SAML 2.0 or OIDC integration via the Cloud Identity Engine (CIE). Multi-Factor Authentication (MFA) is completed.
3. Client Configuration Retrieval: Upon successful authentication, the portal returns an encrypted XML configuration containing the list of available external gateways, split-tunneling inclusion/exclusion subnets, DNS servers, and client upgrade policies.
4. Gateway Probing & Selection: The client executes latency probing against the gateway list, elects the lowest-latency responsive MU-SPN, and initiates tunnel negotiation.
5. Tunnel Negotiation (IPsec ESP with SSL Fallback):
   • Primary Transport: IPsec ESP (UDP port 4501) for maximum throughput, low overhead, and real-time audio/video performance.
   • Automatic SSL Fallback: If the mobile user is behind a restrictive hotel, coffee shop, or guest Wi-Fi network that blocks outbound UDP traffic, the client automatically fails over to SSL/TLS (TCP port 443), ensuring continuous connectivity without user intervention.
6. Host Information Profile (HIP) Submission: Once connected, the local GlobalProtect agent gathers endpoint compliance telemetry (OS patch version, disk encryption status, active antivirus/EDR signatures) and securely transmits the HIP report to the gateway for continuous Zero Trust policy enforcement.

---

Agent Upgrade Management & Phased Rollouts

Prisma Access provides centralized client lifecycle management directly through the GlobalProtect Portal:

• Transparent (Silent Background Upgrade): The portal pushes the new client installer binary to endpoints in the background. The installation executes automatically upon the next user reboot or service restart without prompting the user or disrupting active work.
• Prompt User: The client displays a notification informing the user that an update is available, allowing them to initiate the upgrade when convenient.
• Enforce (Mandatory Minimum Version): Rejects connections from outdated client versions that fall below a designated security baseline (e.g., mandating GlobalProtect 6.2+ to patch an OS vulnerability).
• Phased Deployment Cohorts: Administrators configure multiple client configuration profiles mapped to specific Active Directory / CIE user groups, enabling gradual rollouts (e.g., IT Pilot Group -> Early Adopter Business Units -> General Enterprise Population).

---

Cross-Fabric User-ID Mapping Distribution & Cloud Identity Synchronization

In a multi-tenant global fabric, security policies across all nodes must instantly recognize the user behind every packet.

Distributed User-ID Architecture

1. Authentication Binding: When a mobile user authenticates to an MU-SPN in Tokyo, the gateway immediately binds the authenticated user identity (alex.chen@company.com) and associated security groups (Engineering-Lead, DevOps-Admins) to the newly assigned virtual IP (100.64.15.22).
2. Cloud Identity Bus Propagation: The Tokyo MU-SPN publishes this IP-to-User mapping to the Prisma Access internal Cloud Identity / Directory Sync bus running across the hyperscale cloud backbone.
3. Global Fabric Synchronization: Within milliseconds, the mapping is synchronized across all provisioned SPNs, including Remote Network SPNs and Service Connection SPNs.
4. Seamless Corporate Access: When the mobile user in Tokyo initiates an SSH session over a Service Connection to an on-premises server in Chicago, the Chicago SC-SPN already possesses the active IP-to-User mapping. Security policies enforcing role-based access execute instantaneously without requiring secondary authentication or on-premises Kerberos queries.

---

Essential Verification Commands

# Display real-time active GlobalProtect mobile users and their assigned virtual IPs
admin@panorama> show plugins cloud_services status mobile-users active-users

# View current GlobalProtect gateway operational health and connected user counts
admin@panorama> show plugins cloud_services status mobile-users gateways

# Display active User-ID IP-to-User mappings synchronized across the cloud fabric
admin@PA-GW> show user ip-user-mapping all

# Inspect detailed Host Information Profile (HIP) attributes submitted by an endpoint
admin@PA-GW> show user hip-report user alex.chen computer WORKSTATION-884

# Check Dedicated Egress IP address assignments and compute location bindings
admin@panorama> show plugins cloud_services status dedicated-ips