Troubleshoot an Azure Network

Diagnose and repair an SSH block between private Azure virtual machines.

Introduction

30 Second Summary

An online system can look healthy while one hidden rule silently blocks two parts from communicating. When that happens, the useful skill is proving exactly where the connection failed.

In this project, you will build a private Azure Virtual Network with two Linux virtual machines in separate subnets. You will use Azure Network Watcher to diagnose a deliberate SSH failure and restore the blocked path.

What You'll Build

You'll watch Azure flag a private SSH path as unreachable, identify the exact security rule behind it, restore the connection, and show the complete incident in a public GitHub report.

By the end of this project, you'll have:

A private network path between frontend and backend machines in separate subnets. Both machines use private IP addressing without public exposure.
A reproducible SSH failure that Azure reports as unreachable after a destination-side Network Security Group blocks the path.
A public incident report that tells the complete troubleshooting story. Readers can see the network design, root cause, repair, and proof of recovery.
Secret Mission: Move the failure to the frontend side. Use Network Watcher to prove that an outbound rule caused the source-side block.

Do I need any experience before starting?

Basic familiarity with IP addressing, CIDR notation, TCP ports, and subnetting helps you focus on the Azure troubleshooting workflow. You need an active Azure subscription with permissions equivalent to Network Contributor for network operations plus a GitHub account.

You'll also need a Windows device with the latest Microsoft Edge and Snipping Tool.

Before We Start

Before the hands-on work begins, this is your moment to define the purpose of your Azure network troubleshooting lab. Connecting the lab to your career or certification goal gives every diagnosis a clear reason.

Set Up the Lab Workspace

Cloud networking work can stall before the first subnet exists. Browser issues can interrupt the portal at the worst moment.

This step verifies your Microsoft Edge access to the Azure portal.

GitHub stores your incident report. Snipping Tool captures the evidence that supports it.

In this step, get ready to:

Verify Azure subscription access through the latest Microsoft Edge.
Create a public GitHub repository with a rendered README.
Test the Snipping Tool capture workflow.

Verify Microsoft Edge and Azure access

The Azure portal supports the latest Microsoft Edge. Checking for updates now removes a browser problem before you start creating resources.

Select Start on the Windows taskbar.
Enter Microsoft Edge in Windows search.
Select Microsoft Edge from the search results.
Enter edge://settings/help in the address bar.
Press Enter to start the update check.
Complete any update offered on the page.
Restart Microsoft Edge if the page requests it.
Confirm the update page reports that Microsoft Edge is current.

Your browser is current. It is ready to support the Azure work ahead.

Your subscription status controls whether the lab can proceed. This check only reviews access.

Visit the Azure portal in Microsoft Edge.
Sign in with the account connected to your intended subscription.
Enter Subscriptions in the portal search field.
Select Subscriptions from the search results.
Select the subscription you intend to use for this lab.

You are now viewing the subscription that will contain the lab resources.

Confirm the Overview page reports the subscription status as active.
Select Access control (IAM) from the subscription menu.
Select View my access.
Confirm your listed role assignments cover network operations at this subscription scope.
Confirm your access permits creation of the lab resources.
Confirm your access permits deletion of the lab resources.

What access does this lab need?

The lab needs permission for network operations at the intended subscription scope. It also needs permission to create the resources used later.

Deletion permission matters because the final cleanup removes the resource group. Confirming both capabilities prevents an incomplete lab.

That access check clears the biggest setup risk. Your intended subscription is active with the permissions this lab needs.

Subscription access missing?

An inactive subscription can block every later deployment. A role assignment at the wrong scope can also prevent resource creation.

Ask your subscription administrator to confirm that the intended subscription is active.
Ask your subscription administrator to grant the required network permissions at the subscription scope.
Ask your subscription administrator to confirm that you can create and delete the lab resources.

Help me interpret my Azure access.

Create the public GitHub repository

The repository gives your future incident report a public home. Its README becomes the page where your evidence appears.

Keep public evidence safe

Public repositories can be viewed by anyone. Sensitive account information must stay out of this repository.

