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.