PAN-OS: Configuring Multiple GlobalProtect Gateway Agent Configurations

Introduction: Tailoring the Client Experience

While a single GlobalProtect Gateway can serve many users, you might encounter scenarios where different groups of users connecting to that same Gateway require distinct settings pushed down to their GlobalProtect agents. For example, you might need different split-tunneling rules, DNS servers, or IP pools based on user group, operating system, or device compliance (via HIP profiles).

PAN-OS addresses this need by allowing you to configure multiple Agent Configurations within a single GlobalProtect Gateway definition. The firewall then uses matching criteria (like user group, OS, or HIP profile) to determine which specific configuration to apply to a connecting client.

This powerful feature allows one logical Gateway infrastructure object on the firewall to provide customized experiences and network access parameters for diverse user populations, enhancing flexibility and granular control over your GlobalProtect deployment.

Why Use Multiple Gateway Agent Configurations?

Common scenarios where multiple configurations on a single Gateway are beneficial:

• Different Access Levels (Split Tunneling):

  Providing full-tunnel access (all traffic via VPN) for some user groups (e.g., IT Admins, Developers needing to test external access through corporate IPs) while enabling split-tunneling (only specific corporate traffic via VPN) for others (e.g., Sales team accessing only CRM and internal file shares).

• Operating System Specific Settings:

  Pushing different DNS servers, specific Access Routes, or even different connect methods based on whether the user is connecting from Windows, macOS, Linux, iOS, or Android. For example, mobile devices might get a more restrictive set of routes.

• Device Compliance (HIP-Based Settings):

  Assigning different IP pools, access routes, or DNS servers based on the device's security posture. For instance, fully compliant devices get a standard IP with broad access, partially compliant devices get an IP with limited access, and non-compliant devices might be shunted to an IP pool on a restricted remediation network with access only to update servers and helpdesk.

• BYOD vs. Corporate Devices:

  Providing more restricted access (e.g., limited split-tunnel routes, no "save password" option) for personally owned devices (BYOD) compared to corporate-managed devices. This differentiation is often achieved using HIP profiles or user group membership.

• Regional Differences (Limited Gateway Scope):

  If users from different internal departments or roles connect to the same centralized Gateway, you might assign them different DNS servers or slightly varied access routes pertinent to their primary work resources, based on their user group.

  Note: For true geographical diversity (e.g., users in AMER vs. EMEA vs. APAC), deploying multiple distinct Gateways selected via Portal configuration based on Source Region is generally the preferred approach. However, for role-based differences within a single Gateway's user base, multiple agent configs are ideal.
• Testing and Phased Rollouts:

  Introduce new settings (like a new DNS server or split-tunnel rule) to a specific pilot user group or OS type before rolling it out to everyone, all while using the same production Gateway.

• Varying Client Software Settings:

  Pushing different client settings like "Enable Inactivity Logout," "Disable User Credential Saving," or "Collect HIP data" based on user role or device posture.

Configuration Location and Key Concepts

Location within the Gateway

You configure multiple agent configurations within the settings of a specific GlobalProtect Gateway.

GUI Path: Network > GlobalProtect > Gateways > [Select/Edit Your Gateway Name] > Agent tab

Within the Agent tab, the primary area for these multiple configurations is the Client Settings sub-tab. Here, you will add and order multiple "Client Settings Configuration" blocks.

Core Concept: Matching Criteria & Order

When a GlobalProtect client connects to the Gateway, the firewall evaluates the list of configured Client Settings configurations sequentially from top to bottom .

Flowchart of Gateway Agent Configuration Matching Logic.

Matching Criteria & Order of Evaluation

The effectiveness of multiple agent configurations hinges on correctly defining the matching criteria and the order of these configurations.

Matching Criteria

Each Client Settings configuration block allows you to specify criteria that the connecting client's attributes (OS, user identity, device posture) must meet to receive that specific set of configurations. The key matching criteria tabs within a Client Settings configuration are:

• Operating System Tab: Select specific OS versions (e.g., Windows 10, macOS Ventura, specific Android versions, iOS). You can select 'any' or be very granular.
• User and Group Tab: Select specific Usernames or User Groups. This requires User-ID to be configured and functioning correctly on the firewall so it can identify the user and their group memberships. You can select 'any', specific users, or specific groups.
• HIP Profile Tab: Select one or more pre-configured Host Information Profiles (HIP). This requires HIP Objects and Profiles to be configured and HIP data collection enabled. You can match if the client matches *any* of the selected HIP profiles (OR logic among selected HIP profiles) or if it matches *all* (if that option becomes available in future PAN-OS, currently it's typically 'any of').

Order and "First Match Wins"

The order in which you list your Client Settings configurations is CRITICAL .

• The firewall evaluates these configurations from the top of the list downwards .
• The first configuration block whose criteria are fully met by the connecting client is applied.
• No further configuration blocks in the list are evaluated for that client session once a match is found. This is known as the "first match wins" principle.

The Indispensable Default/Fallback Configuration

It is crucial to have a "catch-all" or default Client Settings configuration block at the very bottom of the list .

• This block should typically have no specific OS, User/Group, or HIP criteria selected (i.e., all set to 'any' or left blank).
• Its purpose is to apply a standard set of baseline settings to any client who doesn't match any of the more specific configurations defined above it.
• Without a default/catch-all, clients not matching any specific rule might not receive any agent configuration, potentially leading to connection failures or unexpected behavior.

Settings Defined Per Agent Configuration

Within each Client Settings configuration block (which is matched by OS, User/Group, and/or HIP criteria), you define the specific parameters that will be pushed down to the GlobalProtect agent on the client's endpoint. Key configurable settings include:

By customizing these settings within different agent configuration blocks, you can deliver precisely tailored network access and agent behavior to different sets of users connecting to the same Gateway.

Configuration Workflow Example

Let's illustrate with a common scenario:

Scenario: You have one GlobalProtect Gateway. You need to:

1. Provide full-tunnel access for the 'IT-Admins' user group.
2. Provide split-tunnel access (only to internal network 10.0.0.0/8 ) for the 'Sales-Users' user group.
3. Provide highly restricted access (perhaps only to a remediation portal, e.g., 192.168.100.10/32 ) for any device that matches a 'Non-Compliant-Device' HIP profile, regardless of user group.
4. Provide a default full-tunnel with basic internet access for all other users who don't meet the above criteria.

Steps:

1. Navigate to Gateway Config:

   Go to Network > GlobalProtect > Gateways > [Your Gateway Name] > Agent tab > Client Settings sub-tab.

2. Configure Non-Compliant Device Settings (Top Rule - Strictest Security Posture First):
   • Click Add .
   • Name: NonCompliant-RestrictedAccess
   • HIP Profile Tab: Select the 'Non-Compliant-Device' HIP profile.
   • Network Settings Tab: Assign a specific IP Pool (e.g., GP-Quarantine-Pool ), and DNS servers that might only resolve remediation sites.
   • Split Tunnel Tab: Under 'Access Route' (Include), click Add and enter 192.168.100.10/32 (the remediation portal). Ensure no other include routes are present for maximum restriction.
   • Click OK .
3. Configure IT Admins Settings (Second Rule - Specific User Group):
   • Click Add .
   • Name: IT-Admins-FullTunnel
   • User and Group Tab: Select the 'IT-Admins' user group.
   • Network Settings Tab: Assign an IP Pool (e.g., GP-IT-Pool ), assign appropriate corporate DNS Servers.
   • Split Tunnel Tab: Leave 'Access Route' (Include) empty . This, combined with not having "Exclude local subnet access" (or similar options if present), typically signifies full tunnel. You might explicitly exclude video streaming sites if desired.
   • Click OK .
4. Configure Sales Users Settings (Third Rule - Another Specific User Group):
   • Click Add .
   • Name: Sales-SplitTunnel
   • User and Group Tab: Select the 'Sales-Users' user group.
   • Network Settings Tab: Assign an IP Pool (e.g., GP-Sales-Pool ), assign appropriate corporate DNS Servers.
   • Split Tunnel Tab: Under 'Access Route' (Include), click Add and enter 10.0.0.0/8 .
   • Click OK .
5. Configure Default Settings (Bottom Rule - Catch-All):
   • Click Add .
   • Name: Default-FullTunnel-Basic
   • OS Tab: Leave as 'any'.
   • User and Group Tab: Leave this empty or set to 'any'.
   • HIP Profile Tab: Leave as 'any'.
   • Network Settings Tab: Assign a default IP Pool (e.g., GP-Default-Pool ) and general DNS servers (e.g., corporate or public).
   • Split Tunnel Tab: Leave 'Access Route' (Include) empty for full tunnel.
   • Click OK .
6. Order the Rules Correctly:

   Use the up/down arrows in the Client Settings list to ensure the rules are in the correct order of precedence (most specific or most restrictive first, down to the general default):

   1. NonCompliant-RestrictedAccess (HIP based, most restrictive access)
   2. IT-Admins-FullTunnel (Specific User Group)
   3. Sales-SplitTunnel (Another Specific User Group)
   4. Default-FullTunnel-Basic (Catch-all)
   If 'IT-Admins-FullTunnel' was above 'NonCompliant-RestrictedAccess', an IT Admin with a non-compliant device would get full tunnel access, bypassing the intended quarantine. Order is paramount!
7. Commit Changes:

   Commit the configuration to the firewall.

Now, when users connect, the firewall will evaluate them against this ordered list and apply the first matching configuration.

Illustrative Diagrams

1. Agent Configuration Matching Logic Flowchart

Flowchart illustrating the top-down, first-match evaluation process for multiple agent configurations.

2. User Group to Configuration Mapping (Conceptual Graph)

Conceptual graph showing different user profiles/states mapping to distinct agent configurations on the same gateway.

3. Sequence Diagram: Client Connection and Configuration Assignment

Sequence diagram showing the interaction for assigning an agent configuration.

4. State Diagram: Possible Effective Configurations for a Client

State diagram illustrating how a client transitions to an effective configuration state based on matching criteria. (Simplified for clarity)

Use Cases & Scenarios

Common Use Cases (Recap)

As previously mentioned, the primary drivers for using multiple agent configurations on a single Gateway include:

• Differentiated Split Tunneling: Full tunnel for some, specific routes for others.
• OS-Specific Network Settings: Tailoring DNS, routes, or client behavior based on the endpoint's operating system.
• HIP-Based Segmentation: Assigning different IP pools, DNS, or access levels (e.g., quarantine, limited, full) based on device compliance.
• BYOD vs. Corporate Device Policies: More restrictive settings for personal devices.

Advanced & Granular Scenarios

Beyond the common cases, multiple agent configurations enable more nuanced control:

• Granular IP Pool Assignment:

  Assign very specific IP pools not just by broad group, but by a combination of user group AND operating system, or user group AND HIP profile. For example, 'Engineers' on 'Linux' get one pool, while 'Engineers' on 'Windows' get another, even if both are compliant.

• Conditional Client Behavior Settings:
  • Disable "Save User Credentials": For users in a 'Contractors' group or for any device matching a 'BYOD' HIP profile.
  • Enforce "Inactivity Logout": With a shorter timeout for devices connecting from less trusted OS versions or with a 'Partially-Compliant' HIP status.
  • Control "Allow User to Disable GlobalProtect": Disallow for standard employees but perhaps allow for IT support staff who might need to troubleshoot.
• Targeted Network Service Configuration:

  Push specific HTTP/HTTPS proxy settings only to users in a 'Guest-Access' group or to devices that are not domain-joined (identified via HIP). Other users might get direct internet access or different proxy settings.

• Phased Deployment of New Features/Settings:

  When introducing a new internal application that requires a specific access route, initially create an agent configuration targeting only the 'Pilot-Users' group with that new route. Once testing is successful, broaden the criteria or merge it into a standard configuration.

• Location-Aware Customization (Indirectly via User Group/HIP):

  If User-ID can populate groups based on a user's office location (e.g., 'NewYork-Users', 'London-Users'), you can assign location-specific DNS servers or access routes via agent configurations matched to these groups, even if they connect to a central Gateway.

• Forcing Specific Connect Methods:

  While often set globally in the Portal agent config, you could theoretically (though less common) attempt to influence connect methods if different OS versions or user types require variations, though this is more nuanced and typically handled at the Portal level or via client deployment methods.

• Different Settings for Pre-Logon vs. User-Logon:

  If using pre-logon, the "machine" context might match a generic agent configuration. Once the user logs in, User-ID and HIP data become available, potentially matching a more specific, user-centric agent configuration. This requires careful planning of the "pre-logon" agent config versus subsequent "user-logon" configs.

Caveats & Gotchas

While powerful, using multiple Gateway Agent Configurations comes with points to watch out for:

• Order, Order, Order!: This cannot be stressed enough. The top-down, first-match rule means incorrect ordering will lead to unintended configurations being applied. Always place more specific rules above more general ones.
• Missing Default/Catch-All: Failure to include a comprehensive default configuration at the bottom of the list can result in some clients not receiving any agent settings, leading to connection issues or unexpected behavior.
• Complexity Creep:

  Having a very large number of granular agent configurations can become complex to manage, troubleshoot, and document. Strive for a balance between granularity and manageability. Consolidate where possible.

• Dependency on Matching Criteria Data:
  • User-ID Accuracy: If matching by User or Group, User-ID must be functioning correctly and providing timely user-to-IP mapping and group information. Delays or errors in User-ID can lead to incorrect config assignment.
  • HIP Data Accuracy & Timeliness: If matching by HIP Profile, the GlobalProtect agent must successfully collect and submit HIP data, and the firewall must process it correctly. Issues with HIP (e.g., outdated content versions, agent problems) will affect matching.
• Troubleshooting Specificity:

  When a user reports an issue (e.g., wrong IP, cannot access X), you need to determine which agent configuration block they actually matched. Checking system logs for GlobalProtect connections often reveals the applied agent config name.

  Monitor > Logs > System (filter for subtype globalprotect and search for username or IP). The log entry for a successful connection often indicates the name of the agent configuration that was applied.

• "AND" Logic within a Block: Remember that if you specify OS, User/Group, AND HIP Profile within a single configuration block, all conditions must be met for that block to match. This is powerful but can be tricky if one criterion is unintentionally too restrictive.
• Changes Require Commit: Like any firewall configuration change, modifications to Gateway Agent Configurations require a commit to take effect.
• Client Reconnection for Changes: If an active user's attributes change in a way that would make them match a different agent configuration (e.g., they are added to a new group, their HIP status changes), they typically need to disconnect and reconnect to the Gateway for the new configuration to be evaluated and applied. The Gateway doesn't dynamically push a new full agent config mid-session without a reconnect. (Though HIP-based *policy* changes can take effect more dynamically based on periodic HIP updates).
• Clarity of Naming: Use very clear and descriptive names for your agent configuration blocks (e.g., Win10-Sales-Compliant-SplitDNS ). This significantly aids in understanding and troubleshooting.
• Testing Each Path: Thoroughly test client connections for each distinct set of matching criteria to ensure the correct agent configuration is applied and functions as expected.

Agent Configs on One Gateway vs. Multiple Actual Gateways

It's important to distinguish between using multiple Agent Configurations on a single Gateway versus deploying multiple distinct GlobalProtect Gateway instances (which could be on the same firewall or different firewalls).

Multiple Agent Configurations on a SINGLE Gateway:

• Purpose: Provide different client-side settings (IP pool, DNS, split tunnel, client behavior) to diverse user groups/OS/HIP profiles connecting to the same Gateway IP address/FQDN .
• Firewall Object: One GlobalProtect Gateway object in PAN-OS.
• Authentication: Typically uses the same authentication profile defined for that single Gateway.
• Ideal for: Role-based, OS-based, or posture-based customization for users who would otherwise connect to the same logical access point.

Multiple Distinct GlobalProtect Gateways:

• Purpose:
  • Geographical Distribution: Gateways in different regions (e.g., US-East, EMEA, APAC) to provide lower latency for users in those regions.
  • High Availability/Redundancy: Multiple gateways for failover.
  • Different Authentication Requirements: One gateway for SAML MFA, another for RADIUS, another for Kerberos (though often a single gateway can support multiple auth methods sequentially via Authentication Policy).
  • Completely Separate Network Access/Security Scopes: A gateway for internal users (Internal Gateway) and another for external remote access (External Gateway). Or a gateway for standard corporate access and another highly restricted gateway for contractors.
  • Capacity Scaling: Distributing load across multiple physical or virtual firewall instances each running a gateway.
  • Different IP Addressing/Interfaces: Each gateway can listen on a different interface and IP address.
• Firewall Object(s): Multiple GlobalProtect Gateway objects in PAN-OS.
• Authentication: Each gateway can have its own distinct authentication profile.
• Gateway Selection: The GlobalProtect Portal plays a key role in directing clients to the appropriate distinct gateway, often based on:
  • Source Region: Portal assigns gateways based on the client's geographical source IP.
  • Priority: Manually configured priority list of gateways.
  • OS: Portal can direct different OS types to different gateways (less common for this specific purpose than agent configs).
• Ideal for: True geographical diversity, scaling, distinct authentication realms, or fundamentally different access purposes.

You can, of course, use both: have multiple distinct Gateways, and each of those Gateways can itself have multiple Agent Configurations to further tailor the experience for users connecting to that specific Gateway instance.

PCNSE Exam Focus for Multiple Gateway Agent Configurations

For the PCNSE exam, understanding how to tailor the GlobalProtect client experience using multiple agent configurations on a single gateway is crucial. Key areas of focus include:

• Core Mechanism:
  • Knowing that multiple agent configurations are set within the Client Settings tab of a single GlobalProtect Gateway's agent configuration.
  • Understanding the top-down, first-match wins evaluation logic.
• Matching Criteria:
  • Identifying the available matching criteria: Operating System, User and Group, HIP Profile .
  • Understanding the AND logic applied when multiple criteria (OS, User/Group, HIP) are specified within a single agent configuration block.
• Order of Precedence:
  • The critical importance of ordering the agent configuration blocks correctly (most specific to least specific).
  • The necessity and placement of a default/catch-all configuration at the bottom of the list.
• Configurable Settings:
  • Being familiar with the common settings that can be customized per agent configuration block:
    • IP Pools
    • DNS Servers & Suffixes
    • Split Tunneling: Access Routes (Include/Exclude IP-based), Domain/Application-based (Include/Exclude FQDN/App-ID). Understanding that empty include routes often mean full tunnel.
    • Basic client behavior settings (e.g., save credentials, inactivity logout).
• Use Cases/Scenarios:
  • Ability to determine how to configure agent settings to meet requirements like:
    • Full tunnel for Group A, split tunnel for Group B.
    • Different DNS for Windows vs. macOS.
    • Quarantine IP/DNS for non-compliant HIP devices.
• Troubleshooting:
  • Knowing where to look to verify which agent configuration was applied to a client (e.g., System Logs for GlobalProtect).
  • Common reasons for misconfiguration (e.g., incorrect order, missing default, User-ID/HIP issues affecting matching).
• Distinction:
  • Briefly understanding how this differs from deploying multiple *actual* GlobalProtect Gateways (which are selected via the Portal).

GlobalProtect Gateway Agent Configurations - Interactive Quiz

Test your knowledge on configuring multiple agent settings for a GlobalProtect Gateway.