Open a new tab in Microsoft Edge.
Visit GitHub.
Sign in to your GitHub account.
Select New repository.
Enter azure-network-troubleshooting-lab as the repository name.
Choose Public visibility.
Turn on Add README.
Select Create repository.

Your repository now has a front page. The rendered README.md gives your incident report somewhere to grow.

Refresh the repository front page.
Confirm the page still renders README.md.

Your evidence home is live. The public repository is ready for the network report you will publish later.

README not rendering?

Confirm that the repository name is azure-network-troubleshooting-lab. Confirm that you enabled Add README during creation.

Help me fix the missing README.

Test your screenshot workflow

Screenshots provide the visible proof in your future incident report. A harmless test confirms that you can capture evidence before the real diagnostic results appear.

Press Windows logo key + Shift + S to open the capture overlay.
Drag over a harmless empty area of your desktop.
Select the capture preview to open it in Snipping Tool.
Press Ctrl+S to save the test capture.
Choose your Desktop as the save location.
Press Enter to keep the default filename.
Double-click the saved image on your Desktop.

The image opens successfully. That proves your capture can be saved for later evidence.

Close the image viewer.
Select the saved test image on your Desktop.
Press Delete to remove it.
Confirm the test image no longer appears on your Desktop.

Your screenshot workflow works from capture through cleanup. The harmless test image is gone.

Capture not saving or opening?

Confirm that you selected the capture preview before saving. Save the image to your Desktop so it is easy to find.

Help me troubleshoot Snipping Tool.

Before the final check, do you expect every workspace check to hold? Keep your prediction in mind.

Switch back to the Azure portal tab in Microsoft Edge.
Confirm the intended subscription still reports an active status.
Switch to the GitHub repository tab.
Refresh the repository front page.
Confirm README.md still renders.
Return to your Windows Desktop.
Confirm the harmless test image remains deleted.

What should I see?

Microsoft Edge remains current with the Azure portal open.
The intended Azure subscription reports an active status.
The public GitHub repository renders README.md on its front page.
The saved Snipping Tool test image no longer appears on your Desktop.

Your workspace is ready for the lab. Next, you will build the segmented private network that creates the troubleshooting path.

Build the Segmented Network

The workspace checks are complete. Your Azure portal session is ready for the lab resources.

An Azure Virtual Network connects machines across separate subnets by default. This working private path gives the next step a meaningful baseline to break.

In this step, get ready to:

Create the lab resource group.
Segment the virtual network into frontend and backend subnets.
Deploy one private Linux machine into each subnet.

Create the resource group and virtual network

A resource group keeps resources with the same lifecycle together. You can remove this entire lab through that single container later.

Why build this in the portal?

The Azure portal shows each resource relationship as you build it. That visibility keeps this lab focused on network reasoning.

Bicep is useful for repeatable deployments. It fits a follow-on project after you can explain this topology.

Switch back to the Azure portal in Microsoft Edge.
Enter Resource groups in the portal search box.
Select Resource groups from the search results.
Select + Create.

Confirm the intended subscription under Subscription.
Enter rg-aznet-troubleshoot under Resource group.

The project details now point to the subscription you verified earlier. The resource group name identifies this lab as one cleanup unit.

Choose an Azure region under Region.
Record the selected region here: your selected Azure region.

The form now shows the subscription, resource group name, and region for the lab.

Select Review + create.
Select Create after validation passes.

Azure creates the resource group within a few seconds. You now have a container for the network and both machines.

Select Refresh from the top menu.
Open rg-aznet-troubleshoot from the resource group list.

The empty resource list confirms that the resource group exists. The next resource you add is the network.

Enter Virtual networks in the portal search box.
Select Virtual networks from the search results.
Select + Create.

Confirm the intended subscription under Subscription.
Select rg-aznet-troubleshoot under Resource group.

The VNet is now scoped to the lab resource group in the intended subscription.

Enter vnet-troubleshoot under Name.
Choose your selected Azure region under Region.

The instance details now place the VNet beside the other lab resources.

