Planning Checklist for Remote Networks
Focus
Focus
Prisma Access

Planning Checklist for Remote Networks

Table of Contents

Planning Checklist for Remote Networks

Use this checklist to plan for your
Prisma Access
remote network deployment.
Where Can I Use This?
What Do I Need?
  • Prisma Access (Cloud Management)
  • Prisma Access (Panorama Managed)
  • Prisma Access
    License
Before you begin to onboard remote networks, make sure you have the following configuration items ready to ensure that you will be able to successfully enable the service and enforce policy for users in your remote network locations:
  • 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. Local zones don't support remote network and service connection node redundancy across availability zones, as both nodes are provisioned in a single zone. These local zones don't use Palo Alto Networks registered IP addresses, and use cloud provider registered IP addresses. 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
    Workflows
    Prisma Access Setup
    Remote Networks
    Advanced Settings
    . Edit the
    Overlapped Subnets
    settings to enable 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 Cortex Data Lake.
  • 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.

Recommended For You