Azure VM cannot traceroute to Internet destination?

SWiZ 35 Reputation points

Hi Everyone,

Just wanted to check — has anyone experienced issues with traceroute not working on Azure VMs? We've tried it on Windows, Linux, and FortiGate on Azure, but it doesn't seem to work on any of them.

Does anyone know if there's an official Microsoft documentation explaining why traceroute is disabled on Azure? And is there a way to enable it or any workaround available?

Thanks!

👁 User's image
👁 User's image

  1. Himanshu Shekhar 6,710 Reputation points • Microsoft External Staff • Moderator

    The behavior you are observing is expected by design in Azure, and traceroute is not “disabled”, but the intermediate hops do not respond, which is normal in the Azure SDN (Software Defined Network) fabric.

    From your screenshots:

    ping 8.8.8.8 works (ICMP echo replies are received)

    tracert 8.8.8.8 shows the first hop and the final destination but intermediate hops appear as * (Request timed out)

    This is the same behavior on Windows, Linux, and FortiGate VMs

    This is not a misconfiguration - it is how Azure’s networking fabric handles ICMP traffic.Traceroute relies on ICMP “TTL Exceeded” (Type 11) replies from intermediate routers.

    Azure’s underlying network is software-defined, and intermediate hops (host nodes, load balancers, SDN appliances) do not send ICMP Time Exceeded responses.

    Therefore, intermediate hops appear as *, but the packet still reaches the destination — exactly as you’re seeing (hop 11 = 8.8.8.8 reachable).

    This is also why ping works while tracert shows missing hops.

    Microsoft references -

    1. Azure ICMP behavior & traceroute limitations
    2. Azure Network Watcher – Connection Troubleshoot (recommended alternative to traceroute)
    3. Test connectivity with Azure Network Watcher
  2. Himanshu Shekhar 6,710 Reputation points • Microsoft External Staff • Moderator

    Just checking if provided response was helpful! please let me know if you have any queries.

Sign in to comment

2 answers

  1. Andrew Taylor - COREZENN 980 Reputation points • Volunteer Moderator

    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:

    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

    0 comments No comments
    Sign in to comment
  2. Sina Salam 30,166 Reputation points • Volunteer Moderator

    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.

    0 comments No comments
    Sign in to comment
Sign in to answer

Your answer