Select Next to proceed to the Security tab.
Select Next to proceed to the IP Addresses tab.
Set IPv4 Address space to 10.0.0.0/16.
Select the default subnet in the Subnets section.

The CIDR range now gives this VNet a private address space from 10.0.0.0 through 10.0.255.255.

Change Name to snet-frontend.
Set Starting address to 10.0.1.0.

The subnet editor now identifies the frontend segment at the start of the 10.0.1.0 range.

Set Subnet size to /24.
Select Save.

The subnet list now shows snet-frontend with the range 10.0.1.0/24.

Select + Add a subnet.
Enter snet-backend under Name.
Set Starting address to 10.0.2.0.

The backend segment now begins at 10.0.2.0. This keeps its addresses separate from the frontend range.

Set Subnet size to /24.
Select Add.

The subnet list now contains two non-overlapping ranges inside the VNet address space.

Select Review + create.
Select Create after validation passes.

Azure now provisions the VNet with both subnets. The deployment page confirms when the resource is ready.

Select Go to resource after the deployment completes.
Select Subnets from the VNet menu.

You should see snet-frontend at 10.0.1.0/24 and snet-backend at 10.0.2.0/24.

Why does this start as a working path?

Azure routes traffic between subnets in the same VNet by default. Separate subnets organize the machines without blocking communication on their own.

This working baseline makes the security failure in the next step observable. You will know that the new rule caused the change.

VNet validation failed?

Check that both subnet ranges sit inside 10.0.0.0/16. Confirm that the two /24 ranges do not overlap.

Review the exact address fields with help diagnosing my Azure VNet validation problem.

Deploy the private virtual machines

Two Azure Virtual Machines create a real source and destination for the troubleshooting path. Each network interface attaches to one of the subnets you just verified.

These VMs can incur compute and disk charges once deployed. The review page keeps the current estimate visible before Azure creates each machine.

Enter Virtual machines in the portal search box.
Select Virtual machines from the search results.
Select Create.
Select Azure virtual machine.

Confirm the intended subscription under Subscription.
Select rg-aznet-troubleshoot under Resource group.

The frontend VM is now scoped to the same subscription and resource group as the network.

Enter vm-frontend under Virtual machine name.
Choose your selected Azure region under Region.

The instance details now place vm-frontend in the same region as vnet-troubleshoot.

Select Ubuntu Server 22.04 LTS - x64 Gen2 under Image.

The selected image gives the VM the Linux operating system used throughout this lab.

Select Standard_B2ats_v2 under Size when it is available.
Choose Standard_B1s only when the primary size is unavailable and the portal marks this fallback as available within your budget.

The size field now shows the burstable VM option supported by your subscription and selected region.

Select SSH public key under Authentication type.
Enter azureuser under Username.

The administrator account now uses key-based authentication. Azure disables password authentication for this Linux VM.

Select Generate new key pair under SSH public key source.
Keep the generated value under Key pair name.
Record the displayed key pair name here: your generated SSH key name.

The public half of this key authenticates both lab machines. The private half stays on your Windows device.

Select None under Public inbound ports.
Select Next: Disks.
Select Standard SSD under OS disk type.

The VM now has no public inbound-port rule. Its managed OS disk uses the storage tier selected for this dev and test lab.

Select Next: Networking.
Select vnet-troubleshoot under Virtual network.
Select snet-frontend under Subnet.

The network interface now belongs to the frontend subnet inside vnet-troubleshoot.

Select None under Public IP.
Select None under Network interface (NIC) network security group.

The networking summary now shows a private-only VM in snet-frontend with no NIC-level security group.

Select Review + create.

Azure validates the VM configuration on this page. The next selection opens the private-key download prompt before deployment.

Confirm the displayed estimate fits your lab budget.
Select Create.

The downloaded private key grants access to the administrator account. Keep it private because anyone with that file can attempt to authenticate as azureuser.

Select Download private key and create resource when the key prompt opens.
Save the downloaded private key in a secure local folder.

The deployment often takes several minutes. A quiet status page is normal while Azure provisions the VM, network interface, and disk.

Wait for the deployment to complete.
Select Go to resource.

