Plan Your Remote Network Deployment (Cloud Management)

Before you configure Prisma Access for networks, plan your deployment to ensure that you enable Prisma Access and enforce policies successfully.
Here’s what to consider or gather before onboarding a remote network to Prisma Access:
  • Does the remote network 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 doesn’t need to access to infrastructure at other locations, you don’t need to do this.
  • Choose the Right Prisma Access Locations
    When users at your branch office connect to Prisma Access, the Prisma Access location you chooses 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 is not 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.
  • Have IP Subnets Ready
    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.
  • How to Allocate Bandwidth for Remote Networks
    At least two (often more) Prisma Access locations that are geographically near each other are grouped in to compute locations. This is the level at which you allocate bandwidth, instead of allocating bandwidth for individual Prisma Access locations or for specific remote network sites.
    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.
    Still Consider How Much Bandwidth Each Site Needs, When You Allocate Bandwidth Based on Location
    To help you determine how much bandwidth a specific site needs, consider the bandwidth available from your ISP at each location. 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.
    Secure inbound access for remote network sites and Quality of Service (QoS) for remote networks is not supported when you allocate bandwidth across locations.
  • IPSec Termination Nodes
    IPSec termination nodes allow you to associate remote networks with compute locations. When you onboard a remote network, select an IPSec termination node for the remote network that correlates to the compute location.
    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.
  • Overlapping Subnets
    As a general rule, you cannot 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 cannot overlap. However, in some circumstances you cannot 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 does allow you to onboard remote network locations with overlapping subnets, as long as the remote networks are in different regions. 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 would not 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 can not access resources at any remote network location with overlapping subnets because it would not 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 cannot access resources at the remote network locations with overlapping subnets, again because of the inbound routing limitations.

Recommended For You