Palo Alto GlobalProtect Configuration with a Remote User Example

Securing enterprise remote access requires a robust VPN solution that enforces strict authentication, seamless client connectivity, and granular access controls. A standard Palo Alto GlobalProtect configuration allows organizations to terminate remote worker connections directly onto the firewall. This setup applies continuous threat prevention, user-based policies, and centralized logging to all remote traffic.

In this tutorial, you will learn how to build a complete Palo Alto GlobalProtect configuration from scratch. We will walk through certificate deployment, SSL/TLS profiles, tunnel interfaces, portal and gateway setup, security policies, and verification techniques using both the Web Interface and the PAN-OS Command Line Interface (CLI).

Real-Life Scenario

An enterprise engineering firm, ExampleCorp, requires secure access for remote systems engineers connecting to critical internal network resources. Remote employees work offsite and must access corporate applications residing in the internal application subnet.

To meet compliance and security mandates, ExampleCorp requires:

• Encrypted transport using modern TLS/IPsec protocols.
• User authentication against an internal authentication profile.
• Split tunneling to route corporate traffic (10.10.0.0/16) through the encrypted tunnel while sending standard internet traffic out the local network.
• Strict security policies restricting remote user access to authorized corporate zones only.

Lab Topology

The following diagram illustrates the logical path of the remote client connecting across the public internet to the firewall’s GlobalProtect Portal and Gateway, terminating onto a virtual tunnel interface mapped to a dedicated security zone.

+-------------------------+
|  Remote Client          |
|  IP: 198.51.100.50 (Lab)|
+------------+------------+
             |
             | SSL/IPsec Tunnel (Public Internet)
             v
+------------+------------+
| Interface: ethernet1/1  | (Zone: Untrust, IP: 203.0.113.10)
| Palo Alto Firewall      |
| GlobalProtect Portal &  |
| Gateway                 |
+------------+------------+
             |
             | Internal Virtual Interface: tunnel.1
             v (Zone: Remote-VPN, Assigned IP Pool: 10.200.1.0/24)
+------------+------------+
| Internal Security Zone  |
| Interface: ethernet1/2  | (Zone: Trust, IP: 10.10.1.1/24)
+------------+------------+
             |
             v
+------------+------------+
| Corporate Resources     |
| Subnet: 10.10.0.0/16    |
+-------------------------+

Example Addressing and Objects

The table below details the example network parameters, hostnames, and interface configurations used throughout this guide. Production deployments must adapt these lab values to match organizational subnets and naming conventions.

Prerequisites

Before configuring GlobalProtect, verify that your environment satisfies the following operational requirements:

• PAN-OS Version: PAN-OS 10.1 or higher installed on the firewall.
• Licensing: A standard Palo Alto Networks firewall installation includes basic GlobalProtect features for Windows and macOS clients. Mobile device support (iOS, Android) and advanced checks (such as Host Information Profile/HIP) require a GlobalProtect subscription license.
• DNS Resolution: The portal FQDN (e.g., gp.example.com) must resolve publicly to the external interface address (203.0.113.10).
• Routing: The firewall virtual router must have a valid default route out the external interface and internal routes back to local subnets.
• Public Key Infrastructure (PKI): A valid Server Certificate signed by an enterprise internal Root CA or trusted third-party Public CA. Alternatively, a locally generated Root CA on PAN-OS can be used for lab testing.

Step-by-Step GUI Configuration

Follow these steps to configure the SSL/TLS profiles, network interfaces, authentication mechanisms, GlobalProtect Portal, GlobalProtect Gateway, and security policies.

Step 1: Certificate Management

GlobalProtect requires an SSL certificate for server authentication to prevent man-in-the-middle attacks when clients connect.

1. Navigate to Device > Certificate Management > Certificates.
2. If using a local lab Root CA, click Generate:
   • Certificate Name: Lab-Root-CA
   • Common Name: Lab-Root-CA
   • Check the box for Certificate Authority.
   • Click Generate.
3. Generate or import the Server Certificate for the portal/gateway:
   • Click Generate.
   • Certificate Name: GP-Server-Cert
   • Common Name: gp.example.com (or public IP 203.0.113.10)
   • Signed By: Select Lab-Root-CA (or your internal CA).
   • Add a Subject Alternative Name (SAN): Type DNS, Value gp.example.com.
   • Click Generate.

