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.
- Bandwidth Types—Remote networks use one of the following bandwidth models:
- Site-Based Bandwidth Model—For new deployments starting with Prisma Access 6.0, you onboard a site by specifying the location and the site
type. You select predefined bandwidth capacities for each site.
By moving away from aggregate bandwidth-based licensing, you can more easily
estimate and allocate resources for your remote locations.
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.
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.
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.
Reporting URL Access Issues—If you have problems
accessing URLs, report the website issue to Palo Alto Networks support.
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 . Edit the Overlapped Subnets settings to
enable overlapped subnets. If you're using Panorama to manage Prisma Access,
go to 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.