The Overview page should report Running. It should show no public IP address.

Confirm the private IP address begins with 10.0.1..
Record the frontend address here: your frontend VM private IP.

The frontend machine is live inside its private subnet. That is the first half of your test path working.

Frontend deployment failed?

A regional size or quota issue can stop the deployment. Return to the VM configuration and use only the approved fallback when its displayed estimate fits your budget.

Share the non-sensitive deployment details with help diagnosing my frontend VM deployment.

Enter Virtual machines in the portal search box.
Select Virtual machines from the search results.
Select Create.
Select Azure virtual machine.

Confirm the intended subscription under Subscription.
Select rg-aznet-troubleshoot under Resource group.

The backend VM is now scoped to the same subscription and resource group as the frontend VM.

Enter vm-backend under Virtual machine name.
Choose your selected Azure region under Region.

The instance details now place vm-backend beside the frontend machine and VNet.

Select Ubuntu Server 22.04 LTS - x64 Gen2 under Image.

Both machines now use the same operating-system image. This keeps the network path as the variable you investigate.

Select Standard_B2ats_v2 under Size when it is available.
Choose Standard_B1s only when the primary size is unavailable and the portal marks this fallback as available within your budget.

The backend size now matches an approved option for the selected subscription and region.

Select SSH public key under Authentication type.
Enter azureuser under Username.

The backend administrator account now uses the same authentication method as the frontend account.

Select Use a key stored in Azure under SSH public key source.
Select your generated SSH key name from the available key list.

Both VMs now trust the same public key. The private key remains on your device.

Select None under Public inbound ports.
Select Next: Disks.
Select Standard SSD under OS disk type.

The backend VM now has the same disk tier and public inbound-port posture as the frontend VM.

Select Next: Networking.
Select vnet-troubleshoot under Virtual network.
Select snet-backend under Subnet.

The backend network interface now sits in the second subnet of vnet-troubleshoot.

Select None under Public IP.
Select None under Network interface (NIC) network security group.

The networking summary now shows a private-only VM in snet-backend with no NIC-level security group.

Select Review + create.

The review page should show the backend subnet and no public IP. It also shows the current deployment estimate.

Confirm the displayed estimate fits your lab budget.
Select Create.

This deployment can also take several minutes. Azure is provisioning the second VM, network interface, and managed disk.

Wait for the deployment to complete.
Select Go to resource.

The Overview page should report Running. It should show no public IP address.

Confirm the private IP address begins with 10.0.2..
Record the backend address here: your backend VM private IP.

Both ends of the private path are now running. Each machine has an address from its assigned subnet.

Backend deployment failed?

Confirm that the backend uses the same region as the VNet. Check that snet-backend is selected under the networking settings.

Review the non-sensitive configuration with help diagnosing my backend VM deployment.

Verify the private topology

Before you check the finished topology, do you expect either VM to show a public IP address?

Return to rg-aznet-troubleshoot in the Azure portal.
Open vm-frontend from the resource list.
Select Overview.

You should see Running with no public IP address. The private IP should match your frontend VM private IP.

Return to rg-aznet-troubleshoot.
Open vm-backend from the resource list.
Select Overview.

You should see Running with no public IP address. The private IP should match your backend VM private IP.

Enter Virtual networks in the portal search box.
Select Virtual networks from the search results.
Open vnet-troubleshoot.
Select Subnets.

You should see snet-frontend at 10.0.1.0/24 and snet-backend at 10.0.2.0/24 inside 10.0.0.0/16.

Your private baseline is live across two Azure subnets. Next, you will introduce a narrow SSH block and watch the working path become unreachable.

Create the SSH Failure

Your two private Linux virtual machines are running in separate subnets. Their private addresses give you a realistic source-to-destination path.

An Azure Virtual Network routes between its subnets by default. This step adds destination-side control through a network security group rule.

You will test SSH traffic with Network Watcher. The result gives you evidence for the diagnosis that follows.

In this step, get ready to:

Protect snet-backend with nsg-backend.
Define an inbound deny rule for TCP port 22.
Capture the failed private SSH path with Connection troubleshoot.

