Unable to access Azure Storage Account from on-premises (network error) + need guidance on VPN Gateway logs and traceroute limitations

Question

Problem Statement

We have an Azure Storage Account (with private endpoint enabled) that is accessed from on-premises via VPN Gateway.

Previously, users from on-premises were able to access containers successfully, but now they are encountering network errors while opening containers.

• No changes have been made on the Azure side (network rules, firewall, private endpoint, DNS, etc.)
• Access is already allowed from both Azure and on-premises
• Issue is occurring only for on-premises users

We are currently troubleshooting connectivity between on-premises network and Azure VNet.

Observations

• Storage account is configured with private endpoint
• Traffic flows via VPN Gateway (Site-to-Site)
• Diagnostic logs for VPN Gateway are enabled and sent to:
  • Log Analytics Workspace
  • Storage Account
  • On-premises team wants to validate routing using traceroute to storage account FQDN, but it is failing

Questions

1. How to verify on-premises traffic using VPN Gateway diagnostic logs?

We want to confirm:

• Whether traffic from specific on-prem IP/subnet is reaching Azure Virtual Network Gateway
• Whether traffic is being dropped or not

We attempted KQL queries but did not get results.

However, we are not sure how to:

• Extract source IP / subnet (on-prem side)
• Validate incoming traffic patterns

Could you please provide:

• Sample KQL queries to identify:
  • Source IPs hitting the gateway
  • Tunnel traffic status
• Best way to confirm if traffic from on-prem network is reaching Azure

2. Traceroute to Azure Storage FQDN (ICMP blocked scenario)

On-premises team wants to run traceroute to storage account FQDN, but it fails.

We understand:

• Azure does not support ICMP/traceroute for endpoints in many scenarios

Questions:

• Is there any supported way to validate routing path to Storage Account Private Endpoint?
• Since traceroute depends on ICMP TTL expiry responses, is this expected behavior in Azure?

3. Using NSG to allow ICMP for traceroute (Private Endpoint subnet)

We are considering:

• Applying NSG on subnet where private endpoint exists
• Adding rule: Allow ICMP

Need clarification:

• Will allowing ICMP via NSG help traceroute scenario?
• Will adding ICMP rule impact existing traffic (HTTPS/SMB/etc.)?

From our understanding:

• NSGs are stateful and filter traffic based on protocol, port, source, destination
• Storage account communication primarily uses (port 443 and 22)

Please confirm:

• Allowing ICMP will NOT block existing ports like 443 and 22
• And ICMP rule will just add additional allowed protocol, not override others

Also, requesting official Microsoft documentation link confirming if available:

Allowing ICMP in NSG does not block ports like 443 and 22

What we are trying to achieve

• Validate whether issue is:
  • Routing problem
  • VPN tunnel issue
  • DNS resolution issue
  • Storage firewall / private endpoint issue

4.Can network error in container cause due to IPs overlapping between different LNG tunnels but both tunnels are using seperate Gateway but their vnet is peered

Expected Help

We are looking for guidance on:

1. Correct KQL queries for VPN Gateway logs
2. Alternative to traceroute for Azure Storage connectivity validation
3. Confirmation on NSG + ICMP behavior
4. Documentation references for the above

Answer 1

Hi Shubhangi Nannware,

Thanks for updating us on the issue.

You’re seeing KQL errors in the Azure portal because the VPN Gateway diagnostic logs may not be landing in the Log Analytics workspace as expected, or the query is being applied against the Storage Account’s own logs instead of the VPN Gateway / GatewayDiagnosticLog tables. Let me walk you through how to inspect and validate these logs when the KQL queries are failing.

How to check VPN Gateway logs in the Storage Account

If you configured diagnostic settings on the Virtual Network Gateway to send logs to a Storage Account, the raw logs are stored as JSON blobs in a blob container. The path structure looks like:

subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworkGateways/{vpngw-name}/...

Inside this path, you’ll find folders grouped by:

• category=GatewayDiagnosticLog
• category=TunnelDiagnosticLog
• category=IkeEvent, etc.

