>
    Strata Copilot
    Changes to Default Behavior for Prisma Access 6.1 and 6.1.1
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma Access
    3. Prisma Access Release Notes
    4. Prisma Access Release Information
    5. Changes to Default Behavior for Prisma Access 6.1 and 6.1.1
    Download PDF
    Prisma Access

    Changes to Default Behavior for Prisma Access 6.1 and 6.1.1

    Table of Contents

    Changes to Default Behavior for Prisma Access 6.1 and 6.1.1

    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Strata Cloud Manager)
    • Prisma Access (Managed by Panorama)

    Changes to Default Behavior for Prisma Access 6.1.1

    The following table details the changes in default behavior for Prisma Access version 6.1.1.
    ComponentChange
    Dataplane Upgrade Considerations for PAN-OS 10.2 to 11.2.7 and PAN-OS 10.2.4 to 10.2.10
    If you have been notified that you are part of a PAN-OS dataplane upgrade, make a note of the following considerations after your dataplane has been upgraded:
    PAN-OS 10.2 to 11.2.7 Upgrades: In addition to checking the Upgrade and Downgrade considerations and Known Issues for PAN-OS 11.2.7, be aware of the following issues after your dataplane is upgraded:
    Mobile Users Issues:
    • Authentication Override Cookie Lifetime cannot exceed the Tunnel Login Lifetime value (Applies to GlobalProtect and Prisma Agent Deployments): The Authentication Override Cookie Lifetime cannot exceed the Tunnel Login Lifetime value. If the Authentication Override Cookie Lifetime is greater than the Tunnel Login Lifetime, change the value of the cookie lifetime so it is lower. This change further strengthens the security of the authentication override cookie by preventing its use after the tunnel login lifetime expires.
    • Use Default Browser Option Select in Client Authentication Settings (Applies to GlobalProtect Deployments Only): The Use Default Browser option is enabled in the Client Authentication setting of the portal configuration if the portal agent configuration has the Use Default Browser for SAML Authentication option enabled. If the Use Default Browser for SAML Authentication option is set to No in the app settings, then the Use Default Browser option is not added to the configuration after the upgrade and the option is not displayed on the Client Authentication screen.
    Remote Network and Service Connections Issues:
    • IKE Crypto Validation Checks for Multiple IKE Gateways with different IKE Crypto Profiles: As a result of PAN-240618, a validation and commit error occurs if you configure multiple IKE Gateways with different IKE Crypto Profiles while using dynamic peering. For more information and remediation procedures, see Action Required: IKE Crypto Profile Changes in PAN-OS 11.2.
    • Default IKE Version Changed from IKEv1 to IKEv2: We have changed the default IKE protocol version support from IKEv1 to IKEv2.If you have not configured the IKE protocol version in the IKE gateway configuration, then PAN-OS supports the IKEv2 protocol version by default. Make sure that your peer CPE for tunnels has the IKEv2 set after the upgrade or you might experience tunnel connection issues.
    Authentication Issues:
    • Authentication Portal Profile Errors Not Displaying in Commit Validation: If you have configured Authentication Portal (Captive Portal) and if all possible authentication methods (Certificate Authentication Profile and Client Certificate Authentication) are set to None, this misconfiguration doesn’t display under Commit Validate. However, this authentication misconfiguration is displayed during the commit and causes a commit error.
    Enterprise Data Loss Prevention (Enterprise DLP) Issues:
    • File Uploads Can Fail if an HTTP 100 is Received: When Enterprise DLP is enabled, file uploads might unexpectedly fail when an HTTP 100 continue response is received from the server during file uploads.
    PAN-OS 10.2.4 to 10.2.10 upgrades: After upgrading from PAN-OS 10.2.4 to PAN-OS 10.2.10, Prisma Access does not add Mutual TLS (mTLS) websites that require client certificate authentication using the DN list to the SSL decryption exclusion cache list. As a workaround, you can bypass the websites from SSL decryption.
    Potential IP Address Changes During Location Reboarding
    Starting March 20, 2026, if you remove (deboard) and then re-add (onboard) the same location, Prisma Access might assign a different public IP address to that location. This behavior applies to the following location types in a subset of Prisma Access locations:
    Affected deployments—This potential IP address change affects Prisma Access deployments where:
    • You’ve deboarded and then onboarded the same location in an affected location.
    • You’ve pre-allocated IP addresses in an affected mobile user location.
    Affected locations—This change only affects the following locations:
    • Australia South
    • Canada Central
    • Canada East
    • France South
    • Japan Central
    • Japan South
    • Saudi Arabia
    • South Korea
    • Sweden
    • Switzerland
    • United Arab Emirates
    • UK
    • US West
    • US East
    Required actions:
    For mobile user locations: After deboarding the new location, we recommend that you run the API with an action_type of preallocate or use the IP Capacity Planning feature to check the IP addresses for your locations against your existing allow lists.
    For remote network, service connection, or explicit proxy locations: Verify the IP address by running the API script or navigating to the Strata Cloud Manager or Panorama UI, locating the reboarded location, and verifying the assigned IP address against your existing allow lists.
    • If the IP address remains the same, you do not need to take further action.
    • If Prisma Access assigns a new IP address, add the new address to your organization’s allow lists to ensure continued connectivity.
    • For Explicit Proxy location, if the Ingress IP (NLB IP) also changes, you may need to adjust the on-premises firewall rules to allow this new ingress IP address.

    Changes to Default Behavior for Prisma Access 6.1

    The following table details the changes in default behavior for Prisma Access version 6.1.
    ComponentChange
    Strict Source URL Format Enforced for External Dynamic Lists Used by Explicit Proxy
    Starting with Prisma Access 6.1.0, Prisma Access enforces a strict format for the source URLs of External Dynamic Lists (EDLs) referenced by Explicit Proxy configurations (including shared EDLs and EDLs scoped to the Explicit Proxy device group or Explicit Proxy parent device group). If any EDL source URL does not conform to the required format, the commit fails with the following error:
    Invalid source URL format for EDL "<edl-name>". URL must start with http:// or https:// and be properly formatted.
    A source URL is accepted only if it:
    • Begins with a lowercase http or https scheme
    • Specifies a host that contains no inline credentials, colons, slashes, or whitespace
    • Uses a digits-only port number, if a port is specified
    • Begins any path component with /
    Predefined EDLs are exempt.
    The following examples would pass commit checks:
    • https://feeds.example.com/list.txt/
    • https://feeds.example.com:8443/list.txt
    • http://10.20.30.40:8080/feed.txt
    The following examples would fail commit checks and block the commit:
    • https://user:password@feeds.example.com/list.txt (inline credentials are not allowed)
    • feeds.example.com/list.txt (missing scheme)
    • ftp://feeds.example.com/list.txt/httpsa://... (invalid scheme)
    • https:// (no host)
    • https://feeds.example.com:port/list.txt (non-numeric port)
    • https://feeds.example.com?type=ip (query string not preceded by a / path)
    Workaround: URLs using inline credentials (user:pass@host), a missing/invalid scheme, a non-numeric port, white space, or an unpathed query string will now block the commit. Update any non-conforming EDL source URL to use the format http(s)://host[:port][/path]. For EDLs that previously used inline credentials (user:pass@host), remove the credentials from the URL and configure authentication through the EDL's authentication settings instead.
    Locations added to New and Existing Prisma Access DeploymentsPrisma Access adds new locations starting with the 6.1 release. The newly-added locations are denoted with a single asterisk in the list of Prisma Access locations.
    New deployments have these locations added automatically; for existing deployments, reach out to your Palo Alto Networks account representative to add them, who will contact the Site Reliability Engineering (SRE) team and submit a request.
    The following functionality is not supported for these locations:
    If you require additional functionality, we recommend that you onboard alternate locations.
    Location Groups Changing for the Mexico Central and Mexico West Mobile User Locations
    The Mexico Central and Mexico West locations are changing their IP pool location group starting with the Prisma Access 6.1 release. If you have enabled the Prisma AccessMexico Central or Mexico West mobile user locations, and have created mobile user IP address pools based on location groups, be aware that the location groups have changed:
    • The Mexico Central location changed from ip-pool-group-31 (US-Central) to ip-pool-group-1 (US-Eastern).
      If you’ve enabled the Mexico Central Prisma Access Mobile User location and have added a mobile user IP address pool based on ip-pool-group-31 (US-Central), an update in the Prisma Access infrastructure caused the Strata Cloud Manager or Panorama UI to show Mexico Central in its new pool group ip-pool-group-1 (US-Eastern). However, the Prisma Access infrastructure continues to provide IP addresses from ip-pool-group-31 (US-Central). This is a cosmetic issue and will not cause connectivity issues provided that the IP address pool group is not modified.
    • The Mexico West location changed from ip-pool-group-23 (US-Western) to ip-pool-group-1 (US-Eastern).
      If you’ve enabled the Mexico West Prisma Access Mobile User location and have added a mobile user IP address pool based on ip-pool-group-23 (US-Western), an update in the Prisma Access infrastructure caused the Strata Cloud Manager or Panorama UI to show Mexico West in its new pool group ip-pool-group-1 (US-Eastern). However, the Prisma Access infrastructure continues to provide IP addresses from ip-pool-group-23 (US-Western). This is a cosmetic issue and will not cause connectivity issues provided that the IP address pool group is not modified.
    To align with the updated Private IP allocation structure, if you are affected, you must perform the following steps immediately:
    1. Preallocate public IP address for Mexico Central and Mexico West Prisma Access location using APIs, or contact your Palo Alto Networks account representative to assist with this process.
    2. Allow list these public IP addresses in your SaaS applications.
    3. Deboard the Mexico Central Prisma Access location.
    4. Deboard the Mexico West Prisma Access location.
    5. Push your configuration (Push ConfigPush for Prisma Access (Managed by Strata Cloud Manager) deployments or CommitCommit & Push Prisma Access (Managed by Panorama) deployments) to save the changes
    6. After the push is successful, re-onboard the Mexico Central and Mexico West PA locations.
    7. Configuring new mobile user IP address pool allocation for users coming from these locations, using the new, correct pool group: US-Eastern (ip-pool-group-1).

    Action Required: IKE Crypto Profile Changes in PAN-OS 11.2

    As part of the commitment to maintaining a highly secure and robust infrastructure, Prisma Access is upgrading the dataplane from PAN-OS 10.2 to PAN-OS 11.2. Starting with PAN-OS 11.2, a stricter validation check has been introduced during the configuration commit process for IKE Gateways, which was addressed with PAN-240618.
    Previously, you could configure multiple IKE Gateways with different IKE Crypto Profiles while using dynamic peering. However, this configuration can lead to tunnel establishment failures when the firewall attempts to dynamically match the incoming connection to an IKE gateway. To prevent these silent failures, PAN-OS 11.2 proactively blocks the commit if multiple IKE Crypto Profiles are assigned to gateways utilizing dynamic peering.

    Symptoms and Error Messages

    If the configuration violates this new validation check, the Prisma Access upgrade commit will fail with an error similar to the following message:
    IKEv2 gateway CUSTOMER_RN_TUNNEL_1 should use the same IKE crypto profile as CUSTOMER_RN_TUNNEL_2 (IKEv2: Auto_PA_SDWAN_IKECrypto).(Module: ikemgr)
    IKEv2 gateway CUSTOMER_RN_TUNNEL_1 should use the same IKE crypto profile as CUSTOMER_RN_TUNNEL_3 (IKEv2: Auto_PA_SDWAN_IKECrypto).(Module: ikemgr)
    client ikemgr phase 1 failure
    Commit failed

    Required Action: Standardize the IKE Crypto Profile

    To successfully complete the upgrade, you must ensure that you configure all IKE gateways that use dynamic peering to use the exact same IKE Crypto Profile.
    Critical Prerequisite: Peer Device (Customer DC Router) Updates: When you standardize your IKE gateways to a single IKE Crypto Profile on the Prisma Access side, you must ensure that you also update the corresponding peer devices (for example, your on-premises Customer DC Routers) to match this profile. A mismatch between the Prisma Access IKE Crypto Profile and the customer DC router will result in a Crypto Mismatch issue, preventing the IPSec tunnels from establishing.

    Remediation Steps

    To remediate the IKE gateway misconfiguration, complete one of the following procedures.
    Before you start:
    • Make a note of the message you received, showing the tunnel names that used different IKE gateways.
    • Determine the correct IKE gateway settings to use for the tunnel for which you received the error message.
    To simplify configuration, consider using common IKE gateway settings for all tunnels.
    Prisma Access (Managed by Strata Cloud Manager) deployments:
    1. Log in to Strata Cloud Manager.
    2. Go to the ConfigurationNGFW and Prisma AccessConfiguration ScopePrisma Access.
    3. Find the tunnel or tunnels that received the mismatch error, select it, and Edit the tunnel settings.
      You can find the tunnel in either the Service Connections or Remote Networks area.
    4. Review the IKE gateway settings configured for the affected Remote Network or Service Connection tunnel.
    5. In the configuration panel, select the IKE Advanced Options and find the IKE Crypto Profile assignment.
    6. Update the profile to match your standardized profile.
    7. Save your changes.
    8. Repeat this process for all remaining dynamic peering IKE gateways.
    9. Push Config to push the configuration changes to your Prisma Accessdeployment.
    Prisma Access (Managed by Panorama) deployments:
    1. Log in to the Panorama that manages Prisma Access.
    2. Go to NetworkNetwork ProfilesIKE Gateways.
      Select either the Remote_Network_Template (for remote networks) or the Service_Conn_Template (for service connections).
    3. Review the list of your configured IKE Gateways.
    4. Look at the IKE Crypto Profile column to identify gateways using different profiles.
    5. Determine the standardized IKE Crypto Profile you wish to use across all dynamic peering gateways (e.g., Auto_PA_XXX_IKECrypto).
    6. Select an IKE Gateway that needs to be updated by clicking on its name.
    7. In the configuration dialog, navigate to the Advanced Options tab.
    8. Locate the IKE Crypto Profile drop-down menu.
    9. Change the selection to your standardized IKE Crypto Profile.
    10. Click OK.
    11. Repeat steps 6 through 10 for all other IKE gateways using dynamic peering.
    12. Commit and Push your changes.

    Reference Documentation and Additional Information

    For more detailed information regarding IKE Gateway setup, configurations, and visual UI references, please refer to the official Palo Alto Networks documentation. The Set Up an IKE Gateway document includes standard visual layouts for the IKE Gateway configuration tabs mentioned previously:

    © 2026 Palo Alto Networks, Inc. All rights reserved.