Reporting MSN Network Routing Issue

Thank you for your response. I performed tests from multiple internal sites and traceroute consistently dies within Microsoft's network for one specific site. I can see the hop as msn.net and it is timing out from there.

We have a WAF firewall where we are whitelisting all the ip's and confirmed the site ip in there.

Also, from the traceroute looks like it is not even hitting that WAF. It is failing in the mid path.

Is there a way to fix it without opening a support ticket with MS?

Hello @NK

If the Azure resource is reachable from other ISPs/public IPs but fails consistently from one specific ISP, I wouldn't start by changing Azure Firewall rules. That pattern is more consistent with an Internet routing/BGP path issue, asymmetric routing, or an ISP-to-Microsoft peering issue.

First, collect evidence from the affected ISP while the problem is occurring:

tracert <Azure-public-IP>

pathping <Azure-public-IP>

If possible, run the same tests from a working ISP for comparison. Record the source public IP, destination Azure public IP, exact UTC timestamp, and where the traces begin to diverge.

On the Azure side, also verify that nothing in your configuration is dropping the traffic. Azure Network Watcher provides Connection troubleshoot, Next Hop, IP Flow Verify, and packet capture specifically for diagnosing routing and filtering issues.

For example, Next Hop can confirm whether Azure is selecting the expected route toward the affected source/destination.

If Azure Firewall is involved, check its network/application rule logs during a failed attempt. If the incoming traffic never appears in Azure-side captures/logs, that's useful evidence that the failure is occurring upstream rather than at the firewall.

If the traceroute consistently dies within Microsoft's network, however, be careful interpreting that alone. Routers may simply choose not to answer ICMP while still forwarding production traffic. A simultaneous packet capture and a TCP connectivity test to the application's port provide stronger evidence.

If you can reproduce the issue only from that ISP, you have to open cases with both the ISP and Microsoft Azure Support and provide:

• affected source public IP/prefix
• Azure destination public IP
• protocol/port
• working and failing traceroutes
• exact UTC timestamps
• packet captures if available
• Azure region/resource details

That gives the networking teams enough information to investigate the BGP/peering path. You can't normally fix this with a route table inside the VNet if the failure occurs on the public Internet path before traffic reaches your Azure resource.

Microsoft's troubleshooting guidance also recommends Network Watcher for determining routing, filtering, and connectivity failures.

Sharing these references with you:

Azure Network Watcher documentation

Troubleshoot connections with Network Watcher

Diagnose Azure VM routing problems

Please "Accept the Answer" if this information helped you. This will help us and others in the community.