Azure NAT Gateway: Fix Setup, Connectivity & SNAT Errors

Why This Is Happening

You've set up an Azure NAT Gateway, or you're trying to, and something just isn't working. Maybe your VMs in a private subnet still can't reach the internet. Maybe you're seeing SNAT port exhaustion errors under load. Maybe you deployed a StandardV2 NAT Gateway and now your virtual network is stuck in a failed state , and the Azure portal is giving you a vague error with zero guidance on how to fix it. I've seen every one of these scenarios, and they're all fixable once you understand what Azure NAT Gateway actually does under the hood.

Here's the core concept you need to internalize: Azure NAT Gateway is a fully managed, distributed Network Address Translation service. It lets every resource in a subnet reach the internet using shared public IP addresses , without those resources ever needing a public IP of their own. Crucially, it's a one-way door. Unsolicited inbound connections from the internet are blocked. Only response packets to outbound connections can flow back through. That security model is exactly why things break in non-obvious ways when the configuration is off.

The two most common reasons people land on this guide are:

1. SNAT port exhaustion, Your subnets are hammering outbound connections faster than NAT Gateway can allocate Source Network Address Translation ports. This surfaces as intermittent connection failures, especially under load, and it's one of the most misdiagnosed networking problems in Azure.
2. SKU mismatch or missing association, You created a NAT Gateway but didn't properly associate it with a subnet, or you're using a Standard SKU public IP with a StandardV2 NAT Gateway (which isn't supported, more on that below).

There's also a third category that trips up Azure engineers who are newer to the platform: the StandardV2 SKU is currently in public preview, and it has a meaningful list of limitations and known bugs, including a nasty one where attaching it to an empty subnet created before April 2025 can send your entire virtual network into a failed state. Microsoft's error messages for this are genuinely unhelpful, which is why you're here.

The good news: Azure NAT Gateway is intentionally designed to be straightforward to configure. When it breaks, it almost always comes down to one of a handful of root causes, and they're all addressable with the right sequence of steps. Browse all Microsoft fix guides →

The Quick Fix, Try This First

Before diving into a full diagnostic, run through this checklist. In my experience, about 70% of Azure NAT Gateway problems are solved by catching one of these misconfigurations early.

Step 1, Verify the subnet association. Open the Azure portal, navigate to your NAT Gateway resource, and click Subnets in the left-hand menu under Settings. If the subnet you expect to use isn't listed there, that's your problem. A NAT Gateway that isn't associated with a subnet does absolutely nothing. Click + Associate, pick your virtual network and subnet, and save.

Step 2, Confirm the public IP or prefix is attached. Still in your NAT Gateway resource, click Outbound IP in the left menu. You need at least one public IP address or one public IP prefix assigned. If this blade shows nothing, your VMs have nowhere to NAT their traffic to. Add a public IP by clicking + Add a public IP address.

Step 3, Check the SKU match. This is the silent killer for StandardV2 deployments. If you're using StandardV2 NAT Gateway, you must use StandardV2 SKU public IP addresses. Standard SKU public IPs are not supported with StandardV2 NAT Gateway. In the portal, go to your public IP resource, look at SKU in the Overview pane. If it says "Standard" instead of "Standard V2", you need to create a new public IP with the correct SKU.

Step 4, Check your region. StandardV2 NAT Gateway isn't available everywhere. If your virtual network is deployed in Canada East, Central India, Chile Central, Indonesia Central, Israel Northwest, Malaysia West, Qatar Central, or UAE Central, StandardV2 is not an option in your region yet. You'd need to use the Standard SKU instead.

Step 5, Run a connectivity test. SSH into one of your private VMs (via Azure Bastion or a jump box), then run:

curl -s https://ifconfig.me

If this returns the public IP you assigned to your NAT Gateway, everything is working. If it hangs or fails, continue to the step-by-step section below.

Advanced Troubleshooting

If you've worked through the steps above and you're still hitting issues, here's where to dig deeper. These scenarios come up more in enterprise environments, larger deployments, Infrastructure-as-Code pipelines, and multi-tenant architectures where the interaction between services gets complicated fast.

Terraform Deployments

If your team uses Terraform to manage Azure infrastructure, be aware: Terraform does not yet support StandardV2 NAT Gateway or StandardV2 Public IP deployments. This is a documented limitation. If you try to deploy StandardV2 resources via Terraform, you'll get provider errors or the resources will silently deploy as the wrong SKU depending on your provider version. Your options are to use Azure CLI, ARM templates, Bicep, or the portal directly for StandardV2 resources, and manage the state manually until Terraform adds support. Track the relevant GitHub issue in the Azure Terraform provider repo for status updates.

Using Azure CLI for Deployment

When the portal gives you cryptic errors, the CLI often gives more useful output. Here's the full creation sequence via Azure CLI:

# Create a StandardV2 public IP
az network public-ip create \
  --resource-group MyRG \
  --name MyNatGwIP \
  --sku StandardV2 \
  --allocation-method Static \
  --version IPv4

# Create the StandardV2 NAT Gateway
az network nat gateway create \
  --resource-group MyRG \
  --name MyNatGateway \
  --public-ip-addresses MyNatGwIP \
  --sku StandardV2 \
  --idle-timeout 10

# Associate with your subnet
az network vnet subnet update \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --name MySubnet \
  --nat-gateway MyNatGateway

Virtual Network Failed State Recovery

If your VNet entered a failed state after attaching a StandardV2 NAT Gateway to an empty subnet (created before April 2025 without any VMs), the recovery sequence is:

# Step 1, Disassociate the NAT Gateway from the subnet
az network vnet subnet update \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --name MySubnet \
  --remove natGateway

# Step 2, Deploy a VM into that subnet (any minimal VM will do)
# Step 3, Reattach the NAT Gateway
az network vnet subnet update \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --name MySubnet \
  --nat-gateway MyNatGateway

Flow Logs for Deep Traffic Analysis (StandardV2 Only)

StandardV2 NAT Gateway supports flow logs, IP-based traffic records that show you exactly what's flowing outbound. If you're trying to trace which VMs are generating traffic, where it's going, and whether expected connections are making it through, enabling flow logs is the right move. In the portal, go to your NAT Gateway → Diagnostic settings → add a setting to send logs to a Log Analytics workspace or Storage Account. Query them in Log Analytics with:

AzureDiagnostics
| where ResourceType == "NATGATEWAYS"
| where Category == "NatGatewayFlowLogs"
| project TimeGenerated, srcIP_s, dstIP_s, dstPort_d, protocol_s
| order by TimeGenerated desc

Prevention & Best Practices

Once your Azure NAT Gateway is running correctly, a small amount of upfront planning saves you from most of the pain points outlined in this guide. Here's what I tell every team that asks me how to avoid NAT Gateway headaches going forward.

Plan your IP capacity before you need it. Each public IP on your NAT Gateway provides 64,512 SNAT ports. If you know your workload makes thousands of concurrent outbound connections, start with a public IP prefix instead of a single IP. A /28 prefix gives you 16 IPs out of the gate and scales automatically without any reconfiguration. The operational overhead of managing 16 individual IPs later versus a single prefix resource is significant, get the prefix in place early.

Choose your SKU with zone requirements in mind. Standard NAT Gateway is zonal, it lives in a single availability zone. If that zone goes down, your outbound connectivity goes with it. StandardV2 is zone-redundant across all zones in the region. For production workloads that require high availability, StandardV2 (where available in your region) is the better choice, just factor in the preview limitations before committing fully.

Separate your subnet topology by purpose. Don't mix delegated PaaS subnets with VM subnets if you need NAT Gateway everywhere. Use dedicated subnets for each PaaS service and a separate compute subnet with the NAT Gateway association. This gives you clean control over routing and avoids the delegation conflicts described in Step 4.

Monitor SNAT metrics proactively. Set up an Azure Monitor alert on the Dropped Packets metric for your NAT Gateway before traffic problems happen, not after. A reasonable alert threshold is anything above 0 for more than 5 minutes, dropped packets should not be a normal baseline condition.

Test idle timeout settings in staging first. The default 4-minute TCP idle timeout works for most workloads. But if you have long-lived connections, database connections, WebSocket sessions, or keep-alive HTTP connections, changing this value in production without testing first can cause unexpected disconnections. Simulate your connection patterns in a staging environment and measure actual idle connection behavior before touching the timeout value.

Frequently Asked Questions