Azure Vnet Peering

Category
Azure Virtual Network – Blog No 3
Time to Read
25 Minutes
Who should read this blog?
If you want to learn about Vnet peering and how to configure it?
Azure Vnet Peering

Preface

An Azure Virtual Network is like an isolated place, within which you can roam anywhere but still, you are confined to the boundaries of the virtual network. Similarly, within each virtual network every machine/resource can talk to each other but can not speak to any resource out of the virtual network.

But what if we requirement emerges to have communication between two virtual machines/resources which are part of the different virtual networks. This can be achieved through Vnet Peering. Let’s understand.

Azure Vnet Peering

Why Vnet Peering?

When you create a virtual network in Azure, it acts as a logical boundary for your resources, providing isolation and control over network traffic. However, there are situations where you may have multiple virtual networks and the need to connect them together for various reasons, such as sharing resources and enabling cross-network communication. Virtual network peering enables you to connect virtual networks in the same region and across regions (also known as Global VNet Peering) through the Azure backbone network. 

This is where VNet Peering comes in handy. It enables you to connect virtual networks using the Azure backbone network, ensuring low-latency and high-bandwidth connectivity. By establishing peering relationships between virtual networks, you can seamlessly access and use resources across those networks, as if they were part of a single network.

Furthermore, VNet Peering supports both virtual networks within the same Azure subscription and different subscriptions, making it suitable for various scenarios, such as multi-tenant environments or connecting networks across organizational boundaries.


How to configure Vnet Peering

In this section, we will start creating two different vnets VnetA and Vnet B from two different regions. You may refer to my blog in which I have covered how to create a virtual network.

VnetA -10.1.0.0/16 – Location EastUS

VnetB- 172.16.0.0/16 – Location UK South

Test conditions – We will create a Windows VM each in VnetA and VnetB and test the connectivity to see before and after the Vnet Peering.

Go to VnetA and Click on Peerings

Click on Add

On the Next Page, we see peering configuration. Since Vnet peering is a bidirectional concept which means you have to go to VnetB and configure peering from that side also to VnetB.

To save those efforts azure lets you configure the other side of vnet peering from the remote vnet side which is VnetB in our case.

there are two parts to this configuration – 1) this Virtual Network and 2) Remote Virtual Network.

Both sections have the same options to configure, let’s understand them

Point 1 – Traffic to remote virtual Network

 Select Allow (default) if you want to enable communication between the two virtual networks

Select Block all traffic to the remote virtual network if you don’t want traffic to flow to the peered virtual network by default. You can select this setting if you have to peer between two virtual networks but occasionally want to disable the default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings.

When this setting is selected, traffic doesn’t flow between the peered virtual networks by default; however, traffic may still flow if explicitly allowed through an NSG rule that includes the appropriate IP addresses or application security groups.

Note

Selecting the Block all traffic to remote virtual network setting only changes the definition of the VirtualNetwork service tag. It doesn’t fully prevent traffic flow across the peer connection, as explained in this setting description.

Point 2 – Traffic forwarded from remote virtual network

Select Allow (default) if you want traffic forwarded by a network virtual appliance in the remote virtual network (that didn’t originate from the remote virtual network) to flow to this virtual network through a peering. This will help in the hub and spoke topology.

For example, consider three virtual networks named Spoke vnet1 , Spoke vnet 2, and Hub. A peering exists between each spoke virtual network and the Hub virtual network, but peerings don’t exist between the spoke virtual networks.

A Firewall virtual appliance gets deployed in the Hub virtual network, and user-defined routes get applied to each spoke virtual network that routes traffic between the subnets through the network virtual appliance.

If this setting isn’t selected for the peering between each spoke virtual network and the hub virtual network, traffic doesn’t flow between the spoke virtual networks because the hub isn’t forwarding the traffic between the virtual networks. 

Point 3 – Virtual Network Gateway and Route Server

This setting is used in scenarios where you have a Virtual Network Gateway or Route Server deployed in the Virtual Network which has site-to-site connectivity with your on-prem office and this Vnet connects to other Vnets via vnet peering

Here we will explain this concept on Hub and spoke topology

Our Hub vnet has site to site VPN connectivity with on-prem office and has vnet-peering with the other spoke Virtual Networks.

Note

Virtual Network Gateway and Route Server settings is specifically only for Spoke vnets which wants to reach the on-prem networks.

When you Select None(default), your Hub vnet can talk to the on-prem resources, and all the spokes vnets connected via vnet peering but spoke vnets can only talk to hub resources via vnet peering. Refer to the below routing table –

As you can see the spoke vnets can talk to Hub vnet resources but can not reach the on-prem office network.

None(Default) setting

However you want your Spoke virtual Networks to talk to your On-prem Networks via HUB Virtual Network Gateway

Under the Hub vnet you need to select – Use this Virtual Network Gateway or Route Server

Under the each Spoke vnet you need to select – Use the remote Virtual Network Gateway or Route Server

This is how the routing tables will be modified with the above settings. To learn more about Gateway Transit click on the link.

Note

This topology works if your spoke Vnets do not have a virtual network gateway themselves You can’t use remote gateways options for your spoke vnets if your spoke already have a virtual network gateway configured in virtual network.In hub-and-spoke network architecture, gateway transit allows spoke virtual networks to share the VPN gateway in the hub, instead of deploying VPN gateways in every spoke virtual network. 

Completing Configuration

Since I don’t have any On-prem site in my topology I am going to use virtual network gateway and Route server setting as None

This Network

Remote Network

Click on Add and Vnet Peering is established from both vnets to each other. Let’s verify

On VnetA side

On VnetB side


Validation

For Validation I created

VnetA-VM01 under VnetA – Got IP address – 10.1.0.4

VnetB-VM01 under VnetB- Got IP address – 172.16.0.4

The routing table of VnetA VM

For testing, I will perform RDP to VnetB-VM01 from VnetA-VM01

Voila !! It works.


Conclusion: This summary explores how Virtual Network Peering enables organizations to establish private and secure communication channels between virtual networks, simplifying network management and resource sharing.

Related Posts

What VPN types are supported by Azure

Category Azure VPN – Blog No 1 Time to Read 25 Minutes Who should read this blog? If you want to learn about the VPN tunnel types…

What is Azure Load Balancer?

Category Azure Load Balancer – Blog No 1 Time to Read 25 Minutes Who should read this blog? If you want to learn about the load balancer…

Azure Routing Table

Category Azure Virtual Network – Blog No 2 Time to Read 25 Minutes Who should read this blog? If you want to learn about the types of…

Configuring Azure NSG

Category Azure NSG – Blog No 2 Time to Read 15 Minutes Who should read this blog? If you want to configure NSG Configuring Azure NSG Preface…

Azure NSG

Category Azure NSG – Blog No 1 Time to Read 20 Minutes Who should read this blog? If you want to understand NSG in simple words. Azure…

Azure Virtual Network

Category Azure Virtual Network – Blog No 1 Time to Read 25 Minutes Who should read this blog? Do you want to learn about the Azure virtual…

Leave a Reply

Your email address will not be published. Required fields are marked *

Verified by MonsterInsights