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 Preferred and Innovation

The following table details the changes in default behavior for Prisma Access version 3.2 Preferred and Innovation.
Component
Change
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
80
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
80
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
80
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
80
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