Create and associate the backend NSG

A subnet association makes an NSG evaluate traffic entering that subnet. Associating nsg-backend with snet-backend places the security decision on the destination side.

Switch back to the Azure portal in Microsoft Edge.
Enter Network security groups in the portal search bar.

The search results should include the Azure service used to control network traffic.

Select Network security groups from the search results.
Select + Create.

The creation form opens with settings for the new NSG.

Choose rg-aznet-troubleshoot as the resource group.
Enter nsg-backend as the NSG name.

The NSG now has a project-specific name inside your existing lab resource group.

Choose the same Azure region as vnet-troubleshoot.
Select Review + create.

The review page should validate the NSG configuration.

Select Create after validation passes.

Good progress. The deployment confirmation means nsg-backend now exists in your lab.

Enter nsg-backend in the portal search bar.
Select nsg-backend from the search results.

The NSG page opens with its configuration menu.

Select Subnets from the NSG menu.
Select + Associate.

The association form asks which virtual network and subnet this NSG should protect.

Choose vnet-troubleshoot as the virtual network.
Choose snet-backend as the subnet.

The selected values place the NSG on the backend subnet.

Select OK to create the association.

You should see snet-backend in the NSG subnet list. This confirms that inbound traffic to the backend subnet now passes through nsg-backend.

Association not listed?

Confirm that nsg-backend uses the same Azure region as vnet-troubleshoot.
Return to the Subnets view after the association finishes.
Ask for help with the missing subnet association.

Add the inbound deny rule

An inbound rule describes the source traffic that reaches the backend subnet. Its action determines whether Azure allows that matching flow to continue.

Select Inbound security rules from the nsg-backend menu.
Select Add above the rules table.

The rule form opens with fields for the traffic source and destination.

Set Source to IP Addresses.
Enter 10.0.1.0/24 in Source IP addresses/CIDR ranges.

The source now covers every private address in snet-frontend.

Enter * in Source port ranges.
Set Destination to Any.

The rule accepts any source port while applying to destinations protected by this NSG.

Enter 22 in Destination port ranges.
Set Protocol to TCP.

These values identify SSH traffic arriving over TCP port 22.

Set Action to Deny.
Enter 100 in Priority.

Priority 100 gives this rule the earliest permitted custom priority.

Enter Deny-SSH-From-Frontend in Name.
Select Add to save the rule.

You should see Deny-SSH-From-Frontend in the inbound rules table with priority 100 and action Deny.

Rule missing from the table?

Confirm that every required field contains a value.
Confirm that no other custom rule uses priority 100.
Ask for help with the inbound rule.

Test the private SSH path

Connection troubleshoot tests the path between Azure resources without requiring a public IP address. You will use the frontend VM as the source and the backend VM as the destination.

Enter Network Watcher in the portal search bar.
Select Network Watcher from the search results.

The Network Watcher page lists diagnostic tools for the selected Azure region.

Select Connection troubleshoot under Network diagnostic tools.
Choose vm-frontend as the source virtual machine.

The diagnostic now starts from the frontend side of your private network path.

Choose vm-backend as the destination virtual machine.
Select IPv4 as the IP version.

The source and destination now match the private path protected by your backend NSG.

Select TCP as the protocol.
Enter 22 as the destination port.

Before you run the diagnostic, do you think Azure will report this private SSH path as reachable or unreachable?

Select Run diagnostic tests.

You will see Unreachable. You have reproduced the designed SSH failure on the destination side.

Still seeing Reachable?

Confirm that nsg-backend is associated with snet-backend.
Confirm that Deny-SSH-From-Frontend shows source 10.0.1.0/24 and destination port 22.
Rerun the diagnostic after the NSG update finishes.
Ask for help with the unexpected Reachable result.

Use the Snipping Tool from earlier to capture the Unreachable result.
Crop the capture so unrelated account details stay outside the image.
Save the capture in a location you can find later.
Leave Deny-SSH-From-Frontend unchanged.

Why does this rule win?

