Azure-Advanced-Networking

M01-Unit 8 Connect two Azure Virtual Networks using global virtual network peering

Exercise scenario

In this unit, you will configure connectivity between the CoreServicesVnet and the ManufacturingVnet by adding peerings to allow traffic flow.

In this unit, you will:

Task 1: Create a Virtual Machine to test the configuration
Task 2: Connect to the Test VMs using RDP
Task 3: Test the connection between the VMs
Task 4: Create VNet peerings between CoreServicesVnet and ManufacturingVnet
Task 5: Test the connection between the VMs
Task 6: Clean up resources

Estimated time: 20 minutes

Task 1: Create a Virtual Machine to test the configuration

In this section, you will create a test VM on the Manufacturing VNet to test if you can access resources inside another Azure virtual network from your ManufacturingVnet.

Create ManufacturingVM

On the Azure portal, open the PowerShell session within the Cloud Shell pane.
On the toolbar of the Cloud Shell pane, select the Upload/Download files icon, in the drop-down menu, select Upload and upload the following files ManufacturingVMazuredeploy.json and ManufacturingVMazuredeploy.parameters.json into the Cloud Shell home directory one by one from the source folder F:\Allfiles\Exercises\M01.

Deploy the following ARM templates to create the VMs needed for this exercise:

$RGName = "ContosoResourceGroup"
   
New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile ManufacturingVMazuredeploy.json -TemplateParameterFile ManufacturingVMazuredeploy.parameters.json

When the deployment is complete, go to the Azure portal home page, and then select Virtual Machines.
Verify that the virtual machine has been created.

Task 2: Connect to the Test VMs using RDP

On the Azure Portal home page, select Virtual Machines.
Select ManufacturingVM.
On ManufacturingVM, select Connect > RDP.
On ManufacturingVM Connect, select Download RDP file.
Save the RDP file to your desktop.
Connect to ManufacturingVM using the RDP file, and the username TestUser and the password TestPa$$w0rd!.
On the Azure Portal home page, select Virtual Machines.
Select TestVM1.
On TestVM1, select Connect > RDP.
On **TestVM1 Connect, select **Download RDP file.
Save the RDP file to your desktop.
Connect to TestVM1 using the RDP file, and the username TestUser and the password TestPa$$w0rd!.
On both VMs, in Networks, select Yes.
On TestVM1, open a PowerShell prompt, and run the following command: ipconfig
Note the IPv4 address.

Task 3: Test the connection between the VMs

On the ManufacturingVM, open a PowerShell prompt.
Use the following command to verify that there is no connection to TestVM1 on CoreServicesVnet. Be sure to use the IPv4 address for TestVM1.
```
 Test-NetConnection 10.20.20.4 -port 3389
```
The test connection should fail, and you will see a result similar to the following:

Task 4: Create VNet peerings between CoreServicesVnet and ManufacturingVnet

On the Azure home page, select Virtual Networks, and then select CoreServicesVnet.
In CoreServicesVnet, under Settings, select Peerings.
On CoreServicesVnet Peerings, select + Add.

Add a peering with the following settings (leave others with their default values) and click Add:

Setting	Value
This virtual network
Peering link name	CoreServicesVnet-to-ManufacturingVnet
Allow ‘CoreServicesVnet’ to access the peered virtual network	Allow (default)
Allow ‘CoreServicesVnet’ to receive forwarded traffic from the peered virtual network	Allow
Allow gateway in ‘CoreServicesVnet’ to forward traffic to the peered virtual network	De-Selected
Enable ‘CoreServicesVnet’ to use the peered virtual networks’ remote gateway	De-Selected
Remote virtual network
Peering link name	ManufacturingVnet_to_CoreServicesVnet
Virtual network deployment model	Resource manager
I know my resource ID	De-Selected
Subscription	the name of the Azure subscription you are using in this lab
Virtual network	ManufacturingVnet
Allow the peered virtual network to access ‘CoreServicesVnet’	Allow (default)
Allow the peered virtual network to receive forwarded traffic from ‘CoreServicesVnet’	Allow
Allow gateway in the peered virtual network to forward traffic to ‘CoreServicesVnet’	De-Selected
Enable the peered virtual network to use ‘CoreServicesVnet’ remote gateway	De-Selected

Note: This step establishes two global peerings - one from CoreServicesVnet to ManufacturingVnet and the other from ManufacturingVnet to CoreServicesVnet. Note: If you don’t have a “MOC Subscription”, use the subscription you’ve been using previously. It’s just a name.

In **CoreServicesVnet Peerings, verify that the **CoreServicesVnet-to-ManufacturingVnet peering is listed and Peering status says Connected..

Note: you may have to refresh the **CoreServicesVnet Peerings** blade more than once.
Under Virtual networks, select ManufacturingVnet, and verify the ManufacturingVnet-to-CoreServicesVnet peering is listed and Peering status says Connected.

Note: you may have to refresh the **ManufacturingVnet Peerings** blade more than once.

Task 5: Test the connection between the VMs

On the ManufacturingVM, open a PowerShell prompt.
Use the following command to verify that there is now a connection to TestVM1 on CoreServicesVnet.
```
 Test-NetConnection 10.20.20.4 -port 3389
```
The test connection should succeed, and you will see a result similar to the following:

Congratulations! You have successful configured connectivity between VNets by adding peerings.

Task 6: Clean up resources

Note: Remember to remove any newly created Azure resources that you no longer use. Removing unused resources ensures you will not see unexpected charges.

On the Azure portal, open the PowerShell session within the Cloud Shell pane. (Create Cloud Shell storage if needed, using default settings.)
Delete all resource groups you created throughout the labs of this module by running the following command:
```
Remove-AzResourceGroup -Name 'ContosoResourceGroup' -Force -AsJob
```
Note: The command executes asynchronously (as determined by the -AsJob parameter), so while you will be able to run another PowerShell command immediately afterwards within the same PowerShell session, it will take a few minutes before the resource groups are actually removed.