Azure VM cannot traceroute to Internet destination?

Hi @SWiZ

Thank you for reaching out to Microsoft Q&A. I understand you are attempting to use tracert on a Azure VM.

There is no Azure-wide switch that simply turns on tracert for every VM. In Azure, tracert is typically limited by ICMP behavior on the path in use, and Microsoft documents two important constraints:

• Default outbound access IPs do not support ICMP pings, which is the same ICMP mechanism tracert relies on: https://learn.microsoft.com/azure/virtual-network/ip-services/default-outbound-access
• Azure Load Balancer outbound rules do not support ICMP for outbound NAT; they support TCP and UDP only: https://learn.microsoft.com/azure/load-balancer/outbound-rules#limitations

So, if traceroute appears to fail, the first thing to verify is whether your VM is using a path that permits ICMP and whether the relevant NSG rule allows it. If ICMP is not viable in your design, use Azure Network Watcher connection troubleshoot or TCP/UDP-based connectivity tests instead: https://learn.microsoft.com/azure/network-watcher/connection-troubleshoot-overview

Please Upvote (Thumbs-up) and Accept as answer if the response was helpful. This will be help other community members find relevant help as well.

Best regards, Andrew S Taylor

Hello SWiZ,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure VM cannot traceroute to Internet destination.

Regarding your question. YES! Azure VM traceroute is unsupported and unreliable for Internet destination LIKE on-premises.

Internet traceroute from Azure VMs is not a reliable or supported way to diagnose Internet path hops. There is no Azure switch to enable full Internet traceroute for Windows, Linux, or FortiGate VMs. The behavior you experienced is expected because Azure outbound methods and Internet intermediate devices do not guarantee ICMP/TTL-expired responses, and some Azure outbound mechanisms do not support ICMP at all. NAT Gateway supports TCP/UDP only and does not support ICMP; default outbound access also does not support ICMP pings.

Therefore, use Network Watcher Connection Troubleshoot, Next Hop, NSG diagnostics/IP Flow Verify, packet capture, and TCP port tests against the real application port. If real TCP/UDP traffic succeeds, traceroute failure alone is not a network outage. So, change the diagnostic method, not by enabling traceroute.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.