Skip to content

PieterbasNagengast/Azure-NetworkTS

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Azure Basic Network Troubleshooting Lab

This repository contains a Azure deployment template for two Virtual machines in separate Subnmets but in a single VNET. Deployiong this template allows you to use Azure Network troubleshooting tools like Network Watcher, NSG Flow Logs, and Diagnostics logs to troubleshoot network issues. There are three pre-defined scenarios avaialble in the template to simulate network issues. Those scenarios are described below as if it was a description of a customer issue / support ticket.

The goal here is to not only understand the issue but also to understand the tools and resources available in Azure to troubleshoot the issue without signing in to the VM's.

Note

This template and the pre-defined scenarios are highly customizable so please feel free to modify the template and scenarios to fit your learning needs or use this as a starting point to create your own network troubleshooting lab.

Warning

This template is for educational purposes only and should not be used in production environments.

Table of Contents

  1. Deployment steps
  2. Tools to use for troubleshooting
  3. Diagram of the deployment
  4. Scenario A: FrontEnd VM cannot connect via RDP to BackeEnd VM
  5. Scenario B: VM's cannot connect to Internet
  6. Scenario C: Backend VM cannot connect to FrontEnd VM
  7. Solution

Deployment steps

Deploy the template using one of the following methods:

Azure Portal Deployment

Deploy to Azure

Manual deployment
  1. Open your prefered Powershell (e.eg. Azure Cloud Shell, PowerShell)

  2. Clone the repository

    git clone https://github.com/PieterbasNagengast/Azure-NetworkTS.git
  3. Change the directory to the cloned repository

  4. Create new resource group using the following command

    New-AzResourceGroup -Name <resource-group-name> -Location <location>
  5. Run the following command to deploy the template

    New-AzResourceGroupDeployment -ResourceGroupName <resource-group-name> -TemplateFile .\main.bicep
  6. Once the deployment is complete, you can access the resources in the Azure Portal.

  7. To simulate the network issues, you can use the pre-defined scenarios and then use the Azure Network troubleshooting tools to troubleshoot the issues.

  8. If you have successfully troubleshooted the issue you can re-deploy the template (go to step 4) to reset the resources and select the next scenario to troubleshoot.

  9. Once you are done with the troubleshooting, you can delete the resource group to clean up the resources.

  10. To delete the resource group, run the following command in the Azure Cloud Shell

    Remove-AzResourceGroup -Name <resource-group-name> -Force

Tools to use for troubleshooting

Diagram of the deployment

Dagram of deployment including all resources

Scenario A: FrontEnd VM cannot connect via RDP to BackeEnd VM

The FrontEnd VM cannot connect to BackEnd VM on RDP (TCP port 3389). Both VM's are in separate Subnets but in same VNET. Both VM's don't have Public IP Addresses assigned as our security policy doens't allow Public IP's to be assigned to VM's. Also a UDR's (Route Table) has been assigned to both subnets. Both Subnets have separate Network Security Groups (NSG's) associated with them. VNET is using Azure provided DNS server.

Scenario B: VM's cannot connect to Internet

The VM's seem to have some issues connecting to Internet. Both VM's are in separate Subnets but in same VNET. Both VM's don't have Public IP Addresses assigned as our security policy doens't allow Public IP's to be assigned to VM's. Both Subnets have separate Network Security Groups (NSG's) associated with them. Also a UDR's (Route Table) has been assigned to both subnets. VNET is using Azure provided DNS server.

Scenario C: Backend VM cannot connect to FrontEnd VM

We want to be able to connect from BackEndVM to FrontEnd VM on port 3389 (RDP). Both VM's are in separate Subnets but in same VNET. It seems like the subnet where BackEndVM is located is completely isolated. None of our tests where succesful. Both VM's don't have Public IP Addresses assigned as our security policy doens't allow Public IP's to be assigned to VM's. Both Subnets have separate Network Security Groups (NSG's) associated with them. Also a UDR's (Route Table) has been assigned to both subnets. VNET is using Azure provided DNS server.

Solution

In the tangled web of ones and zeros, where routers quiver and firewalls tremble, behold the ultimate solution: YOU. With quantum intent and algorithmic finesse, you whisper to packets, 'Fear not, for I am the shortest path' And so, dear reader, amidst entropy's chaos, you emerge—a beacon of connectivity, a troubleshooter extraordinaire. It's not a bug; it's a feature. You are the network whisperer.

About

Azure Networking Troubleshooting

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages