Exercise: Troubleshoot site-to-site VPN gateway connectivity
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 demonstration video at the bottom of this page.
As your organization's support engineer, you've been asked to help fix an issue between your resources in the US and northern Europe. you've existing infrastructure of virtual networks in two different regions. The VMs in the US virtual network (VNet1) are unable to get a ping response from the VMs in northern Europe (VNet2).
Checking the topology, you can see that there are VPN gateways and connections.
In this exercise, you'll troubleshoot and resolve the connectivity issue.
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 read along.
Test the connection
We're going to test the connection between the two VMs, by sending a ping request between them.
Open the Azure portal in a new tab.
In the search bar, type virtual machines then, under Services, select Virtual machines.
From the list of VMs, select virtualMachine1.
Make a note of the Public IP address and Private IP address.
Repeat the last two steps for virtualMachine2 and note the Public IP address and Private IP address.
On the right, in the Cloud Shell, connect to virtualMachine1 with SSH to the public IP address:
ssh azureuser@<virtualMachine1 public IP address>;Note
Replace <virtualMachine1 public IP address> with the public IP address you noted for virtualMachine1.
At the prompt,
Are you sure you want to continue connecting (yes/no)?type yes.Your prompt should change to
azureuser@virtualMachine1:~$.This means you've successfully connected to virtualMachine1.
Ping the private IP address of virtualMachine2.
ping <private IP address virtualMachine2>Note
Replace <private IP address> virtualMachine2 with the private IP address you noted for virtualMachine2.
We can confirm that the two machines can't connect, as there is no response from virtualMachine2.
Press CTRL + C keys to quit the ping command.
Troubleshoot the gateways
You'll check the types are correct for both gateways.
Go to the Azure portal.
In the search bar, type virtual network gateways, and then select the service to continue.
Select VNet1GW.
Confirm that the VPN type is route-based, and the gateway type is VPN.
Scroll down the page to check the tunnel Ingress and Egress. Can you see a time when something might have happened to cause a problem?
Repeat for VNet2GW.
Troubleshoot the virtual networks
You'll now check the address spaces don't overlap for the two virtual networks.
In the search bar, type virtual networks, and then select the Virtual network service.
Select VNet1.
Make a note of the Address space.
Select VNet2, and check that the address spaces do not overlap.
The two address spaces are different, so we can rule out any problems with them.
You'll now check the subnets are correctly set up.
Select VNet1, then select Subnets.
Check the subnet address is a subset of the address space.
Repeat for VNet2.
The GatewaySubnet addresses have been correctly created and correspond with the default range.
Check the gateway connections
In the search bar, type virtual network gateway and then select virtual network gateways.
The two gateways will be displayed.
Select VNet1GW.
Select Connections.
The issue seems to be with the connections between the gateways.
Select Refresh to check that there is still an issue with connection.
A connection still can't be made, so you'll check the shared keys.
Select VNet1-VNet2.
Select Shared key.
Make a note of the Shared key.
On the breadcrumb trail, select VNet1GW, then select VNet2-VNet1.
Select Shared key.
The shared keys are not the same. For the connections to work, the shared key must be identical.
Now that you've found the issue, you'll resolve it in the next exercise.
In this demonstration you will see how to proactively troubleshoot Conditional Access policies using the What if tool in the Azure portal: