Plan the Service Infrastructure and Service Connections
Focus
Focus

Plan the Service Infrastructure and Service Connections

Table of Contents

Plan the Service Infrastructure and Service Connections

Plan the Service Infrastructure

To Enable the Service Infrastructure in the cloud for your remote network locations and mobile users, you must provide a subnet that Prisma Access uses to establish a network infrastructure between your remote network locations, mobile users, and service connections to your headquarters/data center (if applicable). The IP addresses in this subnet also enable Prisma Access to determine the service routes for services such as LDAP, DNS, or SCEP, as well as enable other inter-service communication. Because a large number of IP addresses will be required to set up the infrastructure, you must use a /24 subnet (for example, 172.16.55.0/24) at a minimum. This subnetwork will be an extension to your existing network or with the IP address pools you assign for Prisma Access for users. If you have a large number of mobile users, branch offices, or both, provide a larger infrastructure subnet.
Use the following recommendations and requirements when adding an infrastructure subnet:
  • You can assign Prisma Access an infrastructure subnet from a existing supernet in your organization’s IP address pool, but do not assign any of the IP addresses from the infrastructure subnet for any other use in your existing network.
    The following example shows a Prisma Access infrastructure subnet, 10.10.1.0/24, that you assigned from an existing supernet, 10.0.0.0/8. After you assign 10.10.1.0/24 as the infrastructure subnet, your organization cannot use any IP addresses from that subnet. For example, you can assign 10.10.2.1 to an endpoint, but 10.10.1.1 is not allowed because that IP address is part of the infrastructure subnet.
  • If you create a new subnet for the infrastructure subnet, use a subnet that does not overlap with other IP addresses you use internally.
  • We recommend using an RFC 1918-compliant subnet. While the use of non-RFC 1918-compliant (public) IP addresses is supported, we do not recommend it, because of possible conflicts with internet public IP address space.
  • Do not specify any subnets that overlap with the following IP addresses and subnets, because Prisma Access reserves those IP addresses and subnets for its internal use.:
    • 169.254.169.253 and 169.254.169.254
    • 100.64.0.0/10
    • 169.254.201.0/24
    • 169.254.202.0/24
  • The subnet cannot overlap with the IP address pools you plan to use for the address pools you assign for your mobile users deployment.
  • Because the service infrastructure can be very large, you must designate a /24 subnet at a minimum.

Service Connection Overview

We recommend always creating a service connection, because it allows Prisma Access to perform the following tasks:
  • A service connection allows access to the resources in your HQ or data center.
    For example, if your security policy requires user authentication using an on-premises authentication service, such as your Active Directory, you will need to enable Prisma Access to access the corporate location where the service resides (and set up a service account that the service can use to access it). Similarly, if you have corporate resources that your remote networks and mobile users will need to access, you must enable Prisma Access to access the corresponding corporate network.
    If you create service connections for this reason, you should plan for the service connections before implementing them.
  • A service connection allows remote networks and mobile users to communicate with each other.
    Even if you don’t need access to your HQ or data center, you might have a need to allow your mobile users to access your remote network locations. In this case, you can create a service connection with placeholder values. This is required because, while all remote network connections are fully meshed, mobile users connect to remote networks using the service connection in a hub-and-spoke network. For this reason, you might also create a service connection with placeholder values if your existing service connection is not in an ideal geographical location.
The number of service connections you receive depends on your Prisma Access license.
  • If you have a ZTNA or Enterprise license, you receive two service connections if you have a Local edition license and five service connections if you have a Worldwide edition license.
  • If you manage multiple tenants and have a ZTNA or Enterprise license, the number of service connections per tenant depends on the number of units you allocate per tenant and the type of license you have.
    • If you have a Global license and allocate at least 1,000 units for a tenant, you can allocate a maximum of five service connections for that tenant.
    • If you have a Global license and allocate between 200 and 999 units for a tenant, you can allocate a maximum of two service connections for that tenant (the same as the number of connections for a Local deployment).
    • If you have a Local license, you can allocate a maximum of two service connections per tenant, regardless of the number of units you allocate past the minimum of 200.
    For both Global and Local licenses, you can purchase additional licenses for service connections if more are required.
    See Multitenancy Configuration Overview for more information about allocating units for tenants and how units correspond to bandwidth (for remote network deployments) or mobile users (for mobile user deployments).
While each service connection provides approximately 1 Gbps of throughput, the actual throughput is dependent on several factors, including:
  • Traffic mix (for example, frame size)
  • Latency and packet loss between the service connection and the headquarters location or data center
  • Service provider performance limits
  • Customer termination device performance limits
  • Other customer data center traffic
In order for Prisma Access to route users to the resources they need, you must provide the routes to the resources. You can do this in one or more of the following ways:
  • Define a static route to each subnetwork or specific resource that you want your users to be able to access.
  • Configure BGP between your service connection locations and Prisma Access.
  • Use a combination of both methods.
    If you configure both static routes and enable BGP, the static routes will take precedence. While it might be convenient to use static routes if you have just a few subnetworks or resources you want to allow access to, in a large data center/HQ environment where you have routes that change dynamically, BGP will enable you to scale easier. Dynamic routing also provides redundancy for your service connections. If one service connection tunnel is down, BGP can dynamically route mobile user and remote network traffic over the operational service connection tunnel.

Plan the Service Connections

If you use the service connection to access information from your headquarters or data center, gather the following information for each of your HQ/data center sites that you want the cloud service to be able to connect to:
If you are creating a service connection to allow mobile users access to remote network locations, you do not need this information.
  • IPSec-capable firewall, router, or SD-WAN device connection.
  • IPSec settings for terminating the primary VPN tunnel from Prisma Access to the IPSec-capable device on your corporate network.
  • IPSec settings for terminating the secondary VPN tunnel from Prisma Access to the IPSec-capable device on your corporate network.
    If you have an existing template that contains IPSec tunnel, Tunnel Monitoring, and IPSec Crypto Profile configurations, you can add that template to the template stack to simplify the process of creating the IPSec tunnels. Or, you can edit the Service_Conn_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 is not included in the predefined templates.
  • List of IP subnetworks at the site.
  • List of internal domains that the cloud service will need to be able to resolve.
  • IP address of a node at your network’s site to which Prisma Access can send ICMP ping requests for IPSec tunnel monitoring.
    Make sure that this address is reachable by ICMP from the entire Prisma Access infrastructure subnet.
  • Service account for your authentication service, if required for access.
  • Network reachability settings for the service infrastructure subnet.
    We recommend that you make the entire service infrastructure subnet reachable from the HQ or Data Center site. Prisma Access uses IP addresses for all control plane traffic, including tunnel monitoring, LDAP, User-ID, and so on from this subnet.
Traffic over the service connections does not count towards the remote network bandwidth pool that you purchased.