Azure evaluates lower priority numbers first. Your custom rule at priority 100 is evaluated before the default AllowVNetInBound rule at priority 65000.

The first matching rule stops further evaluation. The backend subnet therefore denies this SSH flow.

Your repeatable SSH failure is ready for investigation. Next, you will use IP flow verify to identify the exact rule responsible for the blocked path.

Diagnose and Repair the Path

You reproduced an SSH failure between two private subnets. The captured Unreachable result gives you a concrete incident to investigate.

That status is the symptom. Azure Network Watcher can name the responsible security rule.

You will test the rule decision before changing it. You will then repeat both diagnostics to prove the path recovered.

In this step, get ready to:

Identify the security rule denying the inbound SSH flow.
Repair the backend rule without widening its scope.
Prove the recovery with repeat diagnostics.

Identify the blocking rule

IP flow verify evaluates one traffic flow against the effective security rules. It also names the rule responsible for the decision.

Select IP flow verify under Network diagnostic tools in Network Watcher from earlier.

How Does This Test Map the Flow?

The diagnostic models an inbound TCP packet at vm-backend. The backend VM is the local endpoint.

The recorded frontend private IP address supplies the remote address. Remote port 60000 represents the source-side ephemeral port.

Select vm-backend in the VM field.
Set Direction to Inbound.
Set Protocol to TCP.
Enter 22 in the Local port field.
Enter the recorded vm-frontend private IP address in the Remote IP field.
Enter 60000 in the Remote port field.
Predict which security rule Azure will match for this flow.
Select Check.

You should see Access denied. The result should name Deny-SSH-From-Frontend as the responsible security rule.

You have tied the failed path to one specific rule. That is the evidence needed for a justified repair.

Rule Not Showing as the Match?

Verify that Remote IP contains the recorded private IP address for vm-frontend.
Confirm that Deny-SSH-From-Frontend still has Action set to Deny.

Help me diagnose why IP flow verify is not matching the expected backend rule.

Use Snipping Tool to capture only the Access denied result area with its matched Deny-SSH-From-Frontend rule.

Make the narrow repair

The matched backend network security group rule already describes the intended SSH flow. Changing only its action preserves the narrow source range.

Return to nsg-backend in the Azure portal from earlier.
Select Inbound security rules in the left menu.
Select Deny-SSH-From-Frontend.
Set Action to Allow.
Select Save.

The rule row should now show Allow for Deny-SSH-From-Frontend.

What Stayed Protected?

The source range remains 10.0.1.0/24.
The protocol remains TCP.
The destination port remains 22.
The priority remains 100.

Rule Still Showing Deny?

Verify that you edited Deny-SSH-From-Frontend inside nsg-backend.
Confirm that the rule row still shows priority 100.

Help me find why the backend NSG rule still shows Deny after the change.

Prove the path recovered

A repaired rule needs two forms of proof. The first check confirms the rule-level decision.

Use the same inbound test on vm-backend. Keep local port 22 with remote port 60000.

Return to IP flow verify in Network Watcher.
Repeat the inbound test using the same values from your first check.
Predict whether the repaired rule will now allow the flow.
Select Check.

Azure should now report Access allowed for the same inbound flow. The rule-level decision has recovered.

Connection troubleshoot checks the complete path from the source VM to the destination VM. This final diagnostic proves whether TCP traffic can cross the network.

Return to Connection troubleshoot in Network Watcher.
Select vm-frontend as the source VM.
Select vm-backend as the destination VM.
Select IPv4.
Select TCP.
Enter 22 as the destination port.
Predict whether the end-to-end result will agree with IP flow verify.
Select Run diagnostic tests.

You should now see Reachable for the path from vm-frontend to vm-backend over TCP port 22.

That closes the incident loop. Azure now confirms the path recovered after the targeted rule change.

Still Seeing Unreachable?

Confirm that Deny-SSH-From-Frontend shows Allow in nsg-backend.
Verify that the source VM is vm-frontend.
Verify that the destination VM is vm-backend.
Confirm that the destination port is 22.

Help me diagnose why the end-to-end test still reports Unreachable.