To inspect them:

• Go to your Storage Account → Blob containers and open the container configured for diagnostics.
• Navigate into the folders under MICROSOFT.NETWORK/virtualNetworkGateways/....
• Download or open a few JSON files for the relevant time window and look for:
  • Source and Destination (e.g., on‑prem IP to gateway IP)
  • ConnectionName (tunnel name) Status (success/failure, dropped, etc.)

This manual inspection will help you confirm whether traffic from your on‑prem IP/subnet is hitting the gateway and what the system is logging.

What to do when KQL queries fail

If the KQL examples still throw errors, start with a simple discovery:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK"
| where Category contains "GatewayDiagnosticLog"
| take 5

If this returns no rows, it means:

The VPN Gateway diagnostic logs are not arriving in this Log Analytics workspace.

Or the logs are being written to a different workspace or only to the Storage Account (no Log Analytics).

In that case:

1. Go to the Virtual Network Gateway → Diagnostics settings and confirm:
   • GatewayDiagnosticLog / TunnelDiagnosticLog are enabled.
   • The logs are sent to the correct Log Analytics workspace.
2. If they are only sent to the Storage Account, you’ll need to either:
   • Fix the routing to Log Analytics, or
   • Continue analyzing the JSON blobs in the Storage Account container, as described above.

How to still validate traffic from on‑prem

Even if the KQL path is tricky, you can still validate connectivity:

