Prisma Access Connectivity and Routing
Two hops, not one
Every flow has an ingress and an egress. A branch tunnel terminates at a nearby compute location; from there traffic goes to the internet locally, back through a service connection to a data center, or onward for a private application. Mobile users terminate at the nearest mobile user location and are then routed to a compute location when they need private apps. Latency complaints are usually an ingress-versus-egress question, not a firewall question.
Tunnelling and route exchange
IPSec with IKEv2 and a pre-shared key or certificate. BGP runs over the tunnel with eBGP multihop and a customer-side private ASN. Prisma Access advertises your internal prefixes into the tunnel; your CPE advertises branch prefixes back. Static routes are supported but do not fail over, so treat them as a lab shortcut.
Hot potato routing
Prisma Access hands traffic off as early as it can. If the data center advertises a default route into its service connection, all branch internet traffic is pulled back on-premises - the opposite of the intended design, and a frequent cause of "branch internet got slower after migration".
Worked example
A branch tunnel is up and the IPSec SA is established, but users cannot reach 10.20.0.0/16. Walk the hops: does a service connection exist to that data center; is 10.20.0.0/16 advertised by the data center CPE and accepted by Prisma Access; is it redistributed onto the remote network tunnel; does the branch CPE have a matching route? A missing advertisement at any single hop looks identical to the user - "the VPN is up but nothing works".
Traps
- Advertising 0.0.0.0/0 from the data center and hairpinning all branch internet traffic.
- Ignoring MTU: IPSec overhead fragments large packets, so test with the DF bit set.
- Assuming QoS is end-to-end; QoS profiles apply to remote network and service connection links.