Use Snipping Tool from earlier to capture only the Reachable Connection troubleshoot result area.

Your incident now has a complete trail from symptom to cause to recovery. Next, you will turn that evidence into a concise incident report.

Publish the Incident Report

Your private path through Azure Virtual Network is reachable again. Recruiters and interviewers need to see how you isolated the rule that blocked it.

In this step, you'll turn the failure-to-recovery story into a concise public incident report on GitHub. The report follows the path from design to diagnosis. It then records your repair plus cleanup decision.

In this step, get ready to:

Prepare two redacted evidence images.
Upload the evidence images to GitHub.
Publish the incident report without exposing secrets.

Prepare the evidence images

Incident screenshots work best as a matched pair. Snipping Tool lets you isolate the diagnostic result from the rest of the portal.

Keep public evidence safe

Your report is public. A tight crop keeps account details outside the evidence.

Subscription IDs.
Usernames.
Key material.
Unrelated account details.

Switch back to the captured Unreachable result from your earlier test.
Press Windows logo key + Shift + S to start a new capture.
Drag over the diagnostic result to capture only the evidence area.
Save the capture to your Desktop as blocked-path.png.
Switch to the captured Reachable result from your repaired path.
Press Windows logo key + Shift + S to start the second capture.
Drag over the diagnostic result to capture only the evidence area.
Save the capture to your Desktop as restored-path.png.

You now have a matched before-and-after pair. Each image carries one clear part of the incident story.

Open blocked-path.png from your Desktop.
Inspect the failed-path image for account details that should be excluded.
Open restored-path.png from your Desktop.
Inspect the restored-path image for account details that should be excluded.

Each image should show its diagnostic status clearly. Neither image should reveal account information or key material.

What makes incident evidence useful?

The failed-path image establishes the original symptom. The restored-path image proves that your remediation changed the result.

Together, they show a controlled troubleshooting process instead of an isolated success screen.

Build the repository report

Screenshots establish what happened. Your README.md explains why it happened plus how you repaired it.

Return to the azure-network-troubleshooting-lab repository from earlier.
Select Add file above the repository file list.
Select Upload files.
Choose blocked-path.png plus restored-path.png from your Desktop.
Complete the upload with the commit control at the bottom of the page.

Good progress. You should now see both image filenames in the repository file list.

Don't see both images?

Check that each image finished uploading before you complete the commit.
Confirm the filenames are exactly blocked-path.png plus restored-path.png.

Help me troubleshoot missing image files in my GitHub repository.

Open README.md from the repository file list.
Use the file editor control to edit README.md.

Build a clear incident timeline

Start with the network you intended to build. Move through the symptom plus diagnostic decision before showing the repair.

Close with proof of recovery plus your cleanup decision. This order lets a reader follow your reasoning from start to finish.

Add an architecture sketch showing vm-frontend in snet-frontend connecting over TCP port 22 to vm-backend in snet-backend.
Add a CIDR plan mapping vnet-troubleshoot at 10.0.0.0/16 to snet-frontend at 10.0.1.0/24 plus snet-backend at 10.0.2.0/24.
Select Preview.

You should see a readable frontend-to-backend sketch. The three address ranges should appear beside the resources they describe.

Return to the file editor.
Build a symptom section around blocked-path.png that records Connection troubleshoot reporting Unreachable for destination port 22.
Record Access denied from Azure Network Watcher IP flow verify as the diagnostic decision.
Select Preview.

The preview should now connect the blocked-path image to the failed connectivity test. It should also identify IP flow verify as the diagnostic method.

Return to the file editor.
Name the matched network security group rule as Deny-SSH-From-Frontend.
Document the remediation as changing Deny to Allow while keeping the rule scope unchanged.
Select Preview.

Your report should now name the root cause. It should show the smallest change that restored the intended flow.

Return to the file editor.
Build a recovery section around restored-path.png.
Record Access allowed from the repaired IP flow verify test.
Select Preview.

You should see the restored-path image beside the first recovery result. This creates a visible contrast with the blocked state.

