Unexpected Private IP Appearing in Traceroute Despite Next Hop Being Netskope/Virtual Network Gateway

Question

Hello Team,

• We are observing an unexpected private IP in the traceroute output from an Azure VM, even though Azure routing diagnostics confirm that traffic is routed via a Virtual Network Gateway. Scenario (sanitized):
  • VM private IP: 10.20.30.10
  • VNet CIDR: 10.20.0.0/16
  • Hub‑and‑spoke VNet with peering
  • Forced tunneling to internet via VPN Gateway
  • No NVAs or Azure Firewall in the spoke subnet
  • We've routed VM's traffic to route to Netskope directly- IP 192.0.2.10
  Traceroute output (sanitized): 1  VM (0.0.0.0) 2  10.100.50.25   ← unexpected private IP 3  *  *  * 4  192.0.2.10 -->Netskope IP 5  Public destination The IP 10.100.50.25:
  • Is not present in UDRs, BGP propagated routes, VNet peers, or NVAs
  • Responds to ICMP ping from the VM
  Network Watcher → Next Hop from VM:
  • Destination: 8.8.8.8
  • Result: Next hop = VirtualNetworkGateway
  Questions:
  1. Is it expected for Azure platform / SDN internal IPs to appear as intermediate hops in tracert, even when the effective next hop is a Virtual Network Gateway?
  2. Can such IPs represent Azure internal forwarding infrastructure that is not visible via route tables or BGP?
  3. Should Network Watcher Next Hop / Effective Routes be considered authoritative over traceroute output for Azure routing validation?
  Looking for confirmation whether this is expected Azure platform behavior. Thank you.

Answer 1

Hi Shubhangi Nannware,

Thanks for reaching out in Microsoft Q&A forum,

Is it expected for Azure platform / SDN internal IPs to appear as intermediate hops in tracert, even when the effective next hop is a Virtual Network Gateway? Can such IPs represent Azure internal forwarding infrastructure that is not visible via route tables or BGP? Should Network Watcher Next Hop / Effective Routes be considered authoritative over traceroute output for Azure routing validation?

Yes, what we’re observing is expected Azure platform behavior, and there’s no routing misconfiguration here.

It’s completely normal in Azure for private, undocumented IP addresses to show up in tracert/traceroute output, even when Network Watcher confirms the next hop is a Virtual Network Gateway, no NVAs or Azure Firewall exist in the path, and the IP doesn’t appear in UDRs, BGP-propagated routes, or peering configurations. These addresses belong to Azure’s internal Software-Defined Networking (SDN) forwarding infrastructure — the hidden fabric that moves packets between your VM and the logical next hop.

• From a logical perspective, our traffic flow is straightforward: VM > Virtual Network Gateway > Netskope > Internet. However, traceroute exposes the physical/SDN forwarding path, which includes Azure’s internal hops: VM > Host vSwitch > Azure SDN fabric router (10.100.50.25) >Gateway stamp > VPN tunnel > Netskope > Internet.
• The IP 10.100.50.25 is almost certainly an Azure host-level virtual switch, SDN dataplane router, or Virtual Filtering Platform (VFP) hop. These components exist outside customer visibility and control, are not advertised in route tables, BGP, or peering configs, may respond to ICMP (ping/TTL-exceeded) because they process packets in the data plane, and can change dynamically during VM migrations or host updates.
• Azure Network Watcher’s Next Hop and Effective Routes tools evaluate the control-plane routing truth your configured system routes, UDRs, and BGP propagations. They tell you where Azure intends to send the traffic, not every internal hop the packet touches along the way.
• In contrast, traceroute shows every device that decrements TTL, including Azure’s transient SDN fabric nodes. In Azure’s overlay networking model, logical routing ≠ physical forwarding path, so traceroute can be misleading if used as the primary routing validation tool. For routing validation in Azure, Network Watcher Next Hop and Effective Routes are authoritative, NSG Flow Logs are valid for traffic inspection, while tracert/traceroute should be treated as informational only since it exposes SDN fabric hops.
• We’ve confirmed that the unknown private IP (10.100.50.25) appears in traceroute, responds to ICMP ping from the VM, is absent from all route tables, BGP tables, and peering configs, traffic successfully exits via VPN Gateway to Netskope, and no NVA or firewall is involved. All of these observations are consistent with normal Azure SDN behavior. This isn’t a bug or misrouting it’s simply visibility into Azure’s hidden forwarding fabric.

