Changes to Default Behavior
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
3.2 Preferred and Innovation
- 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
-
- Features in Prisma Access 3.2 and 3.2.1
- Changes to Default Behavior
- Upgrade the Cloud Services Plugin
- Prisma Access Known Issues
- Prisma Access Addressed Issues
- Release Updates for Reports
-
- Features in Prisma Access 3.1 Preferred and Innovation
- Features in Prisma Access 3.0 Preferred and Innovation
- Features Introduced in Prisma Access 2.2 Preferred
- Features Introduced in Prisma Access 2.1 Innovation
- Features Introduced in Prisma Access 2.1 Preferred
- Features Introduced in Prisma Access 2.0 Innovation
- Features Introduced in Prisma Access 2.0 Preferred
- Features Introduced in Prisma Access 1.8
- Features Introduced in Prisma Access 1.7
- Features Introduced in Prisma Access 1.6.1
- Features Introduced in Prisma Access 1.6.0
- Features Introduced in Prisma Access 1.5.1
- Features Introduced in Prisma Access 1.5.0
- Features Introduced in Prisma Access 1.4.0
- Features Introduced in Prisma Access 1.3.1
- Features Introduced in Prisma Access 1.3.0
- Features Introduced in Prisma Access 1.2.0
- Features Introduced in Prisma Access 1.1.0
- Getting Help
-
-
-
-
- Allocate Licenses for Prisma Access (Managed by Strata Cloud Manager)
- Plan Service Connections for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Add Additional Locations for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Enable Available Add-ons for Prisma Access (Managed by Strata Cloud Manager)
- Enable Dynamic Privilege Access for Prisma Access (Managed by Strata Cloud Manager)
- Search for Subscription Details
- Share a License for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Increase Subscription Allocation Quantity
-
- Activate a License for Prisma Access (Managed by Strata Cloud Manager) and Prisma SD-WAN Bundle
-
- Onboard Prisma Access
-
4.0 & Later
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
- Prisma Access China
-
- Set Up Prisma Access
- Configure the Prisma Access Service Infrastructure
- Remote Networks: IPSec Termination Nodes and Service IP Addresses
- Remote Networks: IP Address Changes Related To Bandwidth Allocation
- Remote Networks: Service IP Address and Egress IP Address Allocation
- API Examples for Retrieving Prisma Access IP Addresses
- Get Notifications When Prisma Access IP Addresses Change
- Prisma Access Zones
- DNS for Prisma Access
- High Availability for Prisma Access
-
- Enable ZTNA Connector
- Delete Connector IP Blocks
- Set Up Auto Discovery of Applications Using Cloud Identity Engine
- Private Application Target Discovery
- Security Policy for Apps Enabled with ZTNA Connector
- Monitor ZTNA Connector
- View ZTNA Connector Logs
- Preserve User-ID Mapping for ZTNA Connector Connections with Source NAT
-
- Enable Dynamic Privilege Access for Prisma Access Through Common Services
- Authorize User Group Mapping in Cloud Identity Engine for Dynamic Privilege Access
- Enable the Access Agent
- Set Up the Agent Infrastructure for Dynamic Privilege Access
- Create a Snippet
- Create a Project
- Traffic Steering for Dynamic Privilege Access
- Push the Prisma Access Agent Configuration
- Download the Dynamic Privilege Access Enabled Prisma Access Agent Package
-
- Install the Prisma Access Agent
- Log in to the Dynamic Privilege Access Enabled Prisma Access Agent
- Change Preferences for the Dynamic Privilege Access Enabled Prisma Access Agent
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Location
- Switch to a Different Project
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Server
- Disable the Dynamic Privilege Access Enabled Prisma Access Agent
- Switch Between the Prisma Access Agent and GlobalProtect App
- View and Monitor Dynamic Privilege Access Users
- View and Monitor Dynamic Privilege Access Projects
- App Acceleration in Prisma Access
-
-
- Planning Checklist for GlobalProtect on Prisma Access
- Set Up GlobalProtect Mobile Users
- GlobalProtect — Customize Tunnel Settings
- GlobalProtect — Customize App Settings
- Ticket Request to Disable GlobalProtect
- GlobalProtect Pre-Logon
- GlobalProtect — Clientless VPN
- Monitor GlobalProtect Mobile Users
- How the GlobalProtect App Selects Prisma Access Locations for Mobile Users
- Allow Listing GlobalProtect Mobile Users
-
- Explicit Proxy Configuration Guidelines
- GlobalProtect in Proxy Mode
- GlobalProtect in Tunnel and Proxy Mode
- Private IP Address Visibility and Enforcement for Agent Based Proxy Traffic
- SAML Authentication for Explicit Proxy
- Set Up Explicit Proxy
- Cloud Identity Engine Authentication for Explicit Proxy Deployments
- Proxy Mode on Remote Networks
- How Explicit Proxy Identifies Users
- Explicit Proxy Forwarding Profiles
- PAC File Guidelines
- Explicit Proxy Best Practices
- Monitor and Troubleshoot Explicit Proxy
- Block Settings for Explicit Proxy
- Use Special Objects to Restrict Explicit Proxy Internet Traffic to Specific IP Addresses
- Access Your Data Center Using Explicit Proxy
- App-Based Office 365 Integration with Explicit Proxy
- Configure Proxy Chaining with Blue Coat Proxy
- IP Address Optimization for Explicit Proxy Users- Proxy Deployments
- DNS Resolution for Mobile Users—Explicit Proxy Deployments
- View User to IP Address or User Groups Mappings
- Report Mobile User Site Access Issues
- Enable Mobile Users to Access Corporate Resources
-
-
- Planning Checklist for Remote Networks
- Allocate Remote Network Bandwidth
- Onboard a Remote Network
- Connect a Remote Network Site to Prisma Access
- Enable Routing for Your Remote Network
- Onboard Multiple Remote Networks
- Configure Remote Network and Service Connection Connected with a WAN Link
- Remote Networks—High Performance
- Integrate a Shared Desktop VDI with Prisma Access Using Terminal Server
-
- Prisma Access Logs
- External Logs and Other Data
- Prisma Access Activity Dashboards and Reports
-
- Get Started with Prisma Access Monitoring in Strata Cloud Manager
- View and Monitor Applications
- View and Monitor App Acceleration
- View Mobile Users
- View and Monitor IPv6 for Mobile Users
- View and Monitor Branch Sites
- View Subscription Usage
- View and Monitor Prisma Access Locations
- View and Monitor Third-Party Device-IDs
- View and Monitor Remote Browser Isolation
- Prisma Access and Autonomous DEM
-
- Multitenancy Configuration Overview
- Plan Your Multitenant Deployment
- Create an All-New Multitenant Deployment
- Enable Multitenancy and Migrate the First Tenant
- Add Tenants to Prisma Access
- Delete a Tenant
- Create a Tenant-Level Administrative User
- Sort Logs by Device Group ID in a Multitenant Deployment
-
- Add a New Compute Location for a Deployed Prisma Access Location
- How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote Network Connections
- Proxy Support for Prisma Access and Strata Logging Service
- Block Incoming Connections from Specific Countries
- Prisma Access for No Default Route Networks
-
-
- Default Routes With Prisma Access Traffic Steering
- Traffic Steering in Prisma Access
- Traffic Steering Requirements
- Default Routes with Traffic Steering Example
- Default Routes with Traffic Steering Direct to Internet Example
- Default Routes with Traffic Steering and Dedicated Service Connection Example
- Prisma Access Traffic Steering Rule Guidelines
- Configure Zone Mapping and Security Policies for Traffic Steering Dedicated Connections
- Configure Traffic Steering in Prisma Access
- Preserve User-ID and Device-ID Mapping for Service Connections with Source NAT
-
- Prisma Access Internal Gateway
-
- Configure Privileged Remote Access Settings
- Set Up the Privileged Remote Access Portal
- Configure Applications for Privileged Remote Access
- Set Up Privileged Remote Access Profiles
- Define Permissions for Accessing Privileged Remote Access Apps
- Configure Split Tunneling for Privileged Remote Access Traffic
- Manage Privileged Remote Access Connections
- Use Privileged Remote Access
-
- Integrate Prisma Access With Other Palo Alto Networks Apps
- Integrate Third-Party Enterprise Browser with Explicit Proxy
-
-
- Connect your Mobile Users in Mainland China to Prisma Access Overview
- Configure Prisma Access for Mobile Users in China
- Configure Real-Name Registration and Create the VPCs in Alibaba Cloud
- Attach the CEN and Specify the Bandwidth
- Create Linux Instances in the Alibaba Cloud VPCs
- Configure the Router Instances
- Onboard the GlobalProtect Gateway and Configure the Prisma Access Portal
-
-
-
- INC_CIE_AGENT_DISCONNECT
- INC_CIE_DIRECTORY_DISCONNECT
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_MU_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_MU_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_DNS_SERVER_UNREACHABLE_ PER_PA_LOCATION
- INC_RN_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_DNS_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_ECMP_TUNNEL_RTT_EXCEEDED_ BASELINE
- INC_RN_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SECONDARY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SITE_CAPACITY_PREDICTION
- INC_SC_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SITE_CAPACITY_PREDICTION
-
- INC_CERTIFICATE_EXPIRY
- INC_GP_CLIENT_VERSION_UNSUPPORTED
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_CAPACITY
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_THRESHOLD
- INC_PA_INFRA_DEGRADATION
- INC_PA_SERVICE_DEGRADATION_PA_LOCATION
- INC_PA_SERVICE_DEGRADATION_RN_ SITE_CONNECTIVITY
- INC_PA_SERVICE_DEGRADATION_SC_ CONNECTIVITY
- INC_RN_ECMP_BGP_DOWN
- INC_RN_ECMP_BGP_FLAP
- INC_RN_ECMP_PROXY_TUNNEL_DOWN
- INC_RN_ECMP_PROXY_TUNNEL_FLAP
- INC_RN_ECMP_TUNNEL_DOWN
- INC_RN_ECMP_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_BGP_FLAP
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_BGP_DOWN
- INC_RN_SECONDARY_WAN_BGP_FLAP
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_FLAP
- INC_RN_SITE_DOWN
- INC_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_RN_SPN_LONG_DURATION_CAPACITY_EXCEEDED _THRESHOLD
- INC_RN_SPN_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_SC_PRIMARY_WAN_BGP_DOWN
- INC_SC_PRIMARY_WAN_BGP_FLAP
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_PRIMARY_WAN_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_BGP_DOWN
- INC_SC_SECONDARY_WAN_BGP_FLAP
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_TUNNEL_FLAP
- INC_SC_SITE_DOWN
- INC_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_SC_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- INC_ZTNA_CONNECTOR_CPU_HIGH
- INC_ZTNA_CONNECTOR_MEMORY_HIGH
- INC_ZTNA_CONNECTOR_TUNNEL_DOWN
-
- AL_CIE_AGENT_DISCONNECT
- AL_CIE_DIRECTORY_DISCONNECT
- AL_MU_IP_POOL_CAPACITY
- AL_MU_IP_POOL_USAGE
- AL_RN_ECMP_BGP_DOWN
- AL_RN_ECMP_BGP_FLAP
- AL_RN_PRIMARY_WAN_BGP_DOWN
- AL_RN_PRIMARY_WAN_BGP_FLAP
- AL_RN_PRIMARY_WAN_TUNNEL_DOWN
- AL_RN_PRIMARY_WAN_TUNNEL_FLAP
- AL_RN_SECONDARY_WAN_BGP_DOWN
- AL_RN_SECONDARY_WAN_BGP_FLAP
- AL_RN_SECONDARY_WAN_TUNNEL_DOWN
- AL_RN_SECONDARY_WAN_TUNNEL_FLAP
- AL_RN_SITE_DOWN
- AL_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- AL_RN_SPN_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_PRIMARY_WAN_BGP_DOWN
- AL_SC_PRIMARY_WAN_BGP_FLAP
- AL_SC_PRIMARY_WAN_TUNNEL_DOWN
- AL_SC_PRIMARY_WAN_TUNNEL_FLAP
- AL_SC_SECONDARY_WAN_BGP_DOWN
- AL_SC_SECONDARY_WAN_BGP_FLAP
- AL_SC_SECONDARY_WAN_TUNNEL_DOWN
- AL_SC_SECONDARY_WAN_TUNNEL_FLAP
- AL_SC_SITE_DOWN
- AL_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_SITE_LONG_DURATION_EXCEEDED_CAPACITY
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- AL_ZTNA_CONNECTOR_CPU_HIGH
- AL_ZTNA_CONNECTOR_MEMORY_HIGH
- AL_ZTNA_CONNECTOR_TUNNEL_DOWN
- New Features in Incidents and Alerts
- Known Issues
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
- Prisma Access 3.2.1 Mobile User Licensing Change Examples
- Changes to Default Behavior—Prisma Access 3.2 Preferred and Innovation
- Public IP Address Assignment Changes for Providing Secure Inbound Access for Remote Network Sites
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.