Planning Checklist—Prisma Access Remote Networks

Aggregate Bandwidth Model
—Bandwidth for your remote networks locations are allocated at an aggregate level per compute location. Each location you onboard has a corresponding compute location for which bandwidth is allocated. You allocate bandwidth per compute location, instead of per location. This method is known as the
aggregate bandwidth model
.
The aggregate bandwidth model is available for all new deployments. If you have an existing deployment that allocated bandwidth by location, you can migrate from allocating bandwidth per location to allocating bandwidth per compute location.
Before you migrate to the aggregate bandwidth model, you should review the migration checklist.
All locations you onboard share the allocated bandwidth for that compute location. For example, you need to onboard four branch offices using remote networks in the Singapore, Thailand, and Vietnam locations. All these locations map to the Asia Southeast compute location. If you allocate 200 Mbps bandwidth to the Asia Southeast compute location, Prisma Access divides the 200 Mbps of bandwidth between the four branch offices you onboarded in that location. If you also add a location in Hong Kong, you note that Hong Kong maps to the Hong Kong compute location, and you would need to add bandwidth to that compute location. Specify a minimum bandwidth of 50 Mbps per compute location.
Prisma Access dynamically allocates the bandwidth based on load or demand per location. Using the previous example where the four sites collectively use up to 200 Mbps, if one or more sites are not using as much bandwidth as the other sites, Prisma Access provides more bandwidth for the locations that are more in demand, giving you a more efficient use of allocated bandwidth. In addition, if one of the sites goes down, Prisma Access reallocates the bandwidth between the other sites that are still up in that compute location.
IPSec Termination Nodes
—You assign an
IPSec termination node
to the remote network during onboarding. Each IPSec termination node can provide you with a maximum of 1,000 Mbps of bandwidth. If you allocate more than 1,000 Mbps of bandwidth to a compute location, Prisma Access provides you with an additional IPSec termination node.
IPSec Termination Nodes and Upgrades from Releases Earlier than 3.2
—Before 3.2, one IPSec Termination Node was allocated for every 500 Mbps of allocated bandwidth in a compute location. If you have a remote network deployment earlier than 3.2 and upgrade to a release that is 3.2.1 or later, and if remote network locations have more than 500 Mbps allocated to their corresponding compute location, every remote network associated with the IPSec Termination Node can support up to 1,000 Mbps of bandwidth. After you upgrade to 3.2 or later, Prisma Access deploys one IPSec Termination Node for every 1,000 Mbps of allocated bandwidth. For existing remote networks, 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. See Changes to Default Behavior in the Prisma Access (Panorama Managed) Release Notes for details.
The current IPSec termination node-to-remote network mapping after the upgrade to 3.2 is unchanged, and the number of IPSec Termination Nodes remain the same. IPSec termination nodes are added or deleted only when you increase or decrease the bandwidth for an existing compute location or when you onboard new compute locations for remote networks.
Service Connection
—If your remote network locations require access to infrastructure in your corporate headquarters to authenticate users or to enable access to critical network assets, you must create a service connection so that headquarters and the remote network locations are connected. If the remote network location is autonomous and does not need to access to infrastructure at other locations, you do not need to set up the service connection (unless your mobile users need access).
Template
—Prisma Access automatically creates a template stack (Remote_Network_Template_Stack) and a top-level template (Remote_Network_Template) for Prisma Access for networks. To Onboard and Configure Remote Networks, you will either need to configure the top-level template from scratch or leverage your existing configuration, if you are already running a Palo Alto networks firewall on premise. The template requires the settings to establish the IPSec tunnel and Internet Key Exchange (IKE) configuration for protocol negotiation between your remote network location and Prisma Access for networks, zones that you can reference in security policy, and a log forwarding profile so that you can forward logs from the Prisma Access for remote networks to
Strata Logging Service
.
IPSec Tunnel Configurations
—If you have an existing template that contains IPSec tunnel, Tunnel Monitoring, and IPSec Crypto Profile configurations, you can add that template to the Remote_Network_Template_Stack to simplify the process of creating the IPSec tunnels. Or, you can edit the Remote_Network_Template that gets created automatically and create the IPSec configurations required to create the IPSec tunnel back to the corporate site. Prisma Access also provides you with a set of predefined IPSec templates for some commonly-used network devices, and a generic template for any device that is not included in the predefined templates. Be sure to following the IPSec tunnel recommendations when you configure the remote network tunnel
Configure IP Subnets for Static Routing or BGP for Dynamic Routing
—In order for Prisma Access to route traffic to your remote networks, you must provide routing information for the subnetworks that you want to secure using Prisma Access. You can do this in several ways. You can either define a static route to each subnetwork at the remote network location, or configure BGP between your service connection locations and Prisma Access, or use a combination of both methods. If you configure both static routes and enable BGP, the static routes take precedence. While it might be convenient to use static routes if you have just a few subnetworks at your remote network locations, in a large deployment with many remote networks with overlapping subnets, BGP will enable you to scale more easily.
Parent Device Group
—Prisma Access for networks requires you to specify a parent device group that will include your security policy, security profiles, and other policy objects (such as application groups and objects, and address groups), as well as authentication policy so that Prisma Access for networks can consistently enforce policy for traffic that is routed through the IPSec tunnel to Prisma Access for networks. You will need to either define policy rules and objects on Panorama or use an existing device group to secure users in the remote network location.
If you use an existing device group that references zones, make sure to add the corresponding template that defines the zones to the Remote_Network_Template_Stack. Doing so will allow you to complete the zone mapping when you Onboard and Configure Remote Networks.