Step 2: Create an SSL/TLS Service Profile

The SSL/TLS profile defines the cryptographic parameters and certificates used by the portal and gateway endpoints.

1. Navigate to Device > Certificate Management > SSL/TLS Service Profile.
2. Click Add.
3. Name the profile: GP-SSL-Profile.
4. In the Certificate dropdown, select GP-Server-Cert.
5. Set Min Version to TLSv1.2 and Max Version to Max.
6. Click OK.

Step 3: Configure Authentication

For this lab example, we will configure a local user database and link it to an Authentication Profile. Production enterprise environments typically link this profile to Active Directory via LDAP, RADIUS, or SAML (IdP).

1. Navigate to Device > Local User Database > Users.
2. Click Add. Define vpnuser1, assign a secure password, and click OK.
3. Navigate to Device > Authentication Profile.
4. Click Add.
   • Name: GP-Auth-Profile
   • Type: Select Local Database.
5. Select the Advanced tab:
   • Under the Allow List, click Add and select all (or restrict to specific local user groups).
6. Click OK.

Step 4: Create Tunnel Interface and Security Zone

GlobalProtect terminates client encrypted connections onto a logical Layer 3 tunnel interface.

1. Navigate to Network > Zones.
2. Click Add.
   • Name: Remote-VPN
   • Log Type: Layer3
3. Click OK.
4. Navigate to Network > Interfaces > Tunnel.
5. Click Add.
   • Interface Name: tunnel.1
   • Virtual Router: Select default (or your active virtual router).
   • Security Zone: Select Remote-VPN.
6. Leave the IPv4/IPv6 address configuration blank (unassigned); the gateway dynamically handles IP allocations. Click OK.

Step 5: Configure the GlobalProtect Gateway

The gateway authenticates the client, assigns internal network configurations (IP address, DNS servers), establishes the encrypted tunnel, and controls split-tunnel routes.

1. Navigate to Network > GlobalProtect > Gateways.
2. Click Add.
3. In the General tab:
   • Name: GP-Gateway
   • Interface: Select ethernet1/1 (external interface).
   • Address Type: IPv4
   • IPv4 Address: Select 203.0.113.10/24.
4. In the Authentication tab:
   • SSL/TLS Service Profile: Select GP-SSL-Profile.
   • Under Client Authentication, click Add:
     • Name: Gateway-Auth
     • Authentication Profile: Select GP-Auth-Profile.
     • Click OK.
5. In the Agent tab:
   • Select Tunnel Settings:
     • Check Tunnel Mode.
     • Tunnel Interface: Select tunnel.1.
     • Check Enable IPsec (allows high-performance ESP encapsulation with automatic SSL fallback).
   • Select Client Configuration and click Add:
     • Name: Gateway-Client-Config
     • Authentication Profile: Select GP-Auth-Profile.
     • Navigate to the IP Pools sub-tab: Click Add and enter the IP pool range: 10.200.1.10-10.200.1.250.
     • Navigate to the Split Tunnel sub-tab: Under Include, click Add and specify the internal destination route: 10.10.0.0/16.
     • Navigate to the DNS sub-tab: Enter internal enterprise DNS servers if applicable (e.g., 10.10.1.53).
     • Click OK to close the Client Configuration window.
6. Click OK to save the Gateway configuration.

Step 6: Configure the GlobalProtect Portal

The portal serves as the single management endpoint for remote clients. It handles initial client authentication, provides agent software downloads, and delivers gateway connection configurations.

1. Navigate to Network > GlobalProtect > Portals.
2. Click Add.
3. In the General tab:
   • Name: GP-Portal
   • Interface: Select ethernet1/1.
   • Address Type: IPv4
   • IPv4 Address: Select 203.0.113.10/24.
4. In the Authentication tab:
   • SSL/TLS Service Profile: Select GP-SSL-Profile.
   • Under Client Authentication, click Add:
     • Name: Portal-Auth
     • Authentication Profile: Select GP-Auth-Profile.
     • Click OK.
5. In the Agent tab:
   • Click Add to create an Agent Configuration:
     • Name: Portal-Agent-Config
     • Authentication Profile: Select GP-Auth-Profile.
     • Navigate to the External sub-tab under Gateways:
       • Click Add under External Gateways:
         • Name: External-GW
         • Address: Enter the FQDN gp.example.com or IP 203.0.113.10.
         • Click OK.
     • Navigate to the App sub-tab: Set client connection rules (e.g., Connect Method: User-Auth).
     • Click OK to close the Agent Configuration window.
