BGP Default Route, Asymmetric Return Paths and a Flapping Service Connection
Fabrikam runs Prisma Access with two service connections - Chicago and Amsterdam - each with two IPSec tunnels carrying BGP. The core advertises a summary 10.0.0.0/8 plus 172.20.0.0/16 to Prisma Access and accepts whatever Prisma Access advertises. Forty remote networks in North America and Europe break out to the internet locally. Branch users report that internal SharePoint at 172.20.12.15 loads only when they connect GlobalProtect from home, and that printing to a server in another branch times out. Separately, the Chicago core engineer began advertising 0.0.0.0/0 into the Chicago BGP sessions last week to 'simplify things.' Since then, European mobile users' SaaS traffic has been appearing in Chicago firewall logs, Amsterdam service connection utilization has dropped by roughly 60% while Chicago utilization has climbed, and Amsterdam's tunnel monitor now flaps several times a day.
1. Why does SharePoint work over GlobalProtect but not from branch users, and how would you correct the routing design?
Read the worked answer
The service connection is working - GlobalProtect users prove it. What differs is the return path for the branch source addresses.
The mechanism. The core advertises 10.0.0.0/8 into Prisma Access, so Prisma Access sends branch-bound traffic toward the core over the service connection. But the branch users' source subnets are 10.x prefixes that also exist inside the core's own 10.0.0.0/8 world, reachable over MPLS. When the SharePoint server at 172.20.12.15 replies to a branch user's 10.x address, the core follows its most preferred path - MPLS - not back through Prisma Access. The reply is dropped or arrives from an unexpected path, and the TCP handshake never completes. GlobalProtect works because the mobile user pool is a prefix the core only learns from Prisma Access, so the return path is unambiguous.
Correction. Make the return path deterministic: ensure Prisma Access advertises every remote network LAN as a specific prefix over the service connections, and make the core prefer those specific prefixes over its 10.0.0.0/8 summary (longest-prefix match usually wins, but check route-maps, admin distance, and any summarisation that suppresses the specifics). Where the branch is also reachable over MPLS, choose deliberately: either route branch-to-DC traffic symmetrically through Prisma Access, or make sure that if it goes in one path it comes back the same way. Document the choice. Then re-test with a traceroute in both directions, not just a ping.
Branch-to-branch printing failing is the same class of problem - both endpoints' prefixes must be known and reachable in both directions.
2. What is your assessment of the Chicago default route advertisement, and what would you do about the flapping Amsterdam tunnel monitor?
Read the worked answer
The default route. Advertising 0.0.0.0/0 into Prisma Access from one service connection is a deliberate design choice for organizations that want internet-bound traffic from mobile users and remote networks to be steered back to a data center for inspection or compliance logging. It is not a simplification, and it should never be done casually. Consequences visible in the data: European mobile users' SaaS sessions now enter the Prisma Access network and are forwarded to Chicago, so Chicago utilization rises, Amsterdam utilization falls, and users in Europe take a transatlantic detour with the latency and jitter that implies. It also concentrates all internet egress on one site's capacity and one site's failure domain, and it enlarges the blast radius of a Chicago outage to the entire mobile user population.
Action: confirm with the engineer what outcome was intended. If the goal was to force logging of SaaS traffic, use log forwarding and a proper decryption/logging design instead. Remove the default route, or if it is genuinely required, scope it with route filtering and document the traffic it is meant to attract. Verify that Prisma Access has not stopped using its own egress for internet destinations.
The flap. The tunnel monitor tests reachability of a configured destination through the tunnel. If monitoring traffic is now steered by the new default route - for example the monitored IP resolves or routes differently - the monitor fails and the tunnel is marked down even though IKE and IPSec are healthy. Check the monitor destination and how it is routed from Prisma Access, whether the destination is reachable from that compute location, and whether the flaps started at exactly the moment the default route was introduced. Correlate the flap timestamps in Panorama with the BGP change window before concluding the ISP is at fault.