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