>
    Changes to Default Behavior
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma
    3. Prisma Access
    4. Prisma Access (Panorama Managed) Release Information
    5. Changes to Default Behavior
    Download PDF

    Changes to Default Behavior

    Table of Contents

    Changes to Default Behavior

    The following tables detail the changes in default behavior for Prisma Access version 3.2 Preferred and Innovation.

    Changes to Default Behavior—Prisma Access 3.2.1 Preferred and Innovation

    The following table details the changes in default behavior for Prisma Access version 3.2.1 Preferred and Innovation.
    Component
    Change
    1,000 Mbps Support for Remote Networks That Have More Than 500 Mbps of Bandwidth
    If you are upgrading your Cloud Services plugin version from an earlier Prisma Access version to 3.2.1, any locations that have more than 500 Mbps assigned to their corresponding compute location can support up to 1,000 Mbps of bandwidth.
    While bandwidth enforcement is not currently applied, Prisma Access reserves the right to enforce the allocated bandwidth when the consumption exceeds the allocation. You will be notified prior to applying the enforcement.
    For any remote network locations that have more than 500 Mbps allocated to their corresponding compute location, Prisma Access can increase the bandwidth for a remote network using an autoscaling mechanism that is triggered when the bandwidth consumption on the remote network requires additional capacity.
    When this one-time scaling event occurs, you can expect to see a brief interruption in service (15 to 20 seconds).
    If you have allocated bandwidth to a compute location that is 500 Mbps or less, bandwidth is not increased to 1,000 Mbps and this autoscaling mechanism does not take effect.
    Remapped Israel and France South Locations
    To better optimize performance of Prisma Access, starting with the Prisma Access 3.2 infrastructure upgrade, the Israel location is remapped to the Middle-East West compute location and the France South location is remapped to the new compute location Europe Northwest (Paris).
    These compute location remappings apply to all existing Prisma Access deployments, even if you have not installed the Cloud Services plugin 3.2.1. Your current compute location-to-location mapping is not affected; however, if you have an existing Prisma Access deployment that uses one of these locations and you want to take advantage of the remapped compute location, follow the procedure to add a new compute location to a deployed Prisma Access location.
    New deployments have this mapping applied automatically.
    Licensing Changes for Prisma Access Mobile Users
    Due to the licensing changes made for Prisma Access Explicit Proxy (You can use the same Mobile Users license for both Explicit Proxy and GlobalProtect), the following change is made:
    For mobile user deployments, a
    unit
     is defined as one mobile user. When you assign units in Prisma Access from your Mobile users license, each unit allows a mobile user to utilize Prisma Access—GlobalProtect, Prisma Access—Explicit Proxy, or both GlobalProtect and Explicit Proxy for the same user. See Prisma Access 3.2.1 Mobile User Licensing Change Examples for examples of the behavior change.
    Mobile User Count
    To prevent the same mobile usernames (appearing in different formats) from being counted multiple times, Panorama Managed Prisma Access normalizes all usernames to the
    user.name@domain.com
     format.
    Before normalization, instances of the same username (in various formats) are counted as individual users, causing the mobile user counts to be inflated incorrectly.
    After normalization, all usernames will be in the
    user.name@domain.com
     format, and the mobile user counts will accurately reflect the number of users who have connected to Panorama Managed Prisma Access within the last 90 days. If the username is already in the
    user.name@domain.com
     format, the username is not normalized.

    Prisma Access 3.2.1 Mobile User Licensing Change Examples

    The following table provides examples that explain the changes to licensing for Prisma Access Mobile User deployments starting with 3.2.1. These examples assume a deployment with 1,000 mobile user license units.
    Example
    Number of Mobile User License Units Required
    Your organization requires 1,000 mobile users to use Explicit Proxy when working at the branch and GlobalProtect when working remotely
    1,000 Units (previously, 2,000 units would be required)
    Your organization requires 1,000 mobile users to use Explicit Proxy and GlobalProtect at all times to meet network and compliance needs
    1,000 Units (previously, 2,000 units would be required)
    An educational institution wants to secure 500 students with Explicit Proxy and 500 teachers with Explicit Proxy
    1,000 Units (no change)
    Your organization wants to secure 1,000 servers in the branch with Explicit Proxy
    1,000 Units (no change)

    Changes to Default Behavior—Prisma Access 3.2 Preferred and Innovation

    The following table details the changes in default behavior for Prisma Access version 3.2 Preferred and Innovation.
    Enforcement of QoS Rules for Service Connections and Remote Network Connections
    Starting with the Cloud Services plugin 3.2.0-h26, Prisma Access will enforce QoS limits on remote networks and service connections.
    • For service connections, if you create a QoS profile in the
      Service_Conn_Template
       that has an
      Egress Max
       value of more than 1 Gbps and apply it to a service connection, you will receive a Commit Error indicating that the
      Egress Max
       bandwidth configured in the QoS profile is larger than the maximum value.
      Prisma Access calculates service connection bandwidth per service connection IPSec tunnel and not cumulatively across multiple tunnels. To fix this error, specify an
      Egress Max
       value of 1 Gbps for the QoS profiles you apply to a service connection.
    • For remote network connections, you will receive an error if the following conditions apply:
      • You create a QoS profile in the
        Remote_Network_Template
        .
      • You apply the QoS profile to a location.
      • The
        Egress Max
         value for the QoS profile exceeds the allocated bandwidth for the compute location that the location corresponds to.
      In this case, you receive a Commit Error indicating that the
      Egress Max
       bandwidth configured in the QoS profile is larger than the maximum value.
      To fix this error, either specify an
      Egress Max
       value of 0, or specify an Egress Max value that is less than the bandwidth you specified in the QoS profile you apply to a remote network location compute location.
    Reserved IP Addresses for GlobalProtect and Explicit Proxy Deployments Becoming Active
    If you have a Prisma Access Mobile Users— GlobalProtect or Mobile Users—Explicit Proxy deployment, the classification of the allocated gateway and portal IP addresses (for GlobalProtect deployments) and Authentication Cache Service (ACS) and Network Load Balancer (NLB) IP addresses (for Explicit Proxy deployments) is changing.
    Previously, two IP addresses are allocated for each gateway and portal for Mobile Users—GlobalProtect deployments: one IP address that is active and one that is reserved for autoscale events or infrastructure or dataplane upgrade. In addition, one active and one reserved address are allocated for the ACS and NLB for Mobile Users—Explicit Proxy deployments.
    Starting with the Prisma Access 3.2 infrastructure upgrade, all Mobile Users—GlobalProtect gateway and portal and all Explicit Proxy ACS and NLB IP addresses are marked as active for the Prisma Access locations and there are no reserved addresses. The IP retrieval API returns all IP addresses as active.
    In addition, the term
    Active
     refers to IP addresses that have been allocated to the Prisma Access deployment.
    This change ensures that you add all gateway, portal, and ACS IP addresses to your allow lists, which eliminates any issue when a reserved IP address is made active after an autoscaling event or an infrastructure or dataplane upgrade.
    In the API script, the
    addrType
     of
    reserved
     is no longer applicable for Mobile Users—GlobalProtect deployments and does not return any portal or gateway IP addresses.
    For more information, including any actions you need to take, refer to the article on the Palo Alto Networks Live site.
    Remapped Prisma Access Compute Locations
    To better optimize performance of Prisma Access, starting with the Prisma Access 3.2 infrastructure upgrade, the following new compute locations are added and the following locations have been moved to the following new compute locations:
    • Mexico Central, Mexico West, and US South Locations
      —Moved to the US South compute location.
    • Andorra, Portugal, Spain Central, and Spain East Locations
      —Moved to the Europe Southwest compute location.
    • Italy, Kenya, and Monaco Locations
      —Moved to the Europe South compute location.
    • Indonesia Location
      —Moved to the Asia Southeast (Indonesia) compute location.
    In addition, the existing
    Asia Southeast
    compute location is renamed
    Asia Southeast (Singapore)
    .
    These compute location remappings apply to all existing Prisma Access deployments, even if you have not installed the Cloud Services plugin 3.2. Your current compute location-to-location mapping is not affected; however, if you have an existing Prisma Access deployment that uses one of these locations and you want to take advantage of the remapped compute location, follow the procedure to add a new compute location to a deployed Prisma Access location.
    New deployments have this mapping applied automatically.
    Required Steps to Increase Remote Network IPSec Termination Nodes from 500 Mbps to 1000 Mbps
    If you have an existing Prisma Access Remote Network deployment that allocates bandwidth by compute location (aggregate bandwidth deployment), complete the following steps to allow your IPSec termination nodes to support up to 1000 Mbps:
    1. Before installing the Cloud Services plugin 3.2, perform a
      Commit and Push
       operation, making sure that
      Remote Networks
       is specified in the
      Push Scope
      .
    2. Install the 3.2 plugin.
    3. Either perform an additional
      Commit and Push
       operation after installing the plugin, or select
      Commit
      Push to Devices
      .
      In either case, make sure that you have selected
      Remote Networks
       in the
      Push Scope.
    Secure Inbound Access for Remote Network Sites Public IP Address Assignment Changes
    If you use Prisma Access networks to provide inbound access to an application or website at a remote site for internet-connected users, Prisma Access uses a more predictable way of assigning the private IP-to-public IP address assignments for the apps you want to secure. See Public IP Address Assignment Changes for Providing Secure Inbound Access for Remote Network Sites for details.
    Palo Alto Networks recommends that you do not make any changes to your secure inbound access deployment during the window between when the infrastructure upgrade occurs for Prisma Access 3.2 and the time when you install the Cloud Services plugin for 3.2, as unpredictable results might occur.

    Public IP Address Assignment Changes for Providing Secure Inbound Access for Remote Network Sites

    When you use Prisma Access to provide inbound access to an application or website at a remote site, you assign a private IP address, port number, and protocol combination for each application. You then specify Prisma Access to use either 5 or 10 public IP addresses for the applications or websites. Prisma Access maps the private IP addresses you specify to public IP addresses.
    In order to offer more predictability for public IP address mapping when you add a new app, Prisma Access public IP uses the following IP assignment algorithm, as described in the following examples.
    The following example configuration has a secure inbound access deployment with 5 public IP addresses, and with six applications mapped to those addresses. None of these apps are dedicated (that is, you did not specify Prisma Access to dedicate a single application to a single public IP address).
    Because app1 and app2 have a unique private IP address/Port/Protocol combination, they can share a public IP address. If both apps used port 80, they could not share a public IP address.
    App Name
    Private IP Address
    Port
    Protocol
    Dedicated
    Public IP
    app1
    192.168.1.1
    80
    TCP
    No
    35.1.1.1
    app2
    192.168.1.2
    81
    TCP
    No
    35.1.1.1
    app3
    192.168.1.3
    80
    TCP
    No
    35.1.1.2
    app4
    192.168.1.4
    80
    TCP
    No
    35.1.1.3
    app5
    192.168.1.5
    80
    TCP
    No
    35.1.1.4
    app6
    192.168.1.6
    81
    TCP
    No
    35.1.1.5
    If you remove an app (app1 in this example), Prisma Access still allocates five IP addresses for the remaining apps.
    App Name
    Private IP Address
    Port
    Protocol
    Dedicated
    Public IP
    app2
    192.168.1.2
    81
    TCP
    No
    35.1.1.1
    app3
    192.168.1.3
    80
    TCP
    No
    35.1.1.2
    app4
    192.168.1.4
    80
    TCP
    No
    35.1.1.3
    app5
    192.168.1.5
    80
    TCP
    No
    35.1.1.4
    app6
    192.168.1.6
    81
    TCP
    No
    35.1.1.5
    If you add an app that requires a
    Dedicated IP
     address, that app requires the allocation of another public IP address, which puts your deployment over the limit of 5 public IP addresses and would cause a validation error on commit.
    App Name
    Private IP Address
    Port
    Protocol
    Dedicated
    Public IP
    app2
    192.168.1.2
    81
    TCP
    No
    35.1.1.1
    app3
    192.168.1.3
    80
    TCP
    No
    35.1.1.2
    app4
    192.168.1.4
    80
    TCP
    No
    35.1.1.3
    app5
    192.168.1.5
    80
    TCP
    No
    35.1.1.4
    app6
    192.168.1.6
    81
    TCP
    No
    35.1.1.5
    dedicated_app
    192.168.1.1
    8080
    TCP
    Yes
    34.141.3.106
    To offer a more predictable IP address assignment for newly-added applications, Prisma Access changes the behavior of secure inbound access for remote networks. As part of this enhancement, the service also improves IP stickiness with a new algorithm that introduces a predictable sorting order to help your system administrators predict the public IP address that will be assigned when they onboard a new inbound application.
    The new algorithm creates a list of groups made up of unique public IP addresses, sorts the groups by the public IP addresses that are allocated to each group, and then stores the list in the service infrastructure. Prisma Access uses this sorted list of groups to find the available public IP address that can be assigned to a new application, after Prisma Access checks that the new application’s private IP address/port/protocol combination does not conflict with any other apps in that public IP address.
    The following example configuration has a secure inbound access deployment with 5 public IP addresses. Prisma Access has sorted the apps using the public IP addresses in descending order. One app (app7) is dedicated, and Prisma Access does not share this public IP address with any other apps.
    App Name
    Private IP Address
    Port
    Protocol
    Dedicated
    Public IP
    app1
    192.168.1.1
    81
    TCP
    No
    35.141.1.1
    app2
    192.168.1.2
    80
    TCP
    No
    35.141.1.1
    app3
    192.168.1.3
    80
    TCP
    No
    35.141.1.2
    app4
    192.168.1.4
    80
    TCP
    No
    35.141.1.3
    app5
    192.168.1.5
    80
    TCP
    No
    35.141.1.4
    dedicated_app
    192.168.1.7
    8080
    TCP
    Yes
    34.141.1.5
    When the administrator adds a new non-dedicated application, Prisma Access evaluates the public IP addresses from top to bottom, and adds the app to the public IP with the lowest IP address.
    In the following example, the administrator has added a new app, app6, with a private IP address of 192.168.1.6, a port of 81, and a protocol of TCP. Prisma Access evaluates the public-to-private IP address mapping as follows:
    • Prisma Access evaluates the public IP address 35.141.1.1 first, and determines that there is already an app with port 81 assigned to that public IP address.
    • Prisma Access evaluates the next public IP address in the list (35.141.1.2), and determines that the private IP address/port/protocol mapping does not conflict with any other apps assigned to this public IP address.
    • Prisma Access assigns the new app app6 to the public IP address 35.141.1.2.
    • In all cases, Prisma Access ignores any public IP address that has a dedicated app assigned to it (34.141.1.5 in this case).
    App Name
    Private IP Address
    Port
    Protocol
    Dedicated
    Public IP
    app1
    192.168.1.1
    81
    TCP
    No
    35.141.1.1
    app2
    192.168.1.2
    80
    TCP
    No
    35.141.1.1
    app3
    192.168.1.3
    80
    TCP
    No
    35.141.1.2
    app4
    192.168.1.4
    80
    TCP
    No
    35.141.1.3
    app5
    192.168.1.5
    80
    TCP
    No
    35.141.1.4
    app6
    192.168.1.6
    81
    TCP
    No
    35.141.1.2
    dedicated_app
    192.168.1.7
    8080
    TCP
    Yes
    34.141.1.5
    The following rules apply to the deletion of an application:
    • If the administrator deletes an application from the configuration, it does not impact the public IP allocation for any other apps.
    • If the administrator deletes an application that has a public IP address only allocated to itself, Prisma Access deletes that public IP address from the deployment, and that public IP address might not be reused in the secure inbound access deployment.

    Recommended For You

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