Azure News - 2026-06-18
2026-06-18
最終更新: 2026-08-27 21:13:49 JST
Azure Updates
[Launched] Generally Available: ICMP Support for Azure Standard V2 NAT Gateway
- Link: https://azure.microsoft.com/updates?id=565487
- Published: 2026-06-18 01:30:04
- Fetched: 2026-08-27 21:13:48
[In preview] Public Preview: Azure Migrate – GitHub Copilot Modernization integration for at scale code assessments
- Link: https://azure.microsoft.com/updates?id=566145
- Published: 2026-06-18 03:00:18
- Fetched: 2026-08-27 21:13:48
[Launched] Generally Available: Azure Databricks native read access to Microsoft OneLake
- Link: https://azure.microsoft.com/updates?id=565733
- Published: 2026-06-18 03:00:18
- Fetched: 2026-08-27 21:13:48
[In preview] Public Preview: Azure Databricks natively storing data in Microsoft OneLake
- Link: https://azure.microsoft.com/updates?id=565706
- Published: 2026-06-18 03:00:18
- Fetched: 2026-08-27 21:13:48
Azure Networking Blog
ICMP Support for Azure StandardV2 NAT Gateway
- Link: https://techcommunity.microsoft.com/t5/azure-networking-blog/icmp-support-for-azure-standardv2-nat-gateway/ba-p/4528374
- Published: 2026-06-18 02:44:22
- Fetched: 2026-08-27 21:13:49
詳細を表示
Our customers, across all industries, depend on consistent outbound connectivity and observability to operate and troubleshoot their cloud workloads at scale. As Azure environments grow in size and complexity, teams increasingly rely on standard network diagnostic tools such as ping to quickly validate reachability and identify connectivity issues.
When customers route outbound traffic through Azure NAT Gateway, they benefit from centralized and scalable outbound connectivity designed to prevent SNAT port exhaustion, while simplifying management by removing the need for per‑resource public IPs. Historically, outbound connectivity through Azure NAT Gateway supported TCP and UDP traffic only for Azure workloads.
We are pleased to announce that Azure StandardV2 NAT Gateway now supports outbound ping through ICMP Echo Request and Echo Reply traffic. Workloads that rely on NAT Gateway for internet egress can now use ping to validate reachability, improving operational visibility and simplifying network troubleshooting while preserving the scalability and resiliency characteristics of NAT Gateway.
What’s now supported?
Azure StandardV2 NAT Gateway supports outbound ICMP Echo Request and Echo Reply traffic (ping) for IPv4 and IPv6. Other ICMP message types are not currently supported.
With this update, ICMP traffic sent from workloads behind a NAT Gateway can be translated to a public IP address and reliably receive responses from external endpoints. This brings ICMP behavior in line with existing TCP and UDP outbound flows, enabling consistent network diagnostics across all common transport types.
This capability is available automatically when workloads egress through a StandardV2 NAT Gateway - no additional configuration or rule changes are required.
Scenarios enabled by ICMP support
Support for ICMP through StandardV2 NAT Gateway unlocks several common operational scenarios:
- Basic reachability testing – Operators can use ping from virtual machines, VM scale sets, or AKS nodes behind NAT Gateway to verify outbound connectivity to internet endpoints.
- Health validation and troubleshooting – Teams can perform quick checks during incident triage without deploying jump hosts, public IPs per VM, or temporary firewall exceptions.
These scenarios are especially valuable in large‑scale environments where workloads rely on centralized outbound connectivity via NAT Gateway.
How ICMP works through StandardV2 NAT Gateway
Unlike TCP or UDP, ICMP does not use ports to differentiate flows. Instead, ICMP messages include an identifier field, which is used by diagnostic tools to correlate requests and responses.
A common troubleshooting scenario is when workloads deployed behind an Azure StandardV2 NAT Gateway are unable to reach external endpoints. Since these workloads typically do not have public IP addresses, it can be difficult to quickly determine whether the issue is related to basic network reachability or higher-layer configuration. In such cases, ICMP‑based diagnostics such as ping can be used to validate outbound connectivity and help isolate the source of the issue.
When a workload sends an outbound ICMP packet through a NAT Gateway:
- NAT Gateway translates the source private IP to one of its associated public IP addresses.
- The platform tracks the ICMP flow using the ICMP identifier and other packet attributes.
- Return ICMP responses from the external destination are matched to the originating flow.
- The response is translated back to the original private IP and delivered to the workload.
This stateful handling allows replies to be routed correctly even when multiple workloads are sending ICMP traffic concurrently through the same NAT Gateway.
Using ICMP for end-to-end outbound troubleshooting
To validate outbound connectivity using ICMP from workloads deployed behind StandardV2 NAT Gateway:
- Go to your virtual network in the Azure portal and select the subnet hosting your workload.
- Verify that a StandardV2 NAT Gateway is associated with the subnet.
The workload does not require a public IP address. - Connect to the workload (for example, a virtual machine) running in the subnet.
- Run an ICMP ping to an external destination to validate outbound reachability.
Successful ping from a workload behind an Azure StandardV2 NAT Gateway demonstrating outbound connectivity and ICMP Echo reply.
- Review the results.
Successful ICMP echo replies confirm that outbound connectivity through StandardV2 NAT Gateway is functioning and that ICMP traffic is translated and returned correctly
Summary
With ICMP Echo support, Azure StandardV2 NAT Gateway provides a more complete outbound networking experience by enabling essential diagnostic tools to function reliably through NAT. Customers can validate reachability, perform basic troubleshooting, and diagnose connectivity issues while continuing to benefit from the simplicity and scale of centralized outbound connectivity.
Learn More