greg jorgensen(Panorama Managed)
Routing Considerations
When SCs, RNs, and MUs are onboarded into Prisma Access, it automatically builds a meshed cloud infrastructure across all service connections and nodes. SWGs are not part of this routing mesh.
Prisma Access uses dynamic routing to determine the best route and forwards the traffic to the destination remote network security processing node (RN-SPN).
Remote Networks are meshed with each other and all Service Connections (SC-CANs).
Remote networks can connect directly to any SC-CAN in any region to access a service connection within a Prisma Access tenant.
Remote networks can connect directly to the internet.
To route mobile users to remote networks, traffic is forwarded to the SC-CAN to determine the best route to the RN-SPN.
Therefore, if you will deploy both mobile users and remote networks and need to allow mobile users to connect to data centres or remote networks, one or more service connections must be onboarded.
Mobile user traffic can also transit an SC-CAN to a service connection.
MU-SPN traffic will always transit the geographically closest SC-CAN. The MU-SPN may then continue on to that service connection or may go to another service connection.
Mobile user traffic can go through the security enforcement of the MU-SPN and continue on to the internet.
In larger Prisma Access deployments that use multiple locations, traffic is routed through the nearest SC-CAN.
As shown below ⬇️, when mobile users in the Europe region need to connect to the branch office in the Europe region, traffic is routed through the SC-CAN in the North America region.
To reduce latency, onboard another SC-CAN.
It is important to remember that service connections corporate access nodes (SC-CANs) within Prisma Access cannot connect directly to the internet.
Both remote networks and mobile users (with either GlobalProtect or explicit proxy) can both connect directly to the internet.
Proxy connections cannot connect to other resources on Prisma
Infrastructure Subnets
- This must be configured before use
- This is used to establish a backbone between remote network locations and mobile users.
- Extension of existing network* so cannot overlap any existing IP subnets
- /23 is recommended but more than 100 sites or 5k mobile users should be a /22
- Example below:
Service Connections Versus Remote Networks
SC-CAN:
Service connection corporate access node is created when you onboard a service connection.
Service Connections are great for sites with on-premise firewalls
The actual technical requirement is that it be an IPsec-compliant device.
User-ID redistribution and routing (MU-SPNs and portals route through their geographically closest SC-CAN)
SC-CANs have higher throughput than RN-SPNs. The throughput exceeds 1Gb. Five service connections can be made to the same customer site facilitating up to 5Gbps and cloud service provider redundancy.
SC-CANs do not provide security enforcement or log sessions, so it is important to consider whether there is an on-premises firewall in place to address security concerns.
A session cannot be initiated through an SC-CAN to the internet.
RN-SPN:
Remote Network Security Processing Nodes is a security enforcement point that incorporates the advanced security features of a NGFW.
RN-SPNs are metered so during onboarding you should set the maximum symmetric bandwidth that the compute location will support. Bandwidth is allocated from a pool of purchased bandwidth.
A new RN-SPN is created for every 1Gbps
A single tunnel can support up to 1,000Mbps throughput with all security features enabled.
When do to a SC-CAN Vs. RN-SPN ?
The SC-CAN supports greater, unmetered throughput, but there is no Security policy enforcement.
The RN-SPN provides the advanced features that are common to Palo Alto Networks products but is metered and has a maximum guaranteed throughput of 1,000Mbps per tunnel.
A single site can have more than one tunnel.
You might want to use a SC-CAN for connecting a data centre (with a firewall capable of IPsec tunnels) to Prisma Access. The connection, in this case, is between the on-premise firewall and the Service Connection Corporate Access Node
You might want to use an RN-SPN if you need a connection from a branch office to Prisma Access cloud or to secure internet connectivity.
You might have a site (on-prem or cloud) that does not have an existing firewall.
You need something to enforce a security policy
You require inbound access from the internet through Prisma Access to a site
You have a cloud-only or cloud-first tech stack
Representation of traffic flow for which the destination is a resource connected to the Prisma Access Cloud
Branch Offices (1) → Security Processing Nodes (2) → Prisma Access Cloud (3) → Service Connection - Corporate Access Nodes (4) → On-premises Network Infrastructure (5)
OR
Branch Offices (1) → On-premises Next-Generation Firewall (2) → Service Connection - Corporate Access Nodes (3) → Prisma Access Cloud (4) → On-premises Network Infrastructure (5)
OR
Remote Users (1) → Mobile User - Security Processing Nodes (2) → Prisma Access Cloud (3) → Service Connection - Corporate Access Nodes (4) → On-premises Network Infrastructure (5)
There are more steps if the environment is more complex.
Internet-Bound:
Remote Users (1) → Mobile User - Security Processing Nodes (2) → Internet
OR
Branch Offices (1) → On-premises Next-Generation Firewall (2) → Internet
OR
Branch Offices (1) → Security Processing Nodes (2) → Internet
BUT NOT
Remote Users/Branch Offices (1) → Service Connection - Corporate Access Node → Internet
Prepare to Connect Remote Networks to Prisma Access
Need to know:
- Documentation - the number of remote networks and the required bandwidth for each
- Routing Requirements
- Security Policy - determine policy rule requirements
Remote network bandwidth is allocated in increments of more than 50Mbps on a per-Mbps basis for each compute location. This is pooled and shared at a single COMPUTE LOCATION
(Compute location is a general POP area like US-West-2 for example)
How to allocate bandwidth:
Each RN-SPN gets one service infrastructure address and one public IP address.
Any non utilised bandwidth can be shared for all other branch offices in that compute location to use.
Example: There are two SPNs in a compute location sharing 2 Gbps, site A can use 1800 Mbps and site B can use 200Mbps or they can split 1Gbps evenly, it comes to the same.
There is a built-in option to migrate from allocating bandwidth per onboarded remote network to per-compute-location aggregated bandwidth allocation. *after upgrading to plugin 2.1.0 or later
High Availability Tunnels
The active and passive tunnels terminate to the same Prisma Access IP address.
The backup tunnel is used only when Prisma Access detects that the primary tunnel is down.
Second tunnel is available within 15 seconds.
Active/active tunnels can also be configured, they can be used for load sharing for greater throughput or for redundancy.
In the case of active/active, routing should be handled on the on-premises side so that there is no asymmetric traffic path.