Plan to Deploy Remote Networks

Plan to onboard remote networks, including determining the aggregate compute regions to use in remote network bandwidth allocation.
Prisma Access for networks allows you to pick the geographic locations where you want to deploy Prisma Access to secure your remote network locations.
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:
  • Bandwidth Allocation per Compute Location
    —Plan your bandwidth for your remote networks locations 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.
    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, unless you have implemented Quality of Service (QoS) for Remote Networks.
    Before you migrate to the bandwidth allocation 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.
    You assign an
    IPSec Termination Node
    to the remote network during onboarding. Each termination node can provide you with a maximum of 500 Mbps of bandwidth. If you allocate more than 500 Mbps of bandwidth to a compute location, Prisma Access provides you with an additional IPSec termination node.
    You can specify a maximum of 250 remote networks per IPSec termination node. After you use 250 remote networks on an IPSec termination node in a compute location, you cannot onboard additional remote networks in that IPSec termination node. You can have a maximum of 200 IPSec termination nodes in a compute location.
  • 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 Cortex Data Lake.
  • 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.
  • IP Subnets
    —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.

Recommended For You