Azure NAT Gateway Not Working, Connectivity, Rules, and Routing Fixes
Why Azure NAT Gateway Stops Working
You've deployed an Azure NAT Gateway, wired everything up, and your virtual machines still can't reach the internet. No outbound connections, curl times out, nothing. I've seen this exact scenario dozens of times, and almost every time, the root cause comes down to one of four very fixable things: a missing public IP, a misconfigured subnet association, a Network Security Group rule that quietly swallows your traffic, or the NAT gateway itself sitting in a failed provisioning state.
The infuriating part is that Azure doesn't always surface a clear error. Your NAT gateway shows as "Succeeded" in the portal, but traffic still doesn't flow. That's because the portal reports the resource's provisioning state, not whether it's actually passing packets. Those are two very different things, and the gap between them is where hours of debugging disappear.
Let's talk about who hits this most. If you're migrating workloads from a hub-spoke architecture, consolidating multiple outbound IP strategies, or just spinning up a new subnet and forgetting to reattach the NAT gateway, you'll land here. Teams running Basic Load Balancers or Basic Public IPs on the same subnet as their NAT gateway hit a hard incompatibility wall, Basic SKU resources simply cannot coexist with NAT gateway on the same subnet. That's not a configuration mistake you can tweak around; Basic resources have to move or be upgraded to Standard SKU.
Another common trap: people test Azure NAT Gateway connectivity using ping. It fails. They assume the NAT gateway is broken. It's not. NAT Gateway does not support ICMP. Ping will always fail. Always. You need TCP or UDP tools to validate real connectivity, and I'll walk you through exactly which ones to use.
The StandardV2 NAT gateway tier introduces a few additional failure modes, including a known issue where attaching it to an empty subnet that was created before April 2025 can push either the virtual network or the NAT gateway into a failed state. That one catches a lot of people off guard because nothing about the operation looks wrong until the whole VNet starts misbehaving.
Whatever landed you here, this guide covers every scenario. We'll go from the fastest single check all the way through flow log analysis and enterprise-level route table conflicts. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before diving into deep diagnostics, run through this checklist in the Azure Portal. These two checks alone resolve the majority of Azure NAT Gateway connectivity problems I encounter.
Step 1, Confirm a public IP address is actually attached. Open the Azure Portal, search for your NAT gateway resource, and click on it. In the left-hand menu, click Outbound IP. You need to see at least one public IP address or one public IP prefix listed here. If this section is empty, your NAT gateway is physically incapable of providing outbound connectivity, it has nowhere to source traffic from. Click + Add a public IP address, select or create a Standard SKU public IP, and hit Save.
Step 2, Confirm a subnet is associated. Still inside your NAT gateway resource, click Subnets in the left-hand menu. At least one subnet must appear here. If the list is empty, your VMs have no NAT gateway to route through regardless of how the rest of your network is configured. Click + Associate subnet, pick the correct virtual network and subnet, and save.
Step 3, Quick connectivity test from a VM. Once both are confirmed, SSH or RDP into a VM on the associated subnet and run a quick TCP connection test. On Linux:
curl -v https://ifconfig.meOn Windows, open PowerShell and run:
Invoke-WebRequest -Uri "https://ifconfig.me" -UseBasicParsingIf you get back your NAT gateway's public IP address in the response, you're done. Traffic is flowing correctly through the gateway. If you get a timeout or connection refused, keep reading, there's something deeper going on.
ping to test NAT gateway connectivity. Azure NAT Gateway does not support ICMP protocol, ping is expected to fail even when the gateway is configured perfectly. Always use TCP-based tools like curl, nc, PsPing, or PowerShell's Invoke-WebRequest to get accurate results. This single misunderstanding accounts for a massive number of false "broken NAT gateway" reports.
Think of Azure NAT Gateway configuration as a three-legged stool, public IP, subnet association, and clear routing. If any leg is missing or wrong, the whole thing falls over. Let's verify all three systematically.
Public IP or prefix check: In the Azure Portal, navigate to your NAT gateway → Outbound IP. A Standard SKU public IP or a public IP prefix must be present. Note that only Standard SKU public IPs work here, if you created a Basic public IP by accident, it won't attach. The portal will either block the association or silently fail to route traffic. Check the SKU column next to each IP listed.
Subnet association check: Navigate to Subnets in your NAT gateway. Multiple subnets can be associated, but they all must belong to the same virtual network. NAT gateway cannot span across virtual networks, this is a hard architectural boundary, not a configuration option. If your VMs are on a subnet in VNet-A and your NAT gateway is associated with VNet-B, nothing will work, full stop.
Gateway subnet exclusion: One thing that trips up network engineers new to Azure, NAT gateway cannot be deployed in a gateway subnet. If your subnet is named GatewaySubnet or is configured as a VPN gateway subnet, NAT gateway association will fail. The fix is simply to associate NAT gateway with any other subnet in the same virtual network.
After confirming all three items are correct, test from a VM on the associated subnet using the TCP test from the Quick Fix section. If traffic still isn't flowing, move to Step 2 and look at what might be blocking it.
This is the second most common reason Azure NAT Gateway outbound connectivity fails after initial configuration looks correct. Network Security Group (NSG) rules and User Defined Routes (UDRs) can silently override NAT gateway routing without any obvious error in the portal.
NSG outbound rules: Go to the Network Security Group attached to either your subnet or your VM's network interface. Click Outbound security rules. Scan for any rules with a Deny action that targets port 80, 443, or Any destination. Pay close attention to the priority order, rules are evaluated lowest number first, and a Deny rule at priority 100 will override an Allow rule at priority 200. If you see something like DenyAllOutBound at a low priority number that's being hit before your Allow rules, that's your culprit.
To test whether an NSG rule is blocking specific traffic, use the IP flow verify feature in Azure Network Watcher. In the portal, search for Network Watcher → IP flow verify. Select the VM, direction (Outbound), protocol (TCP), local port (any ephemeral port like 50000), and remote IP/port (e.g., 8.8.8.8:443). The tool will tell you exactly which NSG rule is allowing or denying that specific flow, no guessing required.
UDR (route table) conflicts: Navigate to the Route table associated with your subnet. Look for any routes with a 0.0.0.0/0 prefix that point to a Virtual Appliance or VPN Gateway next hop. These routes will capture all internet-bound traffic before NAT gateway ever sees it. If you have a forced-tunneling route directing all traffic back on-premises, your NAT gateway's outbound path is completely bypassed. Either remove that route for the subnet or adjust it so internet-bound traffic isn't captured by the UDR.
If both NSG and UDR look clean, continue to Step 3 for direct connectivity validation.
I want to say this again clearly: do not use ping. ICMP is not supported by Azure NAT Gateway and will always time out. This is by design, not a bug. Every single test you run to validate NAT gateway must use TCP or a UDP-specific application layer test.
On Linux VMs, the two tools you want are nc (netcat) for generic TCP connection testing and curl for full application layer HTTP/HTTPS tests:
# Generic TCP connection test to port 443
nc -zv 8.8.8.8 443
# Full HTTP test that returns your outbound public IP
curl -s https://ifconfig.me
# Verbose output to see connection details
curl -v --max-time 10 https://www.microsoft.comA successful nc output looks like: Connection to 8.8.8.8 443 port [tcp/https] succeeded!. If you see Connection refused, that's a remote firewall issue. If you see Operation timed out, something in your Azure network path is blocking the traffic before it leaves.
On Windows VMs, use PsPing from Sysinternals or PowerShell:
# PsPing TCP test
psping 8.8.8.8:443
# PowerShell HTTP test
Invoke-WebRequest -Uri "https://ifconfig.me" -UseBasicParsing
# Test TCP port directly with PowerShell
Test-NetConnection -ComputerName 8.8.8.8 -Port 443Confirming your NAT gateway public IP is being used: The curl https://ifconfig.me or Invoke-WebRequest https://ifconfig.me response should return the exact public IP address you associated with the NAT gateway. If it returns a different IP, such as a public IP directly attached to the VM, your NAT gateway isn't in the routing path. Double-check your subnet association and make sure there's no instance-level public IP on the VM taking priority.
This one is subtle and genuinely frustrating. Your NAT gateway resource shows in the portal, looks healthy at a glance, but nothing works. When you dig into the provisioning state, it says Failed. The portal doesn't offer a one-click fix, and there's no obvious "retry" button.
The recovery process goes through Azure Resource Explorer, which is a low-level REST API browser built into the Azure Portal. Here's exactly what to do:
1. In the Azure Portal, search for Resource Explorer in the top search bar and open it. Alternatively, navigate directly to resources.azure.com in your browser while signed in to your Azure account.
2. In the left-hand tree, expand: subscriptions → your subscription → resourceGroups → your resource group → providers → Microsoft.Network → natGateways → your NAT gateway name.
3. In the top-right area of the Resource Explorer, find the Read/Write toggle and switch it to Read/Write mode. This unlocks the edit capability.
4. Click the Edit button. The JSON definition of your NAT gateway appears. Don't change anything in the JSON body itself.
5. Click PUT. This resubmits the resource definition to Azure Resource Manager, which triggers a fresh provisioning cycle.
6. After the PUT completes, click GET to refresh the resource view. Check that "provisioningState" now shows "Succeeded".
Once provisioning state is Succeeded, retest connectivity from your VM using the tools from Step 3. In most cases, traffic flows immediately after this operation.
If you've worked through every configuration check and still can't pinpoint why outbound traffic is failing, VNet flow logs are your best diagnostic tool. They give you a packet-level view of what's actually happening, source IP, source port, destination IP, destination port, connection state, and byte counts. Real evidence rather than guesswork.
Enabling VNet flow logs for Standard NAT gateway: In the Azure Portal, navigate to Network Watcher → Flow logs → + Create. Select Virtual network as the flow log type. Choose your VNet, give it a name, select a Storage Account to write logs to, and optionally enable Traffic Analytics for a more visual Log Analytics-based experience. Set the retention period (90 days is a safe default for troubleshooting), and click Create.
For StandardV2 NAT gateway, you get a more direct option, NAT gateway flow logs through Azure Monitor. These logs are specific to traffic flowing through the NAT gateway itself rather than the broader VNet, which can make it easier to isolate NAT-specific issues.
Once logs are flowing (give it 5–10 minutes after enabling), open Log Analytics and run a query targeting your VNet flow log table. A useful starting query to find failed outbound connections:
NTANetAnalytics
| where FlowDirection == "Outbound"
| where FlowStatus == "Denied" or FlowStatus == "Blocked"
| project TimeGenerated, SrcIP, DstIP, DstPort, Protocol, FlowStatus
| order by TimeGenerated desc
| take 100The source IP and port in these logs reflect the VM's private IP, not the NAT gateway's public IP. That's expected, the log is captured before SNAT translation happens. If you see outbound flows consistently showing as Denied, cross-reference those destination IPs and ports with your NSG rules to find the blocking rule. If flows show as Allowed but the VM still can't connect, the problem is downstream of your Azure network, likely a remote-side firewall.
Advanced Troubleshooting for Azure NAT Gateway
Fixing the StandardV2 Failed State on Empty Subnets
If you're running the StandardV2 NAT gateway tier and you're seeing either your VNet or the NAT gateway itself go into a failed state after associating with a subnet, there's a known cause: subnets created before April 2025 that don't contain any virtual machines can trigger this exact failure when a StandardV2 NAT gateway is attached to them.
The fix is a three-step process, remove the NAT gateway association, provision a VM into the empty subnet, then reattach the NAT gateway. To remove the association, go to your NAT gateway → Subnets → select the problematic subnet → click Disassociate. Then deploy any small VM (a B1s is fine, you can delete it after) into that subnet. Finally, return to your NAT gateway → Subnets → + Associate subnet and re-add the subnet. The failed state should clear and provisioning should succeed.
Regional Availability Gaps for StandardV2
If you're getting deployment errors specifically for StandardV2 NAT gateway, the resource may simply not be available in your selected region. As of April 2026, StandardV2 NAT Gateway is not available in: Brazil Southeast, Canada East, Central India, Chile Central, Indonesia Central, Israel Northwest, Malaysia West, Qatar Central, Sweden South, UAE Central, West Central US, and West India. If you're deploying into one of these regions, you'll need to use the standard NAT gateway tier instead, or move the workload to a supported region.
Basic Resources Incompatibility
NAT gateway and Basic SKU resources cannot share a subnet. This is a hard constraint, not a soft warning. If your subnet contains a Basic Load Balancer or a Basic Public IP attached to any VM, NAT gateway association will fail. You have two options: move the Basic resources to a different subnet that doesn't use NAT gateway, or upgrade them to Standard SKU.
To upgrade a Basic public IP, navigate to the Public IP resource → Overview → you'll see an Upgrade prompt if it's Basic SKU. For Basic Load Balancers, the upgrade process requires running a PowerShell migration script since in-place upgrades have limitations. Microsoft's upgrade path for load balancers is well-documented and the script handles the conversion without recreating your backend pool.
VM Network Interface in a Failed State Blocking Subnet Association
You may hit an error when trying to attach a NAT gateway to a subnet that contains a VM whose network interface is in a failed state. The error message is explicit about this. Before the association can proceed, that NIC's failed state must be cleared first.
One quick method using PowerShell:
# Get the NIC
$nic = Get-AzNetworkInterface -Name "your-nic-name" -ResourceGroupName "your-rg"
# Force a re-apply of the NIC configuration
Set-AzNetworkInterface -NetworkInterface $nicAfter the Set-AzNetworkInterface call completes, verify the NIC's provisioning state is "Succeeded" via $nic.ProvisioningState, then retry the NAT gateway subnet association.
Prevention & Best Practices for Azure NAT Gateway
Once you've fixed the immediate problem, there are several habits and architecture decisions that dramatically reduce the chance of landing here again. Azure NAT Gateway is a straightforward resource at its core, most long-term problems come from configuration drift, subnet changes after initial setup, or platform SKU mismatches that sneak in during infrastructure scaling.
Use Azure Policy to enforce NAT gateway subnet associations. In larger environments where multiple teams are creating subnets, it's easy for a new subnet to go live without a NAT gateway attached. An Azure Policy assignment that audits subnets lacking a NAT gateway association gives you visibility before it becomes a production incident.
Always use Standard SKU for everything on NAT gateway subnets. Before you create a public IP, a load balancer, or any network resource that will share a subnet with NAT gateway, check the SKU. Default to Standard every time. The Basic/Standard compatibility issue is one of the most avoidable failures I see in Azure networking, it almost always comes down to a team member clicking through the wizard too fast and accepting the Basic default.
Tag and document your NAT gateway public IPs. NAT gateway outbound IPs are visible to the external services your VMs connect to. If you're calling third-party APIs or SaaS platforms that whitelist IPs, any change to your NAT gateway public IP will break those connections silently. Apply resource tags to your NAT gateway public IPs (environment: prod, notify-on-change: true), and document them in your network runbook. Consider using a Public IP Prefix so your IP range stays predictable even as you scale.
Enable VNet flow logs proactively, not reactively. Turning on flow logging only after something breaks means you have no historical baseline to compare against. Enable flow logs on your VNets from day one. The storage costs are minimal, and when an outage happens at 2 AM, you'll be grateful for the traffic history that was quietly accumulating for months.
Validate after every subnet change. Anytime you add a subnet, modify a route table, or touch an NSG, run the quick TCP connectivity check from a VM on that subnet immediately. Catching a misconfiguration right after a change is orders of magnitude faster than diagnosing it days later when something mysteriously stops working.
- Set up an Azure Monitor alert on NAT gateway provisioning state, get notified the moment it enters a failed state rather than discovering it from user reports
- Use Public IP Prefixes instead of individual public IPs on your NAT gateway to give downstream services a predictable IP range to whitelist
- Never attach a NAT gateway to a gateway subnet, keep a naming convention that makes gateway subnets immediately obvious to anyone editing the network
- Run
Test-NetConnectionorncconnectivity checks as part of your VM provisioning automation to catch routing issues before the VM goes into production
Frequently Asked Questions
Why does ping fail even though my Azure NAT Gateway looks configured correctly?
This is completely expected behavior, Azure NAT Gateway does not support ICMP protocol, which is what ping uses. Even a perfectly configured NAT gateway will cause every ping to fail. This is by design, not a bug. To properly test connectivity, use TCP-based tools: on Linux use curl or nc, on Windows use PsPing or PowerShell's Invoke-WebRequest or Test-NetConnection. These will give you accurate results about whether your NAT gateway is routing traffic correctly.
Can I attach an Azure NAT Gateway to multiple subnets at the same time?
Yes, a single NAT gateway resource can be associated with multiple subnets, and this is actually a common and recommended configuration. The constraint is that all associated subnets must be within the same virtual network. NAT gateway cannot span across virtual networks, so you can't use one NAT gateway to provide outbound connectivity for subnets in VNet-A and VNet-B simultaneously. Within a single VNet, though, attach it to as many subnets as you need.
My NAT Gateway is in a failed state and the portal PUT/GET trick didn't work, what now?
If the Azure Resource Explorer PUT/GET recovery procedure doesn't clear the failed state, try removing and re-creating the NAT gateway resource. Before doing that, document your public IP associations and subnet associations so you can recreate them exactly. If the VNet itself is also in a failed state (this can happen with StandardV2), you may need to open a Microsoft Support ticket, VNet-level failures can't always be self-recovered and require Microsoft backend intervention. Include your NAT gateway resource ID, subscription ID, and the exact error message from the activity log when you open the case.
Can I use both a NAT Gateway and a public IP directly on my VM at the same time?
Yes, but the behavior may surprise you. When a VM has a public IP directly assigned to its network interface and is also on a subnet associated with a NAT gateway, the VM's instance-level public IP takes priority for outbound connections, NAT gateway doesn't handle that VM's outbound traffic. This is something to be aware of if you're trying to ensure all outbound traffic exits through the NAT gateway (for IP whitelisting purposes, for example). To force traffic through NAT gateway, remove the direct public IP from the VM's network interface.
Why is my StandardV2 NAT Gateway not available when I try to deploy in my region?
StandardV2 NAT Gateway has limited regional availability and as of early 2026 is not supported in several regions including Brazil Southeast, Canada East, Central India, Chile Central, Indonesia Central, Israel Northwest, Malaysia West, Qatar Central, Sweden South, UAE Central, West Central US, and West India. If you're deploying in one of these regions, select the standard (non-V2) NAT gateway tier instead. If you need StandardV2 features specifically, you'll need to deploy the workload to a supported region or wait for regional expansion.
How do I delete an Azure NAT Gateway that's stuck and won't let me remove it?
Azure NAT Gateway can't be deleted while it's still associated with any subnets. You have to detach it from every subnet first. Go to the NAT gateway resource → Subnets → select each associated subnet → click Disassociate for each one. Once the subnet list is empty, go back to the NAT gateway's Overview page and click Delete. If the delete still fails after disassociating all subnets, check whether the resource is in a failed provisioning state, use the Azure Resource Explorer PUT/GET recovery to get it to Succeeded first, then retry the deletion.