Planning Checklist for Remote Networks

• Require access to corporate resources?
  If your remote network requires access to infrastructure or resources in your HQ or a data center, create a Prisma Access service connection to the corporate site. If the remote network location is autonomous and does not need to access to infrastructure at other locations, you don’t need to do this.
• Prisma Access Locations
  When users at your branch office connect to Prisma Access, the Prisma Access location you choose determines the language in which content from the internet is served. For the best user experience, select the region and location in the same county as your branch office to ensure the best experience for your users. If a location isn't available in the same country as your branch office, choose a location that uses the same language as the majority of the users at the site.
  Few locations are marked as Local Zones. These locations provide Prisma Access compute locations close to large population and industry centers.
• IP Subnets
  For Prisma Access to route traffic to your remote networks, you’ll need to provide routing information for the subnetworks that you want Prisma Access to secure. 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 remote networks with overlapping subnets, BGP will enable you to scale more easily.
• Aggregate Bandwidth Model—Bandwidth for your remote network 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 Plan Your Migration to the New Model.
  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.
  Locations marked as Local Zones support a maximum bandwidth of 500 Mbps for remote networks. To support a bandwidth of 1 Gbps contact Palo Alto Networks support. These locations provide Prisma Access compute locations close to large population and industry centers; however, they also have some limitations. To add a local zone, reach out to your Palo Alto Networks representative.
• If you have problems accessing URLs, report the website issue to Palo Alto Networks support.
• Sizing Guidelines and Bandwidth Allocation Considerations
  When calculating the amount of bandwidth you need at a site, consider that the bandwidth usage includes both egress and ingress traffic for the remote network connection (that is, the allocated bandwidth is the sum of ingress and egress), and all locations you onboard share the allocated bandwidth for that compute location. To help you determine how much bandwidth a specific site needs, consider the bandwidth available from your ISP at each location.
• Overlapping Subnets
  Generally, you can't have any overlapping subnets within a Prisma Access instance. That is, the subnets for all remote network locations, your service connections, and your Prisma Access for mobile users IP address pools can't overlap. However, in some circumstances you can't avoid having overlapping subnets, for example, if you acquired a company that uses subnets that overlap with your existing subnets. In some cases, you might want to configure two regions with overlapping subnets by design; for example, if you want to create a separate guest network at a retail store location with different policy rules.
  Prisma Access allows you to onboard remote network locations with overlapping subnets, but only internet-bound traffic flow is supported from branches that have overlapped subnets. Branches that don't have overlapped subnets in the same tenant, receive full functionality from Prisma Access. Refer to the table in the following figure for more details.
  Keep in mind, however, that the sites with overlapping subnets have the following limitations:
  • There is no inbound remote network-to-remote network traffic. The other remote network locations wouldn’t know where route the traffic because multiple remote network locations route to the same subnets. However, users and services at any remote network location can access resources at other remote network locations provided there are no overlapping subnets at the site, and any site can access the internet through the Prisma Access infrastructure.
  • Traffic from your service connections cannot access resources at any remote network location with overlapping subnets because it wouldn’t know which remote network location to route the traffic. The remote network locations with overlapping subnets can, however, access resources from service connections.
  • Mobile users can't access resources at the remote network locations with overlapping subnets, again because of the inbound routing limitations.
  If you're managing Prisma Access using Strata Cloud Manager, go to WorkflowsPrisma Access SetupRemote NetworksAdvanced Settings. Edit the Overlapped Subnets settings to enable overlapped subnets. If you're using Panorama to manage Prisma Access, go to Panorama Cloud ServicesConfigurationRemote Networks and check Overlapped Subnets.
• IPSec Termination Nodes—You assign an IPSec termination node to the remote network during onboarding. You can specify a maximum of 500 remote network sites (for Prisma Access 5.0 and later) or 400 remote network sites (for Prisma Access releases earlier than 5.0) per IPSec termination node. Allocate more than 500 Mbps to the compute location that corresponds to the IPSec termination node to support the maximum number of allowed remote networks.
  You can have a maximum of 200 IPSec termination nodes in a compute location. 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 auto scaling mechanism that is triggered when the bandwidth consumption on the remote network requires additional capacity. See Changes to Default Behavior in the Prisma Access 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 don't 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're 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 isn't included in the predefined templates. Be sure to follow the IPSec tunnel recommendations when you configure the remote network tunnel.
• Determine Routing Method (Static or Dynamic)—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.