Route Tracing
Route tracing simulates a packet from one endpoint to another and shows exactly which subnets, route tables, NSGs, and firewalls it would cross, plus where (if anywhere) it would be dropped. It runs against the loaded snapshot, so no real traffic is sent.
Open the trace panel by clicking Trace Route in the top-right action bar of the Visualizer. Route tracing has no standalone URL, the panel is part of the Visualizer.
Route tracing is a simulation, not a guarantee
Trace results are computed from the snapshot's captured Azure configuration. They're a strong indicator, not a guaranteed match for live behavior. Treat verdicts as a starting point for investigation, not an absolute answer.
In particular, StratoLens cannot read rules from third-party network virtual appliances (NVAs), such as Palo Alto, Fortinet, or Check Point firewalls deployed as VMs. When a trace passes through an NVA, the hop is shown but its filtering decision is not evaluated, you have to confirm that path on the appliance itself.
On this page
Trace parameters
The form takes a source, a destination, a protocol, and (for most protocols) a port. Source and destination can each be a NIC from the snapshot or a raw IPv4 address, and the two modes are independent.
- Source / Destination
- By default, pick a NIC from the dropdown. Each entry reads
VM name - NIC name (IP), orNIC name (IP)when no VM is associated. Toggle Custom IP next to the field to type an IPv4 address directly instead. - Protocol
TCP,UDP,ICMP, orAny. Default isTCP.- Port
- A destination port between 1 and 65535. Required for
TCP,UDP, andAny. Hidden when the protocol isICMP.
Custom IP for non-NIC endpoints
You don't need a NIC at both ends. Custom IP lets you trace from any private or public IP, useful for verifying on-premises-to-Azure paths, or paths into a managed PaaS endpoint that isn't in the NIC list.
Running a trace
- Click Trace Route in the top-right action bar of the Visualizer to open the panel.
- Choose a source (NIC or custom IP) and a destination.
- Pick a protocol. For TCP, UDP, or Any, enter a destination port.
- Click Trace Route at the bottom of the form.
While the trace runs, the canvas dims unrelated nodes, highlights the path, and animates a packet dot traveling along it. Endpoints glow: source in blue, delivered destination in green, and the blocking node, if any, in red. The result panel shows a colored verdict banner, a one-line summary in the form source → destination (protocol[:port]), and a collapsible card for each hop. Click any hop to expand it.
Validation runs before submission
The Trace Route button stays disabled until the inputs are valid. IPv4 validation expects four octets between 0 and 255, with no leading zeros. If you enter an invalid value and submit, a red error card explains which field is wrong.
Verdict reference
Every trace ends in one of four verdicts. The verdict banner color and label tell you the outcome at a glance.
- DELIVERED (green)
- The packet would reach the destination. No NSG, route, or firewall stopped it.
- DROPPED (red)
- A rule explicitly blocked the packet. The blocking hop's reason is shown beneath the verdict and in the hop card itself. Common causes: NSG deny rule, firewall deny rule, no matching network rule on Azure Firewall (implicit deny).
- BLACKHOLED (red)
- The packet was sent to a next hop that drops traffic, typically a
Nonenext hop on a route table or a route pointing to a deleted resource. - UNKNOWN (yellow)
- The trace couldn't reach a definitive answer. Usually means the path involves something StratoLens can't evaluate from the current snapshot, for example, on-premises segments past a VPN gateway.
UNKNOWN is not a failure
UNKNOWN means the trace ran into a boundary StratoLens can't resolve from snapshot data, typically on-prem segments past a VPN gateway, or a route into a non-scanned subscription. The hop trail still shows everything up to that boundary, so you can see exactly where evaluation stopped.
Reading hop cards
Each hop is a step along the traced path, identified by a (VNet, subnet) pair plus the routing, NSG, and firewall evaluation that happens there. Hop cards start collapsed, click any one to expand it. The header reads Hop N: VNet name (subnet name) with the action taken on the right.
An expanded hop may include any of these sections, in this order:
- Subnet
- VNet name and subnet name.
- Route Match
- For user-defined routes: the route table and route name. For system routes: "System route". Plus the matched Prefix and the Next Hop (type and IP) when present.
- NSG Outbound / Inbound
- When an NSG was evaluated. Each shows an Allow or Deny badge, plus the NSG and the rule that matched.
- Firewall
- When an Azure Firewall was evaluated. Badge is Allow, Deny, or No Match (Deny). Body shows the firewall name, the matched rule, and the rule collection when present. For no-match: "No matching network rule (implicit deny)".
- Action
- What happened at this hop: Forward (continue to the next hop), or one of the terminal verdicts DELIVERED, DROPPED, or BLACKHOLED. Followed by a short reason.
Behavior & defaults
What to expect when working with traces
- A new trace replaces the previous one. Both in the panel and on the canvas overlay.
- Closing the panel clears the canvas overlay. Dimming, highlighting, and the packet dot all disappear.
- Filter changes don't disrupt an active trace. The overlay re-applies after the canvas re-renders.
- Trace and detail panel are mutually exclusive. Opening one closes the other, you can't view a node's details and a trace result side-by-side.
- Switching protocol to ICMP hides the port field, ICMP traces don't require a port.
Traces reflect the snapshot, not live Azure
The simulation runs against the network configuration captured in the loaded snapshot. To trace against the very latest Azure state, run a new scan first, then re-open the trace.
Prerequisites
What you need before tracing
- A loaded snapshot. Route trace runs against the topology from the currently selected scan. Switch snapshots in the Viewing dropdown to trace against historical state.
- Routing data in the snapshot. Route tracing depends on routing, NSG, and firewall configuration captured during the scan. If a scan ran without that data, traces may return UNKNOWN at points where Azure-evaluated routing would normally take over.
Troubleshooting
No NICs found for this scan
Answer
The snapshot has no Microsoft.Network/networkInterfaces resources, or none in the subscriptions you can see. Toggle Custom IP on either side to enter an IPv4 address directly instead.
My trace says DROPPED but my application is working
Answer
Verify that the source and destination IPs match what real traffic actually uses, private vs. public, post-NAT, or load-balancer frontend. The trace simulates what the current snapshot says, so if the snapshot predates a recent network change, run a new scan and try again.
The animated packet dot doesn't appear
Answer
The overlay only animates while a trace result is active. If you closed the panel or selected a node (which closes the panel), the overlay clears. Re-open Trace Route and run the trace again.