Troubleshooting Lab: Implement Azure NAT Gateway
Diagnostic Scenarios
Scenario 1 — Root Cause
The operations team reports that VMs in a production subnet started failing to connect to external services on the internet. The problem began right after a maintenance window where three simultaneous changes were made: creation of a new NAT Gateway, association of a Public IP Prefix /28 to the NAT Gateway, and creation of a new UDR route table for the subnet.
The team confirms that the subnet NSG was not modified and that the VMs do not have individual Public IPs on their NICs.
The following test was executed from one of the affected VMs:
curl -s --max-time 10 https://ifconfig.me
# result: curl: (28) Operation timed out after 10000 milliseconds
The NAT Gateway verification in the portal shows Succeeded status and the Public IP Prefix appears as associated. The responsible engineer confirms that the NAT Gateway name is correct and that it was created in the same region as the VNet.
What is the root cause of the outbound connectivity failure?
A) The Public IP Prefix /28 is invalid for use with NAT Gateway; the minimum supported size is /31
B) The new UDR route table was associated with the subnet, but the default route 0.0.0.0/0 points to a next hop different from Internet, overriding the NAT Gateway behavior
C) The NAT Gateway was not associated with the subnet after its creation; the Succeeded status only indicates that the resource was provisioned
D) The subnet NSG is blocking outbound traffic because default outbound rules do not allow internet traffic when a NAT Gateway is present
Scenario 2 — Action Decision
The cause of the following problem has already been identified and is stated in the problem statement.
An e-commerce company operates a cluster of processing VMs in a subnet associated with a NAT Gateway with two Public IPs. In recent days, the monitoring team has recorded intermittent failures in new outbound connections to external payment APIs during processing peaks. Analysis of NAT Gateway metrics confirmed that failures occur exclusively when the SNAT Connection Count metric reaches the maximum limit of available ports on the two configured IPs.
The cause is SNAT port exhaustion. The environment is critical production with active SLA. Adding new individual public IPs to the NAT Gateway can be done without resource restart and without impact on already established SNAT connections.
The manager requests the fastest and safest solution to restore capacity without interrupting existing connections.
What is the correct action?
A) Remove the NAT Gateway from the subnet, associate an Azure Load Balancer with outbound rules and more public IPs, then reassociate the NAT Gateway
B) Immediately add individual public IPs to the existing NAT Gateway, increasing the pool of available SNAT ports without interrupting active connections
C) Restart the cluster VMs to free SNAT ports stuck in TIME_WAIT state before adding new IPs
D) Increase the NAT Gateway idle timeout to 120 minutes to reduce port turnover and free capacity for new connections
Scenario 3 — Root Cause
A security team configured a new isolated environment for integration testing. The topology uses a VNet with two subnets:
| Subnet | Purpose | Associated NAT Gateway |
|---|---|---|
| snet-app (10.2.1.0/24) | Application VMs | nat-test |
| snet-data (10.2.2.0/24) | Database VMs | none |
The NAT Gateway nat-test has a single Public IP: 20.80.45.12.
The team reports that VMs in snet-data are successfully making requests to the internet normally, which was not the expected behavior. The security team states that no Public IP was associated with the NICs of these VMs.
The engineer verifies and confirms that the NSG for snet-data has an explicit outbound rule with priority 100 allowing all traffic to the Internet service tag. The snet-data subnet has no associated UDR.
# Executed on VM from snet-data:
curl -s https://ifconfig.me
# response: 52.191.77.230
What is the root cause of the unexpected behavior?
A) The NAT Gateway nat-test is being automatically shared with snet-data because both subnets belong to the same VNet
B) The NSG rule with priority 100 allowing outbound traffic to Internet is overriding the expected isolation and forcing direct routing to the internet
C) VMs in snet-data are using the VNet system default routing, which includes an implicit internet route, and without NAT Gateway or explicit outbound blocking, traffic exits through the public IP of the underlying host network interface
D) The IP 52.191.77.230 belongs to NAT Gateway nat-test, indicating it was improperly associated with snet-data during configuration
Scenario 4 — Diagnostic Sequence
An engineer receives an alert: VMs in a subnet with configured NAT Gateway are failing to connect to external endpoints. The environment has been working normally for weeks.
The following investigation steps are available, but out of order:
- Check NAT Gateway metrics, especially SNAT Connection Count and Dropped Packets, to identify signs of exhaustion or forwarding failure
- Confirm if the NAT Gateway is associated with the affected subnet by accessing subnet settings in the portal or via CLI
- Verify if there were recent changes to UDRs associated with the subnet that could be diverting outbound traffic
- Execute a simple connectivity test from one of the affected VMs to confirm scope and nature of the failure
- Check the NAT Gateway provisioning status and confirm if the associated Public IP or Prefix is still present and active
What is the most efficient and logically correct diagnostic sequence?
A) 2 -> 5 -> 3 -> 1 -> 4
B) 4 -> 2 -> 5 -> 3 -> 1
C) 1 -> 4 -> 2 -> 5 -> 3
D) 5 -> 2 -> 4 -> 1 -> 3
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The critical point in the scenario is the phrase "creation of a new UDR route table for the subnet". The NAT Gateway provides outbound connectivity, but it needs to be associated with the subnet to take effect. The Succeeded status only confirms that the resource was successfully provisioned in Azure, not that it was linked to any specific subnet.
The decisive clue is that the statement describes three distinct actions performed during maintenance, but does not explicitly mention the association of the NAT Gateway to the subnet as an executed step. This omission is the root cause.
Alternative B is the most dangerous distractor: a UDR with wrong next hop can indeed override the NAT Gateway, but the statement doesn't describe the content of the created route, only that it was created. Acting based on this hypothesis without validating the NAT Gateway association would be a diagnostic sequence error. Alternative A is factually wrong: NAT Gateway supports /28 prefixes normally. Alternative D is wrong because default NSG outbound rules allow outbound internet traffic by default, and NAT Gateway doesn't change this behavior.
Answer Key — Scenario 2
Answer: B
The cause is stated: SNAT port exhaustion. The statement also provides critical information that adding public IPs to the NAT Gateway can be done without restart and without impact on existing connections. This eliminates any justification for disruptive actions.
Alternative B is the only one that meets all three scenario constraints: solves the real cause (lack of SNAT ports), is fast, and is safe for production with active SLA.
Alternative D represents the most common mistake: increasing idle timeout reduces port turnover for existing sessions, but doesn't increase the total number of available ports and may even worsen the problem by keeping ports occupied longer in idle sessions. Alternative C adds unavailability to the problem without increasing SNAT capacity. Alternative A is technically valid as an architectural solution, but is disruptive, time-consuming, and unnecessary given the context.
Answer Key — Scenario 3
Answer: C
The root cause is VNet system default routing. Every VNet in Azure includes an implicit system route for 0.0.0.0/0 with Internet next hop. When a subnet has no associated NAT Gateway, no UDR overriding this route, and VMs don't have Public IPs on NICs, Azure still allows outbound traffic to occur using the public IP of the underlying host (implicit platform SNAT). This behavior is the opposite of what many teams expect: the absence of NAT Gateway doesn't block outbound traffic, it just removes control over the IP used.
The irrelevant information in the statement is the NSG rule with priority 100. It allows outbound traffic, but NSG was never the relevant blocking mechanism here; the problem is architectural. The reader who focused on NSG was purposely misled.
Alternative A is wrong: NAT Gateway is not automatically shared between subnets; it needs to be explicitly associated with each one. Alternative D can be refuted by verifying that IP 52.191.77.230 is not 20.80.45.12, meaning it's not the IP of NAT Gateway nat-test. Acting based on alternative D would lead the engineer to look for a configuration problem that doesn't exist.
Answer Key — Scenario 4
Answer: B
The correct sequence is 4 -> 2 -> 5 -> 3 -> 1, which follows progressive diagnostic logic from simplest and most observable to most specific and technical.
Step 4 confirms the real scope of the failure before any infrastructure investigation, avoiding diagnosis of a problem that might be localized or transient. Step 2 verifies NAT Gateway association with the subnet, which is the most basic functional requirement. Step 5 validates the resource state and its associated IPs. Step 3 investigates recent UDR changes, which could silently divert outbound traffic. Step 1 analyzes metrics to identify exhaustion or forwarding failure, being the most specific step that requires context from previous ones to be correctly interpreted.
Alternative C makes the mistake of starting with metrics before confirming if the problem is real and what its scope is. Alternative A starts with association without confirming the symptom, which wastes time if the problem is intermittent. Alternative D starts with resource status, skipping symptom confirmation, and then goes to association before testing connectivity.
Troubleshooting Tree: Implement Azure NAT Gateway
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom, diagnostic entry point |
| Blue | Closed and verifiable diagnostic question |
| Orange | Intermediate verification or validation |
| Red | Identified cause |
| Green | Recommended action or resolution |
To use this tree when facing a real problem, start with the root node that describes the observed symptom and answer each diagnostic question based on what you can directly verify in the portal, CLI, or within the VM. Follow the path corresponding to your answer until you reach an identified cause node. From the cause, the associated recommended action indicates the precise correction to apply. Never skip intermediate questions: the order of verifications prevents corrective actions applied to the wrong hypothesis.