Return to the file editor.
Record Reachable from the repaired Connection troubleshoot test.
Add your Azure cost-cleanup decision to delete rg-aznet-troubleshoot after preserving the portfolio evidence.

Publish the report

Publishing makes every committed detail public. This final preview gives you one last chance to catch sensitive information before the report reaches the repository front page.

Select Preview.
Review every report section for readability.
Inspect both rendered screenshots for sensitive information.
Select Commit changes....
Complete the commit using the confirmation dialog.

Before you refresh the repository front page, do you expect the complete incident story to render without opening any individual files?

Return to the repository front page.
Refresh the browser.

You should see the architecture sketch plus the failed and restored evidence in the rendered README.md. The report should also show the root cause, remediation, verification results, and cleanup decision.

That closes the loop. Your public repository now proves how you diagnosed the blocked path plus how you verified its recovery.

Report or images missing?

Check that each image path uses the same letter case as its uploaded filename.
Confirm the relative paths point to files in the repository.
Complete a new commit after correcting README.md.

Help me troubleshoot my rendered GitHub incident report.

Secret mission

Diagnose a Source-Side Block

Your repaired backend path proves that destination-side security can control a connection. Move the failure to the frontend subnet so you can identify a source-side outbound block from its diagnostic evidence.

Clean Up Your Resources

Running Azure Virtual Machines can continue generating compute charges. Decide whether to keep the lab live, deallocate both VMs for a short pause, or delete the Azure resource group now.

Cost warning

Azure bills VM compute while each VM is Running. A VM that only reports Stopped can still incur compute charges.

The Stopped (Deallocated) state ends compute billing. Retained Standard SSD managed disks can continue to incur storage charges.

Choose Pause if you plan to return soon. Choose Delete if you have finished the lab.

Resources you used:

Azure resource group rg-aznet-troubleshoot.
Azure Virtual Network vnet-troubleshoot with subnets snet-frontend and snet-backend.
Virtual machines vm-frontend and vm-backend with their NICs and Standard SSD managed OS disks.
Azure Network Security Groups nsg-frontend and nsg-backend.

Keep everything running

No action is required. Choose this if you are continuing the lab in your next session.

Leave vm-frontend and vm-backend in Running only while you are actively using the lab.
Review the portal estimate before extending the lab session.
Keep the public GitHub repository azure-network-troubleshooting-lab with its committed README and redacted evidence images.

Pause - I'll come back to this later

Deallocate both VMs to stop compute billing while preserving the lab configuration. Your managed OS disks remain provisioned and can continue generating storage charges.

Return to vm-frontend in the Azure portal from earlier.
Select Stop on its Overview page.
Confirm the stop request.
Refresh the Overview page until it reports Stopped (Deallocated).
Return to vm-backend in the Azure portal.
Select Stop on its Overview page.
Confirm the stop request.
Refresh the Overview page until it reports Stopped (Deallocated).

Delete - I don't want to use this again

Remove all Azure lab resources if you are finished and want to prevent further lab charges.

This deletion looks drastic because it removes the whole lab in one action. Your committed GitHub report remains available because it sits outside Azure.

Return to rg-aznet-troubleshoot in the Azure portal from earlier.
Select Delete resource group.
Type rg-aznet-troubleshoot into the confirmation field.
Complete the resource group deletion confirmation.
Return to the Azure portal resource group list.
Refresh the list until rg-aznet-troubleshoot no longer appears.

You should no longer see the virtual network, subnets, VMs, NICs, managed disks, or network security groups from this lab.

Nice Work!

You made it! Your published incident report proves that you can trace a failed private SSH path through to recovery.

You've learned how to:

Build a private segmented network in Azure Virtual Network across a frontend subnet plus a backend subnet.
Reproduce an SSH connectivity failure with a subnet-level network security group. Use Azure Network Watcher to identify the rule responsible for the denied flow.
Restore the private network path. Verify the change from Unreachable to Reachable. Publish the redacted evidence in a GitHub incident report.
Secret Mission: Diagnose a source-side outbound block on vm-frontend. Prove that outbound security evaluation stopped the intended flow before it reached the backend.

Ready to quiz yourself?