Map the Network Path to an Azure VM

• Define a network test by source, destination, protocol, port, direction, and UTC timestamp.
• Separate DNS, VM state, effective policy, effective route, guest firewall, listener, and application evidence.
• Mark each layer as supported, contradicted, or unknown without filling gaps with assumptions.
• Write an escalation-quality conclusion that identifies evidence and preserves change authority.

You should recognize IPv4 subnets, TCP ports, DNS A records, Windows listeners, network security groups, and effective routes. Review Investigating Azure VM Connectivity first if those layers are unfamiliar.

DNS and resource state

Attached network security groups

Relevant NSG rules

Priorities are evaluated within each NSG, with lower numbers processed first. For inbound traffic, both the destination subnet NSG and destination NIC NSG must permit the flow. A NIC-level allow does not override a deny at the subnet gate.

Effective security and route evidence

Guest and focused connection evidence

Known and unknown evidence

1. Write the exact source, destination, protocol, port, direction, and UTC timestamp.
2. Draw or restate the expected seven-layer path.
3. Mark every layer Supported, Contradicted, or Unknown.
4. State exactly what the DNS result proves.
5. State exactly what the VM power states prove.
6. Evaluate the effective route and next hop.
7. Evaluate source and destination NSG evidence without treating one rule as the whole policy.
8. Evaluate guest firewall and listener evidence.
9. Identify the earliest evidenced divergence.
10. List what remains unknown.
11. Write a concise finding that separates evidence from inference.
12. Recommend the accountable escalation owner without proposing an unauthorized change.

1. Why does a correct A record not establish TCP 443 reachability?
2. Which VM facts are platform or control-plane observations, and which guest facts are separate?
3. Why must both subnet and NIC NSG gates be evaluated?
4. Does the VirtualNetwork next hop prove that every policy layer permits the flow?
5. What does IP flow verify add beyond reading the NSG objects?
6. Why does a local listener not prove a successful application transaction?
7. Who should determine whether DenyAdminHttps reflects intended policy?

Why is DNS not the evidenced failure?

The A record resolves app.lab.example to the destination’s confirmed address, 10.20.2.4. DNS does not test Azure policy, routes, guest policy, a listener, or the HTTPS application.

Why is VM power not the evidenced failure?

Both VMs are reported Running, and their provisioning states are Succeeded. Those facts support platform state only; they do not establish guest or application health. Separate guest evidence is supplied.

Why is the effective route not the evidenced failure?

The source and return evidence show an active 10.20.0.0/16 system route with the expected VirtualNetwork next hop. That supports same-VNet route selection but does not bypass NSGs.

Why is the listener not the evidenced failure?

LAB-WEB-01 owns the expected address and a process listens on 0.0.0.0:443. The local test succeeds. This supports listener availability at the guest, not remote reachability or complete application health.

Why is the guest firewall not the evidenced failure?

The focused active rule allows inbound TCP 443 from 10.20.1.0/24. That supports the defined guest-policy requirement. It cannot override an Azure NSG deny.

Which effective rule blocks the defined flow?

DenyAdminHttps in nsg-lab-app, attached to destination subnet subnet-app, denies inbound TCP 443 from 10.20.1.0/24 to 10.20.2.4. Effective security and IP-flow evidence identify the same rule.

Why is the NSG the earliest demonstrated divergence?

Source state and policy, DNS, address placement, and the expected route are supported before traffic reaches the destination subnet gate. The destination subnet NSG contradicts the expected allow. Later guest evidence may be healthy, but the flow is already denied at that earlier layer.

What additional evidence would still be useful?

Confirm the NSG’s accountable owner, intended application-access policy, relevant change history, and whether a later issue appears after an authorized policy determination. Application health beyond the listener also remains unknown.

Why does this lab not authorize changing the rule?

A technically explanatory rule can still be intentional. Ownership, security intent, business need, approval, change control, rollback, and validation remain outside this evidence packet.

• The application is healthy beyond its listener.
• Every source can or cannot connect.
• The NSG rule is incorrect, should be deleted, or should be weakened.
• No other path issue exists after the demonstrated deny.
• Production change approval exists.
• The same result applies to another port, address, subnet, or timestamp.

• States and billing status of Azure Virtual Machines
• Azure network security groups overview
• Effective security rules overview
• Azure virtual network traffic routing
• IP flow verify overview
• Test-NetConnection
• Get-NetTCPConnection
• Get-NetFirewallRule