DEV Community

Cover image for Implementing Intersite Connectivity in Azure: Seamless Communication Across Virtual Networks
Oladosu Ibrahim
Oladosu Ibrahim

Posted on

Implementing Intersite Connectivity in Azure: Seamless Communication Across Virtual Networks

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.

  1. Sign in to the Azure portal.
  2. Search for Virtual Machines and select Create → Virtual machine.
    Image1
    Image2

  3. 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 Image3 Image4
  4. 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 Image5
  5. Disable boot diagnostics under the Monitoring tab.
    Image6

  6. Review and create the VM.
    Image7

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.

  1. From the Virtual Machines page, select Create → Virtual machine again.
    Image8
    Image9

  2. 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 Image10
  3. 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 Image11
  4. 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.

  1. In the portal, search for Network Watcher.
    Image12

  2. Under Network diagnostic tools, select Connection troubleshoot.

  3. Set the following parameters:

    • Source type: Virtual machine
    • Source VM: CoreServicesVM
    • Destination type: Virtual machine
    • Destination VM: ManufacturingVM
    • Protocol: TCP
    • Destination port: 3389 Image13
  4. Run the diagnostic test.
    Image14

The result will show Unreachable, confirming that traffic cannot flow between VNets without peering.
Image15

Task 4: Configure Virtual Network Peering Between VNets

Now, enable connectivity by creating a peering relationship.

  1. Navigate to the CoreServicesVnet resource.
    Image16

  2. Under Settings, select Peerings and choose + Add.
    Image17

  3. Configure as follows:

    • Peering link name: CoreServicesVnet-to-ManufacturingVnet
    • Virtual network: ManufacturingVnet
    • Allow access both ways (check both boxes for access and forwarded traffic). Image18
  4. Click Add to save the configuration.
    Image19

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).

  1. Open the CoreServicesVnet resource.
    Image20

  2. Under Subnets, select + Subnet and create a new one named perimeter with address range 10.0.1.0/24.
    Image21
    Image22

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

  4. 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) Image26 Image27
  5. Associate this route table with the Core subnet of your CoreServicesVnet.
    Image28

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-rg5 from 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)