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.
- Deployment steps
- Tools to use for troubleshooting
- Diagram of the deployment
- Scenario A: FrontEnd VM cannot connect via RDP to BackeEnd VM
- Scenario B: VM's cannot connect to Internet
- Scenario C: Backend VM cannot connect to FrontEnd VM
- Solution
Deploy the template using one of the following methods:
Manual deployment
-
Open your prefered Powershell (e.eg. Azure Cloud Shell, PowerShell)
-
Clone the repository
git clone https://github.com/PieterbasNagengast/Azure-NetworkTS.git
-
Change the directory to the cloned repository
-
Create new resource group using the following command
New-AzResourceGroup -Name <resource-group-name> -Location <location>
-
Run the following command to deploy the template
New-AzResourceGroupDeployment -ResourceGroupName <resource-group-name> -TemplateFile .\main.bicep
-
Once the deployment is complete, you can access the resources in the Azure Portal.
-
To simulate the network issues, you can use the pre-defined scenarios and then use the Azure Network troubleshooting tools to troubleshoot the issues.
-
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.
-
Once you are done with the troubleshooting, you can delete the resource group to clean up the resources.
-
To delete the resource group, run the following command in the Azure Cloud Shell
Remove-AzResourceGroup -Name <resource-group-name> -Force
- Azure Network Watcher
- IP Flow Verify
- NSG Diagnostics
- Next Hop
- Effective Routes
- Effective Security Rules
- Connection Troubleshoot
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.
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.
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.
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.