6. Click OK to save the Portal configuration.

Step 7: Configure Security Rules

Traffic emerging from the tunnel.1 interface resides within the Remote-VPN security zone. You must add security rules to permit traffic from this zone to internal networks.

1. Navigate to Policies > Security.
2. Click Add.
   • Name: Allow-GP-VPN-to-Internal
   • Source Tab: Source Zone select Remote-VPN. Source Address select Any (or 10.200.1.0/24).
   • Destination Tab: Destination Zone select Trust. Destination Address select 10.10.0.0/16.
   • Application Tab: Select desired application objects (e.g., web-browsing, ssl, ssh) or leave as any for testing.
   • Action Tab: Select Allow. Enable logging at session end.
3. Click OK.

4. Click Commit in the upper right corner of the GUI to process and finalize your candidate configuration.

CLI Section

The PAN-OS Command Line Interface (CLI) allows you to inspect operational statuses, evaluate authentication mechanisms, and verify tunnel parameters quickly.

To test client authentication against a configured Authentication Profile via the CLI, use the following operational command:

test authentication profile GP-Auth-Profile username vpnuser1 password

To verify that the designated tunnel interface is operational and attached to the virtual router:

show interface tunnel.1

To view active connections established on the GlobalProtect Gateway:

show global-protect-gateway current-connection gateway GP-Gateway

To inspect runtime statistics for the GlobalProtect Portal:

show global-protect-portal statistics

To inspect the routing engine table for dynamic routes instantiated by active client connections:

show routing route virtual-router default

How the Traffic Flows

Understanding the distinct stages of control-plane signaling and data-plane routing clarifies how GlobalProtect processes packet flows.

1. Portal Authentication (Control Plane):
   • The client GlobalProtect App initiates an HTTPS request (TCP port 443) to gp.example.com (203.0.113.10).
   • The firewall validates the server certificate, authenticates the user via GP-Auth-Profile, and sends the client configuration payload XML.
   • The XML response contains the list of available external gateways, client app behaviors, and trust configurations.
2. Gateway Tunnel Establishment (Control/Data Plane):
   • The client initiates an authentication request to the external gateway address (203.0.113.10).
   • Upon successful authentication, the gateway assigns a virtual client IP address (e.g., 10.200.1.10) from the configured IP pool.
   • The gateway attempts to form an IPsec tunnel using ESP (UDP port 4500). If firewall middleboxes block IPsec transport, the client seamlessly falls back to SSL encapsulation over TCP port 443.
3. Data Forwarding & Policy Enforcement (Data Plane):
   • The client OS installs a dynamic network interface and injects routes based on the split-tunnel profile (e.g., route 10.10.0.0/16 into the virtual adapter).
   • When the user accesses an internal application (e.g., 10.10.5.20), packets are encapsulated into the IPsec/SSL tunnel.
   • Encapsulated packets arrive at ethernet1/1 (zone Untrust). The firewall decapsulates the packets and logically attributes the unencapsulated traffic to interface tunnel.1 and zone Remote-VPN.
   • The firewall evaluates Security Policies:
     • Source Zone: Remote-VPN
     • Source IP: 10.200.1.10
     • Destination Zone: Trust
     • Destination IP: 10.10.5.20
   • If permitted, the packet routes out physical interface ethernet1/2 to the internal network destination.

Verification

To verify operational status across both the firewall and client endpoints, run the following diagnostic checks:

1. Client App Verification

Open the GlobalProtect Agent on the remote client machine. Verify that the client displays Connected. Click the menu icon and inspect the Connection Details tab. Confirm that:

• The assigned IP address matches an entry from the configured pool (e.g., 10.200.1.10).
• The assigned gateway is gp.example.com.
• The connection type lists IPsec (or SSL).

2. GUI Gateway Active Users Check

Navigate to Network > GlobalProtect > Gateways. Click the Remote Users link on the GP-Gateway row. Confirm that vpnuser1 is displayed with their assigned virtual IP, tunnel status, client OS type, and public IP address.

3. Traffic Log Verification

Navigate to Monitor > Logs > Traffic. Filter logs using the following query structure:

