Network Connectivity Issues¶

Symptoms¶

• Administrative or workload impact is visible to users or operators.
• The VM is deployed, but one part of the expected control plane or data path is failing.
• You need a fast way to narrow the problem before making a risky change.

flowchart TD
    A[Network Connectivity Issues] --> B[Confirm current symptom and blast radius]
    B --> C[Collect platform evidence first]
    C --> D[Collect guest or workload evidence]
    D --> E[Map findings to the most likely hypothesis]
    E --> F[Apply the smallest safe fix]
    F --> G[Validate recovery and prevention actions]

1. Summary¶

Use this playbook when a VM cannot reach internal or external endpoints, dependencies time out, or east-west communication breaks after NSG, NIC, route, or DNS changes.

NIC effective configuration, NSG and route review, DNS, accelerated networking, and dependency reachability.

2. Common Misreadings¶

3. Competing Hypotheses¶

4. What to Check First¶

1. Review VM instance view

   az vm get-instance-view             --resource-group $RG             --name $VM_NAME             --output json
   

2. Review boot diagnostics settings

   az vm boot-diagnostics get-boot-log             --resource-group $RG             --name $VM_NAME
   

3. Review NIC effective security rules

   az network nic list-effective-nsg             --resource-group $RG             --name $NIC_NAME             --output json
   

4. Review recent platform changes

   az monitor activity-log list             --resource-group $RG             --offset 24h             --output table
   

5. Evidence to Collect¶

5.1 KQL Queries¶

// NSG flow or denied connection signals
AzureDiagnostics
| where TimeGenerated > ago(6h)
| where Category has "NetworkSecurityGroup" or Category has "NetworkWatcher"
| project TimeGenerated, Category, Resource, OperationName, ResultDescription
| order by TimeGenerated desc

// Heartbeat freshness by subnet incident window
Heartbeat
| where TimeGenerated > ago(12h)
| summarize LastHeartbeat=max(TimeGenerated) by Computer, _ResourceId
| order by LastHeartbeat asc

5.2 CLI Investigation¶

az vm show     --resource-group $RG     --name $VM_NAME     --query "{powerState:powerState,vmSize:hardwareProfile.vmSize,priority:priority,provisioningState:provisioningState}"     --output json

az network nic show     --resource-group $RG     --name $NIC_NAME     --query "{ipConfigs:ipConfigurations[].privateIPAddress,acceleratedNetworking:enableAcceleratedNetworking,networkSecurityGroup:networkSecurityGroup.id}"     --output json

Interpretation:

• If the VM is not in a usable power state, fix power and boot issues before guest remediation.
• If the NIC or NSG binding is wrong, repair the control plane before changing guest settings.
• If accelerated networking or disk attachment changed after a resize, validate that the new size still supports the intended feature set.

6. Validation and Disproof by Hypothesis¶

Hypothesis 1: Configuration drift or recent change¶

Proves if: Evidence clearly shows the current state changed from the last healthy pattern in a way that explains the symptom.

Disproves if: Control-plane, guest, and capacity evidence all remain healthy and consistent with baseline.

Recommended validation steps:

1. Compare Azure Activity Log against the incident start time.
2. Compare current configuration with the approved landing zone pattern.
3. Review the most recent guest evidence or boot or connection output.
4. Re-test the original symptom after the smallest safe correction.

Hypothesis 2: Guest OS or service failure¶

Proves if: Evidence clearly shows the current state changed from the last healthy pattern in a way that explains the symptom.

Disproves if: Control-plane, guest, and capacity evidence all remain healthy and consistent with baseline.

Recommended validation steps:

1. Compare Azure Activity Log against the incident start time.
2. Compare current configuration with the approved landing zone pattern.
3. Review the most recent guest evidence or boot or connection output.
4. Re-test the original symptom after the smallest safe correction.

Hypothesis 3: Capacity limit or SKU mismatch¶

Proves if: Evidence clearly shows the current state changed from the last healthy pattern in a way that explains the symptom.

Disproves if: Control-plane, guest, and capacity evidence all remain healthy and consistent with baseline.

Recommended validation steps:

1. Compare Azure Activity Log against the incident start time.
2. Compare current configuration with the approved landing zone pattern.
3. Review the most recent guest evidence or boot or connection output.
4. Re-test the original symptom after the smallest safe correction.

Hypothesis 4: Security control blocking the expected path¶

Proves if: Evidence clearly shows the current state changed from the last healthy pattern in a way that explains the symptom.

Disproves if: Control-plane, guest, and capacity evidence all remain healthy and consistent with baseline.

Recommended validation steps:

1. Compare Azure Activity Log against the incident start time.
2. Compare current configuration with the approved landing zone pattern.
3. Review the most recent guest evidence or boot or connection output.
4. Re-test the original symptom after the smallest safe correction.

7. Likely Root Cause Patterns¶

8. Immediate Mitigations¶

1. Check effective NSGs, effective routes, DNS server configuration, and whether the NIC is on the expected subnet.
2. Validate accelerated networking if latency or packet processing CPU changed after a resize or NIC recreation.
3. Use Network Watcher connectivity tests and packet capture only after you have validated the control plane intent.

Step-by-step resolution:

1. Stabilize the VM or admin path without erasing forensic evidence.
2. Correct the control-plane configuration first when Azure intent is clearly wrong.
3. Apply guest-side repair only after confirming the platform path is healthy.
4. Re-run the original command, probe, or sign-in flow to verify recovery.
5. Record the exact evidence that proved the fix, not just that the symptom disappeared.

CLI commands commonly used during fixes:

az vm run-command invoke     --resource-group $RG     --name $VM_NAME     --command-id RunShellScript     --scripts "sudo systemctl status walinuxagent"

az vm restart     --resource-group $RG     --name $VM_NAME

9. Prevention¶

Prevention checklist¶

• [ ] Keep a documented healthy baseline for VM size, NIC, disk, and admin-path settings
• [ ] Alert on drift in critical VM security and connectivity controls
• [ ] Test boot diagnostics, Bastion, serial console, and backup restore before production go-live
• [ ] Review SKU feature compatibility before resize operations
• [ ] Capture post-incident evidence and turn it into a reusable guardrail

See Also¶

• Troubleshooting Index
• First 10 Minutes
• Decision Tree

Sources¶

• Troubleshoot Azure virtual machines
• Boot diagnostics for Azure virtual machines
• Connect to a VM with Azure Bastion
• Azure Managed Disks performance
• Accelerated networking overview