Introduction
In cloud environments, organizations often segment their IT infrastructure into multiple virtual networks (VNets) for better security, performance, and management. For instance, a company may separate core IT services such as DNS and security from departmental workloads like manufacturing or R&D.
However, in many cases, applications and services across these networks still need to communicate securely for example, when a manufacturing app needs to access a shared DNS or authentication service hosted in the core network.
This is where Azure Intersite Connectivity comes in. By implementing Virtual Network Peering, you can connect multiple VNets in Azure, allowing traffic to flow privately through Microsoft’s backbone network without requiring VPNs or gateways.
In this hands-on lab, you’ll explore how to establish communication between two Azure virtual networks and verify connectivity using Network Watcher and PowerShell. You’ll also create a custom route to control traffic flow for specific subnets.
By the end, you’ll understand how to interconnect Azure VNets to build secure, scalable multi-tier cloud architectures.
Skilling Objectives
You will learn how to:
- Create and configure multiple virtual networks and virtual machines.
- Use Network Watcher to troubleshoot connections between VNets.
- Configure VNet peering to enable secure communication.
- Create a custom route to manage and control traffic between subnets.
Lab Scenario
Your organization operates separate virtual networks for core IT services and manufacturing systems. For security reasons, these environments are isolated — but certain business processes require secure communication between them.
In this exercise, you’ll configure peering between these VNets, allowing both areas to communicate over Azure’s backbone while maintaining network segmentation.
Task 1: Create a Core Services Virtual Machine and Virtual Network
Begin by deploying your first virtual machine and network.
- Sign in to the Azure portal.
Search for Virtual Machines and select Create → Virtual machine.


-
On the Basics tab, provide the following:
- Resource group:
az104-rg5(create one if needed) - Virtual machine name:
CoreServicesVM - Region: East US
- Image: Windows Server 2019 Datacenter – x64 Gen2
- Size: Standard_D2s_v3
- Username:
localadmin - Password: create a complex one
- Public inbound ports: None
- Resource group:
-
On the Networking tab, choose Create new for Virtual Network and set:
- Name:
CoreServicesVnet - Address range:
10.0.0.0/16 - Subnet name:
Core - Subnet range:
10.0.0.0/24
- Name:
This creates both the virtual network and the VM that will represent your core services environment.
Task 2: Create a Manufacturing Virtual Machine and Virtual Network
Next, create another virtual machine in a separate virtual network.
From the Virtual Machines page, select Create → Virtual machine again.


-
Provide the following configuration:
- Resource group:
az104-rg5 - Virtual machine name:
ManufacturingVM - Region: East US
- Image: Windows Server 2019 Datacenter – x64 Gen2
- Size: Standard_D2s_v3
- Username:
localadmin - Password: same secure password
- Public inbound ports: None
- Resource group:
-
Under Networking, create a new virtual network:
- Name:
ManufacturingVnet - Address range:
172.16.0.0/16 - Subnet name:
Manufacturing - Subnet range:
172.16.0.0/24
- Name:
Disable boot diagnostics and create the VM.
You now have two isolated environments — Core Services and Manufacturing — ready for intersite connectivity.
Task 3: Test the Connection Between Virtual Machines Using Network Watcher
Before establishing peering, let’s verify that the VMs cannot currently communicate.
Under Network diagnostic tools, select Connection troubleshoot.
-
Set the following parameters:
- Source type: Virtual machine
- Source VM:
CoreServicesVM - Destination type: Virtual machine
- Destination VM:
ManufacturingVM - Protocol: TCP
- Destination port: 3389
The result will show Unreachable, confirming that traffic cannot flow between VNets without peering.

Task 4: Configure Virtual Network Peering Between VNets
Now, enable connectivity by creating a peering relationship.
-
Configure as follows:
- Peering link name:
CoreServicesVnet-to-ManufacturingVnet - Virtual network:
ManufacturingVnet - Allow access both ways (check both boxes for access and forwarded traffic).
- Peering link name:
Your VNets are now linked via Azure’s private backbone — enabling secure intersite communication.
Task 5: Create a Custom Route
To control traffic flow between subnets, you’ll create a user-defined route (UDR).
Under Subnets, select + Subnet and create a new one named
perimeterwith address range10.0.1.0/24.


In the portal, search for Route tables and create a new route table named
rt-CoreServices.



-
Once created, open the route table and add a new route:
- Route name:
PerimetertoCore - Destination type: IP Addresses
- Destination:
10.0.0.0/16 - Next hop type: Virtual appliance
- Next hop address:
10.0.1.7(representing a future Network Virtual Appliance)
- Route name:
Associate this route table with the Core subnet of your CoreServicesVnet.

With this, traffic from the perimeter subnet will be routed through the NVA before reaching internal services — providing an additional layer of control and security.
Cleanup
To avoid unnecessary costs, delete the resources after completing the lab:
- Delete the resource group
az104-rg5from the Azure portal.
Conclusion
You’ve successfully implemented intersite connectivity between two virtual networks in Azure. This setup is foundational for enterprise-grade architectures — enabling cross-department communication, hybrid setups, and multi-region workloads.
In the next lab, you’ll build upon this by exploring more advanced traffic control mechanisms and network security configurations to further strengthen your Azure infrastructure.








Top comments (0)