Prisma Access routing problems are often misdiagnosed because a tunnel can be healthy while the application path is broken. IPSec state proves that peers can establish a secure connection; it does not prove that Prisma Access learned the required prefix, advertised the correct return route, selected the expected next hop, or received a usable route on the far side. Effective troubleshooting separates transport, control-plane routing, policy, and return-path behavior.
The current Security Service Edge Engineer scope explicitly includes Prisma Access deployment and troubleshooting. The practical skill is to follow a destination prefix through remote networks, service connections, and connected infrastructure instead of treating “Prisma Access” as a single routing box.
Prove the tunnel before investigating the route
Start with the relevant connection type. For a branch, verify the remote-network tunnel and the local tunnel endpoint. For a headquarters or data-center path, verify the service connection. Confirm peer reachability, IKE/IPSec state, tunnel monitoring where configured, and the expected cloud location. If the tunnel is down, route analysis is premature because no forwarding path exists.
If the tunnel is up, stop changing crypto settings. A common troubleshooting failure is repeatedly rebuilding an established tunnel because traffic still does not pass. The existing VPN troubleshooting principles are useful here: separate tunnel establishment from the network services that depend on it.
Identify exactly which prefix should be learned
State the failing source and destination as concrete addresses, then map them to prefixes. Determine whether the destination should be reachable through a remote network, service connection, mobile-user infrastructure, ZTNA Connector, or the internet. Next identify who originates the route and who must learn it.
This sounds elementary, but it prevents broad statements such as “BGP is broken” when only one subnet is missing. Compare the failing prefix with a working prefix from the same site. Look for summarization differences, route filters, overlapping advertisements, stale static routes, or a recent subnet addition that was never included in Prisma Access configuration.
Understand static routes and BGP precedence
Prisma Access remote-network routing can use static routes, BGP, or a combination. Static routes are explicit and predictable, but every subnet change requires configuration maintenance. BGP scales better when sites advertise changing prefixes, but it introduces peer state, ASN, policy, and advertisement behavior that must be validated.
When both mechanisms are present, a static route can take precedence over a dynamically learned path. That means an old static entry can silently steer traffic away from the path an engineer expects BGP to select. Inspect the effective route rather than assuming the dynamic protocol “wins” because the BGP session is established. General BGP control-plane concepts remain relevant even though Prisma Access abstracts much of the infrastructure.
Check BGP in both directions
A healthy BGP session is only the beginning. Confirm the branch or data-center peer is advertising the required local prefixes and that Prisma Access accepts them. Then confirm Prisma Access is advertising the expected cloud, mobile-user, remote-network, or service-connected prefixes back to the peer. A one-way route exchange can produce asymmetric connectivity that looks like policy failure.
Review peer ASN, local and peer addresses, authentication, route-export controls, and any device-side filters. Prisma Access can be configured not to export routes in certain remote-network scenarios. If exports are disabled, on-premises equipment may need explicit static return routes. The correct troubleshooting question is therefore “what route should each side know?” rather than “is BGP green?”
Trace service-connection routing separately
Service connections are a frequent source of confusion because they can provide access to private corporate resources and also support communication between mobile users and remote networks. A user can have working internet access through Prisma Access while internal access fails because the private prefix was never learned through the service connection or the data-center network has no return path to the mobile-user pool.
Check the service-connection location, private prefixes, BGP or static routing, on-premises routing table, and internal firewalls. If traffic is source-NATed at the service connection, make sure the data center expects the translated source. If it is not translated, ensure the original mobile-user or remote-site source is routable throughout the return path.
Look for overlap and hidden asymmetry
Private address overlap is common after acquisitions, cloud migrations, and branch reuse of RFC 1918 ranges. Two remote networks advertising the same prefix create an ambiguity that cannot be solved by security policy. Likewise, an internal router may prefer a private WAN path for the return direction while the forward direction arrived through Prisma Access.
Asymmetry can break stateful enforcement and makes packet captures appear contradictory. Compare forward and reverse routing at every boundary. If the organization intentionally uses multiple paths, document the preference and failover behavior. Do not “fix” asymmetry by adding broad NAT until you understand why the paths differ.
Separate route failure from policy and DNS failure
If the route exists, verify whether security policy allows the application and whether name resolution points the client to the expected address. A routing engineer can spend hours investigating a perfectly good prefix while DNS resolves the application to an obsolete or public address. Similarly, the path may be valid while a user- or application-based rule denies the session.
Use traffic logs and policy information to prove that traffic reached the enforcement point and identify the matched rule and session outcome. Palo Alto monitoring should confirm what the platform actually enforced, not merely what the configuration was intended to do.
Use Strata Cloud Manager to correlate health and routing
Strata Cloud Manager can surface Prisma Access health and connectivity for remote networks, applications, and mobile users. Use those views to establish whether the fault is local to one site, one connection, one region, or a broader service condition. Then move to the specific remote-network or service-connection configuration and compare the active routing settings with the design.
Keep time correlation in mind. A route that disappeared at the same moment as a configuration push, BGP flap, ISP event, or branch failover gives you a much stronger hypothesis than a static snapshot. Export or capture relevant status before making changes so you can prove whether the intervention improved the path.
Use a deterministic routing checklist
A disciplined sequence is faster than random configuration changes: verify the tunnel; state the exact source and destination; identify the expected route origin; inspect the effective route; validate BGP advertisements or static entries in both directions; check overlap and NAT; prove policy; verify DNS; confirm return routing; then test failover if redundancy is part of the design.
Record the working state after recovery. Include peer addresses, ASNs, expected prefixes, route-export choices, source NAT behavior, and the devices responsible for return routing. Prisma Access routing becomes manageable when the team treats every path as an explicit contract between the cloud service and connected networks. That same documentation makes future migrations and branch additions safer because new prefixes can be compared against a known-good routing model.
When comparing route state, capture both the control-plane view and a packet-level symptom. A routing table can show the correct next hop while traffic still fails because a local edge device sends the packet into the wrong tunnel, NAT changes the source unexpectedly, or the return path follows a different interface. Use traceroute carefully because intermediate cloud hops may not always respond; the goal is to combine route evidence, session logs, and packet captures rather than rely on a single tool.
Route aggregation deserves special attention. Summaries reduce table size, but an aggregate can hide the fact that one more-specific subnet is missing or reachable through a different path. During migrations, temporary overlap between old and new advertisements can create black holes that disappear when an engineer tests only a broad summary. Compare the exact failing prefix and check whether a more-specific route changes the expected preference.
Maintenance and failover tests should include routing convergence, not just tunnel recovery. If a primary remote-network tunnel fails, measure how long the branch needs to establish the secondary path, whether BGP reconverges, and whether sessions that depend on a service connection or data-center return route recover. If the backup uses a different carrier or edge device, confirm its route filters are actually equivalent.
Build a routing baseline for every important site: expected neighbor state, advertised prefixes, learned prefixes, static routes, source-NAT behavior, and the public or private addresses used by the tunnel. When troubleshooting later, diff the current state against the baseline. This is far faster than interpreting a large routing table without knowing what “normal” should look like.
Source NAT can complicate diagnosis because the far side may never see the address the user or branch actually originated. If Prisma Access or the connected data center translates traffic, record both pre-NAT and post-NAT identities in the path. Confirm that the return route points to the translated source and that any internal firewall or allow list uses the correct address. NAT can make a route appear missing when the real mismatch is the expected source identity.
During an incident, save the routing state before clearing peers or restarting tunnels. Screenshots or exported route details can reveal a flapping prefix, unexpected next hop, or advertisement that disappears only intermittently. Once the session is reset, the strongest evidence may be gone. Troubleshooting is faster when engineers preserve the broken state long enough to compare it with the recovered one.
Do not overlook route age and churn. A prefix that appears and disappears every few minutes can create intermittent application failures that are hard to reproduce during a static check. Correlate BGP or tunnel transitions with user complaints and ISP events. Flapping routes should be treated as a stability problem even if the route is present at the moment you inspect it.