Changes to Default Behavior
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
-
- Prisma Access China
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
-
-
-
- 5.2 Preferred and Innovation
- 5.1 Preferred and Innovation
- 5.0 Preferred and Innovation
- 4.2 Preferred
- 4.1 Preferred
- 4.0 Preferred
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
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.
|
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:
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:
|
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.