Branch Local Breakout Not Reaching Prisma Access
A manufacturer has 30 branches connected to an SD-WAN hub in a data center. All internet-bound traffic from branches is backhauled to the data center, inspected by a PA-5220, and then sent to Prisma Access through a 1 Gbps service connection. The company now wants local internet breakout at branches while keeping Prisma SASE inspection. Each branch has a PA-450 and two ISP links. The Prisma Access service connection is in the data center; no remote network is configured at branches. A pilot branch has an SD-WAN tunnel to the data center, but when you add a policy to send Salesforce traffic directly to Prisma Access, the traffic still follows the default route to the data center. The branch-to-Prisma Access tunnel shows down in the SD-WAN monitor. Users report high latency to Salesforce. The security team will not allow unmanaged local breakout.
1. What is the likely architecture gap, and what Prisma Access and SD-WAN components must be configured?
Read the worked answer
The gap is architectural: a Prisma Access service connection connects a data center to Prisma Access; it does not provide a branch SD-WAN tunnel endpoint. With no remote network at the branch, there is nothing for the branch PA-450 to terminate to, so the tunnel shows down and the default route to the data center wins.
Configure a Prisma Access remote network for the branch, or use the supported Prisma SD-WAN integration if that is the deployed model. Include the IPsec/IKE parameters, the branch tunnel endpoint, and BGP if routes are exchanged. On the branch, create an SD-WAN tunnel to the remote-network endpoint and place an SD-WAN policy above the default/corporate rule for Salesforce and other direct-internet applications. On Prisma Access, attach security policy, decryption, and the correct security processing node so inspection is not bypassed.
Sequence the work: remote network, tunnel/BGP, Prisma Access security policy, branch SD-WAN policy, then testing. Do not enable local breakout until the inspection path is proven.
2. How would you sequence the configuration and policy so that security inspection is not bypassed?
Read the worked answer
Build the inspection path first and prove it before moving production traffic:
- Create the Prisma Access remote network and its IPsec/IKE settings.
- Configure the branch SD-WAN tunnel to the remote-network endpoint and bring up BGP if required.
- In Prisma Access, attach the correct security policy, decryption profile, and security processing node to the remote-network traffic.
- Add a branch SD-WAN policy for Salesforce and other approved SaaS above the data-center default route.
- Test with a non-production client and verify that traffic traverses Prisma Access, is inspected, and returns symmetrically.
Do not create a local internet breakout policy that bypasses Prisma Access. If the business requires local breakout, use the Prisma SASE inspection path as the only allowed exit.
3. What would you check if the tunnel is up but Salesforce still goes to the data center?
Read the worked answer
Check, in order:
- SD-WAN policy order and hit counters: a higher rule may still match Salesforce and send it to the data-center tunnel.
- Routing: the branch may have a more specific route to Salesforce through the data center, or BGP may not be advertising the remote-network path with sufficient preference.
- Policy-based forwarding conflicts: an existing PBF rule or default route may override the SD-WAN decision.
- NAT and return path: source NAT or asymmetric return traffic can make the Prisma Access path fail even when the tunnel is up.
- Prisma Access policy: security policy may be dropping or redirecting the flow, causing the branch to fall back.
Validate with show routing route, SD-WAN policy match counters, session details, and a traceroute from the branch to Salesforce.