( zone.src eq Remote-VPN ) and ( zone.dst eq Trust )

Confirm that traffic sourced from the client virtual IP (10.200.1.10) to internal applications shows an action of allow and correctly maps to the Allow-GP-VPN-to-Internal rule.

Troubleshooting

When remote access connections fail, isolate the issue using systematic verification of symptoms, underlying root causes, and CLI inspection commands.

Symptom 1: Portal Connection Fails with Certificate Error

• Likely Cause: The client machine does not trust the Root CA that signed the portal server certificate, or the certificate Subject Alternative Name (SAN) does not match the FQDN entered by the user.
• Verification Check: Access the portal FQDN using a standard web browser on the client machine (https://gp.example.com). Inspect certificate trust errors. Import the Root CA certificate into the client machine’s Trusted Root Certification Authorities store.

Symptom 2: GlobalProtect Connects, but Internal Application Traffic Times Out

• Likely Cause 1: Missing Return Route. Internal routers or downstream firewalls do not possess a route directing the VPN client pool network (10.200.1.0/24) back to the Palo Alto firewall’s internal interface (10.10.1.1).
• Likely Cause 2: Security Policy Enforcement. No security policy rule exists permitting traffic from the Remote-VPN zone to the destination zone.
• Verification Check: Inspect traffic logs under Monitor > Logs > Traffic. If logs show traffic with Action: drop or `Reset`, check security policy definitions. If logs show bytes_sent but zero bytes_received, inspect internal routing for missing return paths to 10.200.1.0/24.

Symptom 3: Tunnel Connects via SSL Instead of IPsec

• Likely Cause: Intermediate networks or ISP firewalls are dropping UDP port 4500 (IPsec NAT-Traversal) or ESP traffic.
• Verification Check: Run the CLI operational command:

  show global-protect-gateway current-connection gateway GP-Gateway

  Examine the tunnel protocol listing. If SSL is shown, confirm that upstream edge firewalls permit UDP port 4500 inbound to the public firewall interface.

Common Mistakes

• Unassigned Tunnel Interface Zone: Creating tunnel.1 but failing to assign it to a Layer 3 Security Zone (e.g., Remote-VPN). Unassigned tunnel interfaces drop incoming traffic automatically.
• Unassigned Virtual Router: Creating the tunnel interface without placing it inside an active Virtual Router prevents the firewall from populating routing entries.
• Certificate Mismatch: Using an IP address inside the certificate’s Common Name when clients initiate connections using a Domain Name (FQDN), leading to client validation failures.
• Missing Split-Tunnel Route Configuration: Omitting required corporate subnets from the Gateway Split-Tunnel Include list, causing client devices to bypass the VPN tunnel for corporate resources.
• Overlapping IP Pools: Assigning a GlobalProtect Client IP Pool range that overlaps with existing physical internal networks or client local LAN subnets (e.g., using 192.168.1.0/24).

Production Considerations

Before moving a GlobalProtect configuration into production, incorporate these enterprise standards:

• Multi-Factor Authentication (MFA): Integrate your Authentication Profile with SAML 2.0 Identity Providers (such as Okta, Azure AD, or Ping Identity) or RADIUS with MFA to enforce second-factor authentication for remote users.
• Redundant External Gateways: Deploy multiple active GlobalProtect gateways across geographically dispersed firewalls. Configure priority-based gateway lists inside the portal agent configuration for automatic failover and load distribution.
• Host Information Profile (HIP): Require GlobalProtect subscription licenses to enforce device posture checks (e.g., checking for active disk encryption, mandatory endpoint protection, and patch management) prior to granting network access.
• Bandwidth and Capacity Planning: Monitor firewall dataplane CPU usage, session table limits, and SSL decryption load when sizing GlobalProtect deployments for large remote workforces.

Related NetworkFix Guides

• Palo Alto IPsec VPN troubleshooting
• Generate a Palo Alto certificate signed by Microsoft AD CS
• Palo Alto log forwarding to Syslog or SIEM
• Palo Alto security policy configuration

Summary

Implementing a robust Palo Alto GlobalProtect configuration provides secure, policy-driven remote access for remote workers. By configuring server certificates, logical tunnel interfaces, dedicated security zones, split-tunnel rules, and authentication profiles, security teams gain complete visibility and control over off-site devices accessing internal enterprise application environments.