In this blog, we will discuss how to troubleshoot the user-defined route in Azure. I have faced this issue in one of my projects. Typically when you want to test the traffic from a specific VM you will have to log in to the VM and see the output of the Traceroute command and it becomes cumbersome if you have so many routes because now you have to log in to each VM to verify whether the routes are working correctly or not. Another problem is that even if the routes are not working traceroute will not show why it is not working. So if you do not know why routes are not working you can not fix anything. To overcome this issue I wrote a small script that can be used as it is by changing the parameters and it will display the connectivity status (success or failure) if there is an issue then this script will also show what is causing that issue.
To showcase this scenario I have taken the hub and spoke Architecture depicted below wherein we have defines the user defines route from jump box VM to on-premise VM and the traffic goes via Azure Firewall. This scenario is depicted in the below diagram:
We will use the below PowerShell script to test the connectivity. Please modify the script based on your requirement.
connect-azAccount #Copy the Subscription ID of the subscription where your source VM is located Subscription Select-AzSubscription Subscription-ID-of-the-Source-vm # Resource Group Name $rgName = "RG-SVR-MGMT" # Source VM Name $sourceVMName = "jumpbox" # Get the Resource group $RG = Get-AzResourceGroup -Name $rgName # Get the SourceVM in a variable $VM1 = Get-AzVM -ResourceGroupName $rgName | Where-Object -Property Name -EQ $sourceVMName # use Network Watcher where VM is located $networkWatcher = Get-AzNetworkWatcher | Where-Object -Property Location -EQ -Value $VM1.Location # Use AzNetworkWatcherConnectivity commandlet to test the connectivity please specify the destination VM IP address in this case we will use On-remise VM IP address # Port 7 is used for ICMP traffic for Ping Test-AzNetworkWatcherConnectivity -NetworkWatcher $networkWatcher -SourceId $VM1.Id -DestinationAddress Destination-VM-IP-Address -DestinationPort 7
It shows the issue in the connectivity and displays the status of connectivity ConnectionStatus: Unreachable. It also shows the issue that this security rule: Rest-All-Block-to-Cloud is creating the issue.
"Issues": [ { "Origin": "Outbound", "Severity": "Error", "Type": "NetworkSecurityRule", "Context": [ { "key": "RuleName", "value": "/subscriptions/abcdefd-aac5-41d5-b3ca-71 6492cda43a/resourceGroups/rg-svr-mgmt/providers/Microsoft.Ne twork/networkSecurityGroups/nsg-Shared-IN-SrvMgmt-Jump-Out/Secu rityRules/Rest-All-Block-to-Cloud" } ] } ]
It clearly shows that the traffic is flowing thru AzureFirewall which means that the route towards the firewall is also working fine and there are no issues.
{ "Type": "AzureFirewall", "Id": "abcde791-56e6-41c1-acc2-1ca558629db9", "Address": "10.121.0.55", "ResourceId": "/subscriptions/abcd78d3-aac5-41d5-b3ca-71649 2cda43a/resourceGroups/rg-network-transit-in/providers/Microsof t.Network/azureFirewalls/Primary-FW", "NextHopIds": [ "7799a7a0-01e0-498d-bdce-350fc83b5719" ], "Issues": []
Here is the full outcome of the script.
ConnectionStatus : Unreachable AvgLatencyInMs : MinLatencyInMs : MaxLatencyInMs : ProbesSent : 30 ProbesFailed : 30 Hops : [ { "Type": "Source", "Id": "245689b8-efd8-49dc-aa39-e7d143882b25", "Address": "10.120.5.4", "ResourceId": "/subscriptions/abcd78d3-aac5-41d5-b3ca-71649 2cda43a/resourceGroups/RG-SVR-MGMT/providers/Microsoft.Compu te/virtualMachines/jumpbox", "NextHopIds": [ "1a8ea791-56e6-41c1-acc2-1ca558629db9" ], "Issues": [ { "Origin": "Outbound", "Severity": "Error", "Type": "NetworkSecurityRule", "Context": [ { "key": "RuleName", "value": "/subscriptions/abcdefd-aac5-41d5-b3ca-71 6492cda43a/resourceGroups/rg-svr-mgmt/providers/Microsoft.Ne twork/networkSecurityGroups/nsg-Shared-IN-SrvMgmt-Jump-Out/Secu rityRules/Rest-All-Block-to-Cloud" } ] } ] }, { "Type": "AzureFirewall", "Id": "abcde791-56e6-41c1-acc2-1ca558629db9", "Address": "10.121.0.55", "ResourceId": "/subscriptions/abcd78d3-aac5-41d5-b3ca-71649 2cda43a/resourceGroups/rg-network-transit-in/providers/Microsof t.Network/azureFirewalls/Primary-FW", "NextHopIds": [ "7799a7a0-01e0-498d-bdce-350fc83b5719" ], "Issues": [] }, { "Type": "VirtualNetwork", "Id": "7716a7a0-01e0-498d-bdce-350fc83b5719", "Address": "10.120.74.6", "ResourceId": "/subscriptions/abcd6832-1e30-491c-b124-96ecf 056085b/resourceGroups/dev-in/providers/Microsoft.Networ k/networkInterfaces/bod394/ipConfigurations/ipconfig1", "NextHopIds": [], "Issues": [] } ]
Now you can change the source VM name, Subscription id, and destination IP address and test any UDR for its connectivity. I hope this helps.