Continue to trust Network Watcher Next Hop / Effective Routes as the source of truth for routing validation. Treat intermediate private IPs in traceroute as Azure platform infrastructure unless they match your own managed NVA/firewall addresses. No further action is needed unless you observe actual traffic drops, latency spikes, or asymmetric routing issues.

References:

• Diagnose an Azure virtual machine routing problem | Microsoft Learn
• Interoperability in Azure - Data plane analysis | Microsoft Learn
• Tutorial: Diagnose a VM Network Routing Problem - Azure Portal - Azure Network Watcher | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Hi Shubhangi Nannware

Thanks for reaching out on Microsoft Q&A!

Your configuration is behaving correctly as the private IP hop is expected Azure platform behaviour. Traceroute is unreliable in Azure routing as it was designed for physical routers. It does not understand virtualized forwarding, load-balanced dataplanes, asymmetric paths and managed gateways. The Azure documentation states that "traceroute is not a supported validation tool for Azure routing correctness".

Traceroute is still helpful to:

Confirm egress visibility

Validate destination reachability

Observe tunnel exit point order

Detect hard drops vs forwarding

But not to validate Azure routing constructs, ufortunately.

For more information on how to be able to alternatively check your routes, please refer to:

https://learn.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem

Please click ‘Accept answer’ if you think my answer is helpful. Feel free to drop additional queries in the comments below!

Kind regards,

Sonny

Answer 3

1. Yes. It is expected that intermediate private IPs that are not present in user-visible route tables can appear in traceroute, even when Network Watcher shows the next hop as VirtualNetworkGateway. Azure routing is determined by the control-plane routes (system, BGP, and custom/UDR), but the data plane can traverse internal forwarding points that are not exposed in effective routes.
2. Yes. Such IPs can represent Azure internal forwarding infrastructure that is not visible in:
   • Effective route tables
   • BGP route views
   • UDRs or peering configuration
   Azure uses system routes and internal SDN components to implement behaviors such as:
   • Forced tunneling via VPN gateway or NVA
   • Longest prefix match (LPM) selection across system, BGP, and custom routes
   The documentation explicitly notes that routing decisions are based on LPM across system routes, BGP, and custom routes, and that only the LPM-matched routes are shown in effective routes, not every internal hop or platform component involved in forwarding.
3. For Azure routing validation, Network Watcher Next Hop and Effective Routes are authoritative over traceroute:
   • Next Hop tells which type of hop (Internet, VirtualNetworkGateway, VirtualAppliance, VNetPeering, None, etc.) is used for traffic to a given destination, based on the actual route selection logic.
   • Effective routes show the LPM-matched routes that are actively used for the NIC, including system, BGP, and custom routes.
   • Traceroute shows the path at the IP hop level, which can include Azure internal infrastructure that is not modeled as separate routes.
   The official guidance for diagnosing routing issues is to:
   • Use Next hop to determine the next hop type for a destination.
   • Use effective routes (az network nic show-effective-route-table) to see which route is actually used (for example, 0.0.0.0/0 → Internet, or 0.0.0.0/0 → Virtual appliance / VPN gateway).
   • Treat missing or misdirected routes (for example, next hop type None for a private range) as the authoritative indicator of routing problems, not traceroute anomalies.

Therefore, in the described scenario, the presence of 10.100.50.25 as an intermediate hop is consistent with expected Azure platform behavior, and Network Watcher’s Next hop = VirtualNetworkGateway plus the effective route table should be treated as the authoritative view of routing.

---

References:

• Diagnose a virtual machine routing problem
• Diagnose a virtual machine network routing problem using the Azure CLI
• Azure virtual network traffic routing
• Tutorial: Diagnose a virtual machine network routing problem using the Azure portal