• From a VM in the same VNet as the private endpoint:
  • Run Test-NetConnection <private-endpoint-IP> -Port 443 -InformationLevel Detailed to verify TCP reachability from Azure.
  • Use Network Watcher → IP flow verify:
  • Source IP: your on‑prem IP (simulate traffic). Destination IP: private endpoint IP, port 443.

        This tells you whether NSGs or route‑tables are blocking the flow on the Azure side.
        ```If IP flow verify **allows** the traffic, the issue is likely:
    
    

On‑prem routing, DNS resolution, or client‑side issues.

If it blocks, review:

• NSG rules on the private endpoint subnet.
• Route tables / UDRs that might be steering traffic away from the VPN path.

ICMP / NSG behavior confirmation

To re‑confirm what you were considering:

• NSG rules are stateful and additive.
• Adding an Allow ICMP rule on the private‑endpoint‑subnet:
  • Only permits ICMP traffic (echo, TTL‑expired, etc.).
  • Does not block or override existing rules for TCP ports 443/22/SMB 445.
• However, Azure‑managed infrastructure (including many Private Link endpoints and internal routers) typically do not respond to ICMP TTL‑expired packets, so traceroute to the Storage FQDN will likely still fail even with ICMP allowed. This is expected behavior.

Official Microsoft documentation links

• Virtual Network Gateway diagnostics and log categories: https://learn.microsoft.com/azure/virtual-network/vpn-gateway-troubleshoot-vpn-connections
• Network Watcher IP flow verify: https://learn.microsoft.com/azure/network-watcher/network-watcher-ip-flow-verify-overview
• Network Watcher Connection Monitor: https://learn.microsoft.com/azure/network-watcher/connection-monitor-overview
• Storage account diagnostics and logs: https://learn.microsoft.com/azure/storage/common/storage-analytics-logging
• NSGs overview and stateful behavior: https://learn.microsoft.com/azure/virtual-network/network-security-groups-overview
• Azure Private Link / private endpoints limitations (traceroute / ICMP): https://learn.microsoft.com/azure/private-link/private-endpoint-overview

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

1. Verifying on-premises traffic with VPN Gateway diagnostics

Use VPN Gateway diagnostic logs and Network Watcher VPN troubleshoot to validate whether on-premises traffic is reaching the gateway and if the tunnel is healthy.

From the provided context:

• VPN Gateway diagnostics produce:
  • GatewayDiagnosticLog
  • TunnelDiagnosticLog
  • RouteDiagnosticLog
  • IKEDiagnosticLog
  • P2SDiagnosticLog (for P2S)
• Network Watcher VPN troubleshoot writes detailed logs (IKElogs, IKEErrors, ConnectionStats, CPUStats, etc.) into a storage account and also returns a Healthy/UnHealthy status for the gateway and connection.

Recommended approach:

1. Run Network Watcher VPN troubleshoot on the affected VPN connection:
   • In Azure portal → Network Watcher → VPN troubleshoot.
   • Select the VPN gateway and the specific connection.
   • Select a storage account/container and start troubleshooting.
   • When complete, check:
     • The status (Healthy/UnHealthy) in the portal.
     • The generated logs in the storage account (especially IKElogs/IKEErrors and ConnectionStats).
   • Common issues highlighted in logs include:
     • Shared key mismatch:
       • Error: Authentication failed. Check shared key.
     • IPsec parameter mismatch:
       • Error: On-premises device rejected Quick Mode settings. Check values. based on log : Peer sent NO_PROPOSAL_CHOSEN notify
2. Use the VPN troubleshoot log files:
   • ConnectionStats.txt: shows connection state, ingress/egress bytes, and connection time. This confirms whether the tunnel is up and passing traffic.
   • IKElogs.txt / IKEErrors.txt: show IKE activity and failures.
   • Scrubbed-wfpdiag.txt: contains packet drop and IKE/AuthIP failures.

These logs confirm whether the tunnel is established and whether packets are being dropped at the gateway. The context does not provide specific KQL examples for extracting source IPs or subnets from these logs, so only the above log-level guidance is supported.

If more detailed analysis is needed, configure VPN Gateway diagnostics to Log Analytics (already done) and use the documented log types (GatewayDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog, IKEDiagnosticLog) as described in the VPN Gateway diagnostics article referenced in the context.

2. Traceroute to Storage Account FQDN / ICMP limitations

The context confirms that for network datapath troubleshooting in Azure environments, relying on ICMP (ping/traceroute) is discouraged and often blocked:

• Ping/ICMP is frequently blocked by OS and network firewalls.
• Load-balanced or virtual IP endpoints typically block ping by default.
• Instead of ping/traceroute, the recommended tools are:
  • Test-NetConnection on Windows
  • telnet on Linux

Recommended method to validate routing/reachability to the Storage Account private endpoint:

• From on-premises:
  • Use Test-NetConnection (or equivalent) to the private endpoint IP or FQDN on port 443.
  • Run it in a loop for 15–30 seconds to generate sufficient traffic:

        while ($true) {
            Test-NetConnection -ComputerName <storage-private-endpoint-FQDN-or-IP> -Port 443
        }
    

• Collect network traces at both ends (on-premises and Azure VM in the same VNet as the private endpoint) and correlate with VPN Gateway logs.

Given Azure’s behavior, traceroute failure to a Storage Account private endpoint is expected and not a reliable diagnostic method.

3. NSG + ICMP behavior for private endpoint subnet

The context does not include explicit NSG behavior documentation for ICMP vs. TCP ports 443/22. Therefore, no additional statements beyond what is in the context can be provided.

4. IP overlap between different tunnels

The context does not cover IP overlap scenarios between different VPN tunnels or their interaction with peered VNets, so no supported answer can be provided from the given material.

Summary of supported actions from context

• Use Network Watcher VPN troubleshoot to:
  • Diagnose VPN gateway and connection health.
  • Generate logs (IKElogs, IKEErrors, ConnectionStats, Scrubbed-wfpdiag, etc.) in a storage account.
  • Get a Healthy/UnHealthy result and guidance.
• Use VPN Gateway diagnostic logs (GatewayDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog, IKEDiagnosticLog, P2SDiagnosticLog) for deeper troubleshooting.
• Avoid relying on ping/traceroute; instead use Test-NetConnection/telnet and collect traces from both ends.

---

References:

• Diagnose on-premises VPN connectivity with Azure
• Troubleshoot Azure VPN Gateway using diagnostic logs
• VPN troubleshoot overview
• Troubleshoot VPN virtual network gateways and connections using the Azure CLI
• Collect traces and logs to troubleshoot common SDN issues