Short answer: PAN-OS has no mtr command. You can run traceroute and ping from the firewall CLI, but neither shows packet loss per hop over time. For that, run MTR from another machine, or use a free online MTR such as the HardcoreDebug MTR tool, to test the path to your firewall, GlobalProtect portal or Prisma Access location from the internet.
Traceroute and ping from the PAN-OS CLI
The most common mistake is forgetting the source address. Without it, probes leave from the management interface, which often uses a different route from your users' traffic.
> traceroute source 10.10.10.1 host 8.8.8.8
> ping source 10.10.10.1 count 100 host 8.8.8.8sourcemust be an IP configured on a dataplane interface (for example, the inside or untrust interface).- A
countof 100 pings gives a meaningful loss percentage to one hop. Repeat it for the hop where traceroute latency jumps. - If traceroute stops at the firewall, check that the interface's management profile allows ping. Traceroute replies depend on ICMP.
Build an MTR-style view from the firewall
- Run
traceroute source <dataplane-ip> host <target>and note each hop IP. - Ping the destination with
count 100. If loss is 0%, the path is healthy, whatever the middle hops show. - If the destination shows loss, ping the hops before it, one by one, to find where loss starts and continues.
Test GlobalProtect and Prisma Access from outside
When remote users report a slow or dropping VPN, the problem is often between their ISP and your portal or Prisma Access location, which the firewall can't see. Run an MTR from the internet instead:
- TCP 443 to the portal or gateway FQDN: the path for the SSL fallback and the portal login.
- UDP 4501: the path for the GlobalProtect IPsec tunnel.
- ICMP for a quick baseline. If ICMP stops at your edge, that's expected when ping is blocked there.
Compare the outside-in result with an MTR or pathping from an affected user's laptop (see MTR on Windows, Linux and macOS). Where both paths show loss continuing to the end, you have found the problem segment.
How to read the results
| What you see | What it usually means |
|---|---|
| Loss at one middle hop, 0% at the destination | ICMP rate limiting on that router. Not a real problem. |
| Loss starting at hop N and continuing to the end | Real loss at or just before hop N. |
| Latency jump that stays high to the end | Congestion or a long-distance link at that hop. |
| Path stops at your firewall's public IP | ICMP blocked by the management profile or policy. Try TCP 443. |
Frequently asked questions
Is there an mtr command on Palo Alto firewalls?
No. PAN-OS has traceroute and ping but no mtr. To get packet loss per hop, combine a traceroute with repeated pings from the firewall, or run an MTR from outside (for example with the HardcoreDebug online MTR) towards your firewall, GlobalProtect portal or Prisma Access location.
Why does traceroute from the firewall not follow my data traffic?
By default PAN-OS sends ping and traceroute from the management interface. Add source with the IP of a dataplane interface so the probes leave through the same interface and virtual router as user traffic.
How do I test the path to a GlobalProtect portal or gateway?
Run a TCP MTR on port 443 to the portal or gateway FQDN. GlobalProtect also uses UDP 4501 for its IPsec tunnel, so a UDP test helps when users fall back to SSL or see slow tunnels.
Is packet loss on a middle hop a problem?
Usually not. Routers often rate-limit replies to traceroute probes. Loss only matters when it starts at a hop and continues all the way to the destination.