Exercise: Troubleshoot cloud and hybrid connectivity

  • 10 minutes

Important

You need your own Azure subscription to complete the exercises in this module. If you don't have an Azure subscription, you can still view the demonstraition video at the bottom of this page.

If you have not already run the script in unit 2, please do so now so you can follow the exercise below.

You have configured your network as shown in the diagram below. You want VM1 and VM2 to communicate via the VnetHub. Users are complaining that VM1 cannot communicate with VM2. You need to investigate to diagnose the problem, and then fix it.

There are three Azure virtual networks (VNets) in a hub and spoke topology.

Screenshot of spoke and hub topology.

Diagnosis

Verify the network topology

  1. Sign in to the Azure portal using the same account you used to activate the sandbox.

  2. Familiarize yourself with the network topology and check it matches the diagram above.

  3. Check the private IP addresses of the firewall (FW1) and virtual machines (VM1 and VM2). These are allocated automatically. Make a note of the correct IP addresses if they are different from the diagram.

Check OSI level 3 connectivity

  1. Connect to each virtual machine (VM1 and VM2) using Remote Desktop. Windows credentials are:

  2. User name: AdminXyz

  3. Password: sfr9jttzrjjeoem7hrf#

  4. On VM1, open a command prompt window and ping the private IP address of VM2.

  5. Ping the private IP address of the Azure firewall (FW1).

  6. On VM2, open a command prompt window and ping the private IP address of VM1.

  7. Ping the private IP address of the Azure firewall (FW1).

    Screenshot showing the command prompt with the ping request results.

Troubleshoot the problem

  1. To understand what is causing the problem, try the following troubleshooting steps:

  2. Examine ipconfig /all on both VM1 and VM2.

  3. Examine the Network Security Groups, and routing tables.

  4. Examine the firewall and the firewall rules.

  5. Examine the peering connection properties.

    The diagram shows the effective routes on VM1-nic.

    Screenshot showing the effective routes.

Resolution

When you examined the peering connections, you would have found that the peering settings are different.

VNet Peering name Traffic forwarded from remote virtual network
VnetHub Hub-Spoke1 Allow (default)
VnetHub Hub-Spoke2 Block traffic that originates from outside this virtual network
VnetSpoke1 Spoke1-Hub Allow (default)
VnetSpoke2 Spoke2-Hub Block traffic that originates from outside this virtual network

Screenshot showing peerings.

The settings on Hub-Spoke2 are incorrect.

Screenshot showing the incorrect spoke traffic forwarding setting.

To fix the problem, you must change the setting in both sides of the peering between VnetHub and VnetSpoke2.

  • Hub-Spoke2

  • Spoke2-Hub

The Traffic forwarded from remote virtual network must be set to Allow.

It should now be possible on VM1 to ping VM2.

Screenshot showing the command prompt with the ping request working.

There will be a short delay before the new settings take effect. If the ping fails at first, try again.

In this demonstration you will see how to proactively troubleshoot Conditional Access policies using the What if tool in the Azure portal: