Cloud Tracer
Focus
Focus
Prisma AIRS

Cloud Tracer

Table of Contents


Cloud Tracer

Use Cloud Tracer to diagnose multi-cloud network connectivity and security policy issues with real-time, hop-by-hop path visibility.
Where Can I Use This?What Do I Need?
  • Prisma AIRS AI Runtime Security
Cloud Tracer gives network security and cloud administrators real-time visibility into how traffic moves within a single cloud, across regions, or spanning multiple clouds. Trace the exact hop-by-hop path between any two endpoints with detailed visualizations directly in the Strata Cloud Manager (SCM) UI. Instantly spot where connectivity breaks—whether it is a misconfigured route, a firewall drop, or a security policy violation.
With the July R7 release, Cloud Tracer expands significantly beyond the initial AWS-only beta. It now supports:
  • Azure and cross-cloud AWS-to-Azure tracing
  • Full inline Palo Alto Networks firewall policy evaluation at the firewall hop
  • Broader security policy coverage including security groups, network access control lists (NACLs), and network security groups (NSGs) evaluated at every applicable hop along the path
Cloud Tracer always shows the full end-to-end path as long as a route exists. Even if a security policy denies traffic at a hop, the trace continues to show every hop that would have been traversed. The hop where traffic was denied is clearly marked with a drop indicator and the specific reason—whether it is a firewall policy name, a NACL rule number, or an NSG rule—so you know not just that traffic was blocked, but exactly where and why.
  1. Navigate to InsightsCloud Network SecurityCloud Tracer.
    What you see depends on whether any traces have been run before on this tenant:
    • If no traces have been run, you land on a zero-state page with a prompt to get started.
    • If traces have been run before, you land directly on the Trace History page.
  2. Start a new trace.
    There are two ways to start a new trace:
    • Click Run New Trace in the top right of the Trace History page.
    • From within an existing trace result, click Show Parameters, update the fields as needed, and click Run Trace.
  3. Fill in the trace parameters and click Run Trace.
    Provide the following information:
    • Trace Name
    • Source details: cloud provider, region, VPC/VNet, subnet, and IP address
    • Destination details: cloud provider, region, VPC/VNet, subnet, and IP address
    • Protocol and ports
    The trace is submitted and runs in the background. You can close the window and return to Trace History at any time to check the result.
  4. Review the trace result.
    When you open a trace result, the summary at the top shows the overall status, how many paths were traced, and how long it took. The main view is a hop-by-hop visual diagram.
    Click any hop to open its details panel. Each hop includes a transition description—a plain-English explanation of exactly how the packet traversed that hop, including which interface was selected, which IP was used, which subnet it was forwarded to, and the matched rule that drove the decision.
    You will often see multiple paths in a trace. This reflects the inherent redundancy of real cloud topologies—traffic can flow through multiple availability zones, multiple firewall instances behind a load balancer, or multiple ECMP routes in a transit gateway. Cloud Tracer traces all of these simultaneously so you see the complete picture.
  5. Manage traces from the Trace History page.
    The Trace History page shows all previously run traces. For each trace, you can see the trace name, run status, source and destination region, IPs, cloud provider, ports, and the last run timestamp.
    • Filter traces by typing in the filter box—it searches across all fields.
    • Click a trace name to open the results of its last run.
    • From within a trace result, click Show Parameters to reveal the inputs used, then re-run with the same parameters or modify any field and click Run Trace.
    • Delete a trace from this page.

Understand Cloud Tracer Results

Cloud Tracer results reflect the real-world complexity of cloud network topologies. The following scenarios illustrate how to interpret common trace outcomes.
Cross-cloud trace (AWS to Azure) — Success
A trace from an AWS VM to an Azure VM shows the full cross-cloud path: source VM exits through its subnet, through the transit gateway into the AWS security VPC, through the gateway load balancer to the AWS-side Palo Alto Networks firewall, through a VPN tunnel into Azure, through the Azure-side firewall, through the security VNet load balancer, and via VNet peering to the destination Azure VM. All paths show a success status with per-hop transition descriptions at every step.
AWS intra-region trace — Partial success
A trace between two VPCs in the same AWS region may show a partially successful status when some paths succeed and others fail. For example, if two of four paths fail because the firewall instance they were routed to was unhealthy, the trace stops at the gateway load balancer for those paths. AWS does not forward traffic to unhealthy targets, so the trace immediately identifies that a firewall instance behind the load balancer is down and needs attention.
Azure intra-region trace — Firewall policy denial
When a Palo Alto Networks firewall deny policy blocks traffic, the trace marks the firewall hop with a drop indicator showing the specific policy name. Importantly, the trace continues to show the full path beyond the firewall. This can reveal that the destination VM's NSG would have blocked the traffic independently—surfacing two layers of enforcement in a single view.
Azure cross-region trace — NSG denial at destination
When the firewall allows traffic but an NSG at the destination denies it, the trace shows a clean path through the firewall and marks the denial at the destination VM's NSG. Without Cloud Tracer, an administrator would typically check the firewall logs first, find nothing wrong, and spend time investigating the wrong component before discovering the NSG was the actual problem.
AWS intra-region trace — Missing route
When no route exists for the destination, Cloud Tracer evaluates the transit gateway route table, finds no matching route, and stops the trace at that point. The result identifies exactly which route table was checked and that no matching route existed—giving you the precise information needed to fix the routing configuration.