Troubleshooting Lab: Verify IP Flow
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator receives a ticket reporting that VM vm-app01 cannot communicate with a database hosted on another VM (vm-db01) within the same VNet, on subnet 10.10.2.0/24. Both VMs are in different subnets within vnet-prod.
The administrator runs Verify IP flow and gets the following result:
Direction: Outbound
Protocol: TCP
Local IP: 10.10.1.4
Local port: *
Remote IP: 10.10.2.10
Remote port: 1433
Access: Deny
Rule name: Deny-CrossSubnet
NSG: nsg-app-subnet
Additional information collected during the investigation:
- The peering between
vnet-prodandvnet-hubis inConnectedstate - The VPN gateway is operational with an established connection
- The effective route for
10.10.2.0/24points toVnetLocal - The NSG
nsg-db-subnetwas updated yesterday by the database team
What is the root cause of the observed problem?
A. The peering between vnet-prod and vnet-hub is causing a route conflict, preventing traffic between subnets in the same VNet.
B. The NSG nsg-db-subnet was recently updated and is now blocking connections on port 1433.
C. The NSG nsg-app-subnet has a custom rule called Deny-CrossSubnet that is blocking outbound traffic to the database subnet.
D. The effective route pointing to VnetLocal is incorrect and traffic is being dropped before reaching the destination.
Scenario 2 — Side Impact
During a maintenance window, an administrator identifies that NSG nsg-web-subnet is blocking inbound traffic on port 443 from the internet. The responsible rule is DenyAllInbound, the default rule with lowest priority. To fix the issue, the administrator creates a new rule with the following settings:
Name: Allow-HTTPS-Inbound
Priority: 100
Source: Any
Source port: *
Destination: Any
Destination port: 443
Protocol: TCP
Action: Allow
The rule is successfully applied and HTTPS traffic begins flowing normally to VMs in the web-subnet.
What secondary consequence could this action cause?
A. Verify IP flow will start returning inconsistent results for inbound flows in this subnet, as the tool doesn't recognize rules with priority below 200.
B. Inbound HTTPS traffic will be allowed from any source, including unauthorized external IPs, expanding the subnet's attack surface.
C. The created rule automatically overwrites all other NSG rules with higher priority, changing the behavior of already permitted flows.
D. VMs added to the subnet in the future won't inherit the new rule, as NSG rules with priority below 200 don't apply to resources created after the rule.
Scenario 3 — Root Cause
The operations team reports that outbound traffic from vm-analytics01 to an external endpoint on the internet (20.40.10.5, port 443) is being blocked. The environment has the following characteristics:
- The VM is on subnet
10.30.1.0/24withinvnet-analytics - There's a UDR applied to the subnet that redirects
0.0.0.0/0to an NVA (Network Virtual Appliance) with IP10.0.0.4 - The NVA is operational with passthrough rules configured for port 443
- The administrator runs Verify IP flow and gets the result below
Direction: Outbound
Protocol: TCP
Local IP: 10.30.1.5
Local port: *
Remote IP: 20.40.10.5
Remote port: 443
Access: Allow
Rule name: AllowInternetOutBound
NSG: nsg-analytics-subnet
After the result, the team concludes that the NSG is not causing the blocking, but traffic still doesn't reach the destination.
What is the root cause of the observed problem?
A. Verify IP flow returned Allow incorrectly because the AllowInternetOutBound rule is the default rule and takes precedence over any blocking.
B. The NVA is dropping traffic internally, and Verify IP flow confirmed that the blocking occurs at this layer.
C. Verify IP flow only evaluates NSG rules and doesn't consider UDR or NVA behavior, so blocking may be occurring after the packet leaves the NSG.
D. The UDR is overriding the NSG's AllowInternetOutBound rule, and Verify IP flow cannot evaluate flows in subnets with UDR applied.
Scenario 4 — Action Decision
During an incident investigation, Verify IP flow confirms that inbound traffic on port 22 (SSH) is being denied to VM vm-jump01 by rule Block-SSH-All in NSG nsg-mgmt. The security team implemented this rule intentionally as part of the organization's hardening policy.
A senior engineer needs urgent access to vm-jump01 to apply a critical patch that is causing intermittent failures in 30% of application requests. The environment has:
- Azure Bastion deployed and functional in the VNet
- Active Change Management policy requiring approval for changes to production NSGs
- The engineer has Azure portal access with Contributor permissions on the subscription
What is the correct action to take at this moment?
A. Create a temporary rule in NSG nsg-mgmt with higher priority than Block-SSH-All, allowing SSH from the engineer's IP, and remove the rule after access.
B. Request emergency approval in the Change Management process to modify rule Block-SSH-All and permanently enable SSH access.
C. Use Azure Bastion to access vm-jump01 via Azure portal, without needing to modify the NSG or open port 22.
D. Access vm-jump01 directly through Azure portal using the Serial Console functionality, which doesn't depend on network connectivity.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The Verify IP flow result is direct and unambiguous: access was denied by rule Deny-CrossSubnet in NSG nsg-app-subnet. This is the NSG of the source subnet, and the rule name describes exactly the observed behavior. The root cause is the existence of a custom blocking rule in the NSG applied to the source VM's subnet.
The confirmatory clue is in the Rule name: Deny-CrossSubnet field and the NSG: nsg-app-subnet field. These two fields together unambiguously point to where the blocking occurs and which rule is responsible.
Irrelevant information: The state of peering with vnet-hub, VPN gateway status, and recent update to nsg-db-subnet are details inserted to divert the diagnosis. The effective route for 10.10.2.0/24 pointing to VnetLocal confirms that routing is correct and rules out alternative D.
The central reasoning error in the distractors is ignoring the tool's explicit result and seeking the cause in components that the output itself has already ruled out. The most dangerous distractor is B, which leads the administrator to investigate nsg-db-subnet when the blocking occurs before the packet even reaches the destination subnet.
Answer Key — Scenario 2
Answer: B
By configuring the source as Any and not restricting the source IP range, the administrator allowed any external IP address to establish HTTPS connections with any VM in the web-subnet. The immediate problem was solved, but the attack surface was unnecessarily expanded. The correct rule should restrict the source to known ranges, such as the Internet service tag with additional filters, or to a front-end load balancer IP.
Alternative A is false: Verify IP flow has no minimum priority restrictions for rule evaluation. Alternative C is false: NSG rules don't automatically overwrite other rules, they are evaluated by numerical priority. Alternative D is false: NSG rules apply to all subnet resources regardless of when they were created or the rule's priority.
The real side impact here isn't technical in the sense of breaking something, but introducing a security risk that may not be immediately perceived, making it the type of consequence most difficult to detect in production.
Answer Key — Scenario 3
Answer: C
Verify IP flow returned Allow and this result is valid: no NSG rule is blocking the flow. The tool works correctly within its scope, which is limited exclusively to evaluating NSG rules associated with the VM's network interface and subnet. It has no visibility into UDRs, NVAs, Azure Firewall, route tables, or any other filtering mechanism outside the NSG layer.
Traffic may be blocked at the NVA, by an internal firewall rule within it, by IP forwarding being disabled on the NVA's NIC, or by any other layer after the NSG. Verify IP flow cannot confirm or rule out any of these hypotheses.
Irrelevant information: The fact that the NVA is operational with configured rules is contextual information that doesn't invalidate the need for additional investigation at that layer.
The most dangerous distractor is B, which interprets the Allow result from Verify IP flow as confirmation that blocking is in the NVA. The tool doesn't make this assertion: it only reports that the NSG doesn't block. Concluding that blocking is in the NVA from this is a correct diagnostic inference, but not a tool confirmation.
Answer Key — Scenario 4
Answer: C
Azure Bastion solves the problem immediately without requiring any changes to network infrastructure or NSG. It provides RDP and SSH access via HTTPS through the Azure portal, making it unnecessary to open port 22 or modify any NSG rules. This is exactly the situation Bastion was designed for.
Alternative A violates the Change Management policy, even as a temporary change. The policy requires formal approval for any changes to production NSGs, and creating a rule without approval is a violation regardless of intent. Alternative B would solve the access but permanently and with the approval process, which doesn't meet the urgency and introduces an unnecessary security opening. Alternative D is technically feasible for diagnosing boot or operating system issues, but Serial Console doesn't offer full shell access equivalent to SSH for applying patches.
The reasoning error in distractors A and B is treating NSG modification as a mandatory path, ignoring that the environment already has an alternative access solution deployed and functional.
Troubleshooting Tree: Verify IP Flow
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (root) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
To use the tree when facing a real problem, start at the root node and answer each question based on what you observe in the environment. The first step is always to verify if there's an associated NSG before running the test. Then confirm that the Verify IP flow parameters are correct, especially the flow direction. Read the result and follow the corresponding path: if Deny, identify whether it's a default or custom rule; if Allow but the problem persists, proceed to investigate layers beyond the NSG. Each path ends with a named cause or a concrete action to execute.