Troubleshooting Lab: Associate a route table with a subnet
Diagnostic Scenarios
Scenario 1 — Root Cause
The operations team reports that VMs in the app-subnet (10.0.2.0/24) cannot reach an on-premises server at address 192.168.10.5. The VNet has an active VPN Gateway and the IPsec tunnel is established, as confirmed by the network team. Other subnets in the same VNet can communicate normally with 192.168.10.5.
The team checks the effective routes of one of the affected VMs via portal and gets the following output:
Source State Address Prefix Next Hop Type Next Hop IP
-------- ------- ---------------- -------------------- -----------
User Active 0.0.0.0/0 VirtualAppliance 10.0.1.4
User Active 192.168.10.0/24 VirtualAppliance 10.0.1.4
System Invalid 192.168.0.0/16 VirtualNetworkGateway -
System Invalid 10.0.0.0/16 VirtualNetwork -
The NVA at IP 10.0.1.4 is operational and correctly processes HTTP and HTTPS traffic. The team reports that the NVA firewall allows all traffic on port 443. The system route to the gateway appears with Invalid state.
What is the root cause of the connectivity failure?
A) The NVA is blocking traffic to 192.168.10.5 because the port being used is not 443.
B) The UDR with prefix 192.168.10.0/24 in the route table associated with app-subnet is overriding the route learned by the VPN Gateway, and the NVA is not forwarding that traffic to the final destination.
C) The VPN tunnel is unstable and periodically brings down the system routes.
D) The route table should not be associated with app-subnet; it should be associated with GatewaySubnet.
Scenario 2 — Action Decision
The root cause of the problem has been identified: a route table associated with GatewaySubnet contains a UDR with prefix 0.0.0.0/0 and next hop Internet. This route is preventing the VPN Gateway from correctly processing return traffic from on-premises connections, causing intermittent failure in established sessions.
The environment is production. The gateway serves 12 subnets connected via site-to-site VPN with three branches. The security team confirms that the UDR was added by mistake during a maintenance window last week. The scheduled maintenance window for network changes is at 11 PM, and the current time is 2 PM.
What is the correct action to take at this time?
A) Immediately remove the route table from GatewaySubnet, as the impact is already occurring in production and the fix is reversible.
B) Wait for the maintenance window at 11 PM and remove the route table from GatewaySubnet at that time, as any change in production outside the window represents additional risk.
C) Remove only the 0.0.0.0/0 UDR from the route table within the maintenance window, keeping the route table associated with GatewaySubnet in case it contains other necessary routes.
D) Create a second UDR in the same route table with prefix 0.0.0.0/0 and next hop VirtualNetworkGateway to immediately override the incorrect route.
Scenario 3 — Root Cause
An engineer applies a new route table to subnet db-subnet (10.0.3.0/24) to redirect outbound traffic via NVA. Immediately after the association, VMs in db-subnet lose access to Azure Storage service accessed via Service Endpoint configured in the subnet.
The engineer checks the effective routes and notes the following:
Source State Address Prefix Next Hop Type Next Hop IP
-------- ------- ---------------------- ------------------ -----------
User Active 0.0.0.0/0 VirtualAppliance 10.0.1.4
System Active 10.0.0.0/16 VirtualNetwork -
System Active Storage.BrazilSouth VirtualAppliance 10.0.1.4
The engineer observes that the NVA has internet access and concludes that the problem must be the NVA's ability to resolve Storage DNS names. He opens a ticket for the DNS team. The Service Endpoint for Storage was active and working normally before the change.
What is the root cause of the problem?
A) The NVA's DNS cannot resolve Azure Storage FQDNs after traffic passes through the appliance.
B) The 0.0.0.0/0 UDR with next hop VirtualAppliance overrode the Service Endpoint system route, redirecting Storage traffic through the NVA instead of through the direct private endpoint path.
C) The Service Endpoint was automatically disassociated from db-subnet when the route table was linked.
D) The NVA does not support traffic destined to Azure service prefixes due to platform limitation.
Scenario 4 — Diagnostic Sequence
A VM in subnet web-subnet cannot reach an external destination 203.0.113.10. The environment has a route table associated with web-subnet with multiple UDRs. The engineer needs to diagnose whether the problem is routing, NVA configuration, or another nature.
The available investigation steps are:
- Step P: Check the VM NIC effective routes in Azure portal to identify which next hop is being applied for
203.0.113.10. - Step Q: Check if IP forwarding is enabled on the NVA NIC.
- Step R: Run a connectivity test with
Network Watcher > Connection Troubleshootfrom the VM to203.0.113.10. - Step S: Review the content of the route table associated with
web-subnetin the portal to list the configured UDRs. - Step T: Check the NSG flow logs applied to the NVA subnet to confirm if traffic is reaching the appliance.
What is the correct diagnostic sequence?
A) S -> P -> R -> T -> Q
B) P -> S -> Q -> T -> R
C) R -> P -> S -> T -> Q
D) S -> R -> P -> Q -> T
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the effective routes output: the system route 192.168.0.0/16 via VirtualNetworkGateway appears with Invalid state, which indicates that a UDR with a more specific prefix (192.168.10.0/24) is being preferred by Azure. Azure always applies the longest (most specific) route that covers the destination. Since 192.168.10.0/24 is more specific than 192.168.0.0/16, the UDR wins and traffic is sent to the NVA. If the NVA doesn't have a return route for 192.168.10.0/24 or isn't forwarding that traffic to the VPN gateway, the packet is dropped.
The information about port 443 is purposely irrelevant: the problem isn't port filtering but routing. Alternative A leads the reader to focus on this red herring. Alternative C is implausible because the tunnel status was confirmed as active. Alternative D confuses the correct direction of association: the route table is correctly in the traffic source subnet; the problem is its content, not the association location.
The most dangerous distractor is A: acting on the NVA firewall would consume time and not solve the real problem, while traffic would continue being routed incorrectly.
Answer Key — Scenario 2
Answer: C
The critical constraint in the scenario is that the route table may contain other routes besides the incorrect UDR. Removing the entire route table from GatewaySubnet (alternative A) may eliminate valid configurations and cause additional unplanned impact. Alternative B ignores that the impact is already occurring in production: waiting 9 hours with an active failure is unacceptable when surgical correction is viable.
Alternative D is technically wrong: creating a second 0.0.0.0/0 route with a different next hop generates routing ambiguity, as Azure doesn't support two UDRs with the same prefix in the same route table; the operation would be rejected or overwrite the previous one unpredictably.
The correct action is to specifically remove the problematic UDR (0.0.0.0/0 with next hop Internet) within the maintenance window, preserving other routes and following the environment's change management process. The existing impact doesn't justify ignoring the process, but justifies prioritizing surgical correction at the next available safe moment.
Answer Key — Scenario 3
Answer: B
Azure Storage Service Endpoint works by automatically injecting a system route with the service prefix (Storage.BrazilSouth) and next hop VirtualNetworkServiceEndpoint. This route ensures traffic goes directly to Microsoft's backbone without exiting through the internet. When a 0.0.0.0/0 UDR with next hop VirtualAppliance is added, Azure starts applying it to any destination not covered by a more specific route. The Service Endpoint prefix, which was previously the most specific route for Storage, can be overridden if the UDR has equal or higher specificity precedence, breaking the endpoint's direct path.
The effective routes output confirms this: Storage.BrazilSouth appears with next hop VirtualAppliance, indicating that the UDR replaced the Service Endpoint route.
The DNS information is the scenario's red herring and represents the most common reasoning error: the engineer confused connectivity symptoms with name resolution problems. Alternatives C and D are technically false: Service Endpoints are not disassociated by route tables, and Azure doesn't impose this limitation on the NVA by prefix type.
Answer Key — Scenario 4
Answer: A
The correct sequence is S -> P -> R -> T -> Q, which follows progressive diagnostic logic from broadest to most specific:
S reveals what's configured in the route table, providing the routing intention map. P reveals what Azure is effectively applying to the VM NIC, allowing comparison between intention and reality. R executes an end-to-end test that confirms whether traffic reaches the destination and where it fails. T validates whether traffic is effectively reaching the NVA, isolating whether the problem is before or after the appliance. Q checks NVA IP forwarding configuration only if traffic is reaching it, avoiding unnecessary NVA investigation.
Alternative B starts with effective routes without reviewing the route table, which can generate conclusions without the original intention context. Alternative C starts with the connectivity test, which is costly and generates less diagnostic context than checking routes first. Alternative D intercalates the connectivity test in the middle of routing analysis, breaking logical progression.
Troubleshooting Tree: Associate a route table with a subnet
Legend:
| Color | Meaning |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question (binary decision or by state) |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
When facing a real problem, start from the root node and answer each question based on what is observable in the environment: Azure portal, effective routes, Network Watcher logs. Follow the path corresponding to the answer until reaching an identified cause node, apply the corresponding recommended action, and return to the validation flow to confirm that expected behavior has been restored before closing the diagnosis.