How to connect multiple virtual networks using Virtual Network Peering? — Top Tech Notes

Virtual network represents a communication and security boundary and enables various azure resources to communicate with each other securely. Virtual network uses the azure backbone network and the communications within virtual networks are all internal. That means it does not involve internet connection until or unless we want that type of connectivity to happen. Virtual networks are an isolation boundary and so by default two or more virtual network cannot resolve or connect to each other. This is default design of azure virtual network.

To enable communication between virtual machines in different virtual networks we use peering. And we use Azure DNS service for name resolution in virtual machines between different virtual networks. For name resolution within virtual network we have azure provided domain system or DNS to automatically resolve each other names.

But why we need multiple virtual networks and how to connect multiple virtual networks?

Let’s first discuss why we need multiple virtual networks.

There are three main reasons for using multiple virtual networks.

One is for saving money on expensive license of virtual network appliance which are specialized VMs that provide load-balancing, firewalling. We can just configure virtual network appliance on one of the VNet and share it’s capabilities across multiple VNets.

Let’s consider we have a virtual network appliance in one VNet and to this we want to configure all other virtual network subnets. For this we would need to override the system routes and create our own routing tables. This process is called user defined routing. We do this by binding the route tables at the subnet level and configure them with a default route to go to that virtual network appliance. We force other subnets to put all of their outbound traffic through this appliance by creating a user defined routing table. And then we enable IP forwarding in the virtual network appliance to force traffic through it so that it can pass traffic that is not intended for itself. This process is called service chaining.

The next reason for using multiple virtual networks is when your business needs to segment workloads. Using network security group and user defined routing we have full control over routing between virtual networks. And as mentioned without peering there is absolutely no communication between separate virtual networks. But we can create a hub-and-spoke architecture which is often used in a hybrid cloud scenario where we have a site-to-site VPN or an express route connection between on premise and our transit virtual network.

And the final reason is to have a secure traffic when the business wants to replicate their on-premise Vlan infrastructure in azure.

Understanding VPN

A virtual private network represents a secure connection over an insecure medium.

Azure site-to-site VPNs or VNet-to-VNet VPNs, use Internet Protocol Security, Internet Key Exchange, IPSec/IKE tunnels which are industry-standard protocols.

Earlier the VNet-to-VNet VPN was the only way to link different virtual networks that were in separate Azure regions. But now Global VNet peering has removed this limitation. However it is still a good option in case where we need to create more isolated and administratively separated boundaries between different VNets within the same region or across multiple regions.

This can also provide cross-region geo-redundancy and replication in a secure fashion because that channel is not only within the Azure network backbone, but it’s also being protected through a VPN encrypted tunnel. No traffic crosses the public internet and, of course, private IP addressing. But we must keep in mind that establishing a VNet-to-VNet VPN requires a separate VPN gateway in each VNet and each of them cost separately. While in a peering relationship this separate cost is not incurred. So if we want to connect two different VPNs and we also want to avoid this overhead cost then the options for us is network peering.

So let’s understand what virtual network peering is.

Virtual Network Peering

Let’s now understand about virtual network peering.

A peer is a logical link between two virtual networks. And the purpose of virtual network peering is to enable resources in VNets to communicate with each other with little or no extra configuration.

Once virtual networks are peered, resources in both virtual networks are able to communicate with each other, with the same latency and bandwidth as if the resources were in the same virtual network. Note that name resolution does not flow through the peering relationship, which means that we’re going to need to create a private Azure DNS zone as part of our work. We have discussed Azure DNS in detail in separate post where we have created a private Azure DNS zone.

Using peering with user defined routing helps to save money in a service chain scenario. This is common for business to have multiple VNets and communication between these VNets. So how do we do this? For this let’s go back to our previous topology diagram which we saw when we introduced peering.

Let’s say we have an on-premises network with a physical VPN gateway. Here we are using Express Route. We have a gateway subnet in our hub to terminate the secure link. There is a management subnet. In this topology we have two spoke networks and a peering relationship has been created between them which clearly mean that we can have a one-to-many relationship between virtual networks. The hub virtual network has 2 peering relationships with Spoke 1 and Spoke 2. For this topology to be able to forward traffic into the transit network and then to on-premise, we would need to create user-defined routing tables at the subnet level for the Spoke 1 and Spoke 2 subnets. This is called forced tunnelling.

DNS Name Resolution in a Hybrid Cloud

There are two ways to configure name resolution in azure hybrid cloud.

One way is to use our own DNS servers and configure forwarding. So let’s say in a hybrid cloud we have on-premises and Active Directory domain and those domain controllers run DNS. Those DNS servers would be configured to forward queries out to Azure, and then in the VNet peer or site-to-site VPN link between those VNets where we can stand up our own DNS servers and configure forwarding.

Another approach is to configure the Azure DNS service or private zones. Azure DNS is a service where we can actually host and manage our own public DNS domains. With this DNS service we can register one or multiple virtual network that is bound to the same private zone also known as resolution networks. Functionally, the difference would be in the zone records. In registration network, the hosts will have their names auto registered in the private zone. And for our resolution networks, we will need to manually create those hosts in CNAME and MX records that we need. So as a result it provides easy name resolution all hosted in Azure, using the Azure DNS service.

So this was a brief and basic concept of technology which we can use to connect multiple virtual networks in azure. Let’s now see how we can connect multiple virtual networks.

Let’s take a demo on VNet peering implementation.

In our demo setup we are going to do VNet peering where we would assume non-overlapping address spaces in each VNet and we would assume that the VNets are in the same Azure region. I’m going to use East US. We’re going to place a VM in each VNet for testing purposes, and for name resolution. Azure-provided DNS is constrained to the VNet, so in order to do name resolution across we would need to implement a DNS solution which we have discussed in detail in separate posts on Azure DNS.

So once again let’s open virtual network blade and let’s create a new virtual network by clicking on the add button.

A create virtual network blade opens on the right hand side. Here I will go ahead and quickly fill out the form with the below details.

• Virtual network name: prod-vnet1
• Address space: 10.10.0.0/16 (It will contain addresses from 10.10.0.0 to 10.10.255.255 which is a total of 65536 addresses)
• Resource group: pracapproach
• Location: West India
• Subnet: Default
• Address Range: 10.10.10.0/24
• DDos Protection: Basic
• Service endpoint: Disabled

After filling up the form with above details I will click on create button to create this virtual network.

The virtual network will get created in just few seconds.

Now refresh the virtual network blade. And you can see below the virtual network that we have just created.

I will go ahead and create another virtual network with below details.

And now you can see the two virtual networks that we have created.

So our two virtual networks are ready. Now our next task is to create two virtual machines and bind these two virtual networks with the virtual machines. So open virtual machine blade and click on add button to create virtual machine.

I will just go ahead and quickly fill out the form with below details.

First virtual machine specifications Second virtual machine specifications

• Name: vm02
• Virtual network: prod-vnet2
• Subnet: Default
• Rest details will be the same as it is in first virtual machine.

I have filled the VM creation blade form with above details and created two VMs.

So our half work is done. We have created two virtual networks and two virtual machines and we have bind each of these virtual machine to one separate network. Now as discussed earlier one virtual machine in a virtual network by default cannot communicate with another virtual machine in another virtual network. So we will next establish a peering relationship between the two virtual networks and will see if that enables communication between these two VM’s or not.

Now while creating these two virtual machines I have not bind any network security group to any of the VMs. This was because I wanted to show you how to bind a virtual network and it’s subnet to a network security group. Let’s see how we can do this.

How to bind a Virtual Network to a Network Security Group (NSG)?

Let’s open the properties blade of vm01 and then go to the networking tab. In this networking blade you will find that this virtual machine has a virtual network prod1-vnet and a default subnet assigned to it which we did while creating this VM. This VM has a public IP address and a private IP address assigned as per our specified address space. And down below you will find that there is no inbound port rules assigned because it is not bind to any NSG.

So this VM is literally exposed over internet and is vulnerable to attacks. We will bind a NSG to this VM.

In the same manner we can validate that network interface of the second VM that we created is also not associated with any NSG.

So let’s now create a new NSG and associate these two VM’s network to our NSG.

Open the network security group blade and click on the add button at the top. It will open a create network security blade. I will go ahead and quickly fill the form with below details.

• I will give this NSG a name vmpeer-nsg.
• Subscription will be default.
• I will put it in resource group pracapproach.
• Location will be West India.
• Finally click on create.

Azure starts validation and then deploying NSG. In few seconds NSG has been deployed.

And once you refresh the blade now you can see our new NSG vmpeer-nsg.

Let’s go to this network security group properties blade and then go to subnets.

You can see below that there are no subnets associated with this NSG. Let’s now associate the subnets for our two virtual networks that we have created. To associate the subnets here click on the associate button at the top.

In the associate subnet blade click on choose a virtual network. And the next blade shows us all the subnets available in the region West India. I will select the first virtual network prod-vnet1.

And then select the subnet available in this virtual network which is the default subnet.

And click on ok. Azure will take a couple of seconds to save the subnet information.

Now you can see below that the subnet for our virtual network prod-vnet1 has been associated with this NSG.

Let’s now associate subnet for our second virtual network.

Again click on associate button and then click on choose a virtual network. I will select my second virtual network and its subnet. And then click on ok.

And now subnets for both of our virtual networks have been associated with this network security group.

Let’s now go to the inbound security rules blade by clicking on the inbound security rules tab. You can see the three default inbound rules available here. Let’s now add a new inbound rule to allow RDP port. For this click on add button.

I will change it from basic to advanced. In service I will select RDP. And RDP port 3389 is automatically selected in the port range. Priority will be 100.

I will give it name RDP. And now click on Add.

And our new inbound security rule has been created.

So now it’s time to implement VNet peering. Let’s go to virtual network blade and then go to vm01 properties blade. Click on connect button, download RDP file and login into this machine.

Once you have logged in, open powershell in this virtual machine and set execution policy to run anything on this computer. For this we can write Set-ExecutionPolicy and then use the execution policy parameter and type bypass as the parameter value. Then use the force parameter and run this.

Set-ExecutionPolicy -ExecutionPolicy Bypass -Force

So our execution policy is set now.

Next we need to set firewall rule to allow inbound ICMP connection so that we can check if the server is able to communicate with other servers in a different virtual network or not. So for this we will write New-NetFirewallRule. Then use the -DisplayName parameter and I will provide the firewall rule name. The protocol will be ICMP.

New-NetFirewallRule -DisplayName ‘Allow ICMPv4-In’ -Protocol ‘ICMPv4’

And our ICMP firewall rule is set now for this machine.

Next our virtual machine is not part of any active directory domain service. So to enable winrm remoting without active directory domain service we will have to adjust the trusted hosts list on the server. So we will update the trusted host list for this virtual machine.

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value * -Force

Now go to virtual machines blade and open vm02 properties blade. Again login to this virtual machine and open powershell. We will do the same housekeeping here that we just did in vm01.

• We will set execution policy.
• We will allow ICMP firewall rule.
• We will set the trusted host list for this VM as well.

So now housekeeping for both the virtual machine is done. We are currently logged into vm02. Let’s try to ping the first virtual machine vm01.

And you can see that this VM could not identify the hostname vm01. This is because name resolution is not working across virtual networks. To make this work we will have to set DNS records. To see how to set DNS record I would recommend to read our post on Azure DNS.

Though hostname resolution is not working, still we should be able to test it with IP address. So let’s try to ping the private IP address of our virtual machine vm01. So I will ping 10.10.10.4 which is the private IP address of vm01.

And we get the result as request timed out. And this is because virtual network in azure is an isolation boundary. We cannot directly communicate from one virtual network to another even if they are in same region. To enable communication between them we will have to establish a peering relationship between them. And the same will hold true for vm01 also. It won’t be able to reach vm02 until peering relationship is established. So let’s see how we can do that.

Let’s go back to virtual network blade in azure portal and filter the virtual network for the resource group pracapproach.

You can see above our two virtual networks have filtered out. Let’s go to the properties blade of first virtual network. On this virtual network property blade scroll down and then click on the Peerings tab. Or else you just search for peerings from search box and then click on this tab. This will open peerings blade on the right hand side. And now click on add button at the top to create peering relationship.

I will give it a name vnet1-vnet2 which would mean virtual network 1 to virtual network 2. Resource manager would be our deployment model. And you can specify your resource id or we can pick one from the list. Subscription is already selected.

In virtual network I will select prod-vnet2 which is our second virtual network.

In configuration make sure you do not select disabled else it will turn the peering off. So I will keep it enabled.

However if you want to temporarily suspend peering then you can select disabled here and then change it to enabled when you want to enable peering again.

Then there is forward traffic which is used when we are peering from a hub VNet. We are not peering from hub VNet. So I will keep it disabled. Also we are not posting any virtual network gateway. So I will not allow gateway transit. Neither this VNet is going to use peered virtual network gateway. So remote gateway transit is also not required here. So we will keep all these three options disabled and then click on ok button.

Azure will start adding virtual network peering. It will take a couple of seconds.

And after some time you can now see in notification that virtual network peering has been added for this virtual network.

Let’s refresh this page. And you can see below that peering has been initiated.

Let’s go back to the virtual network blade and configure peering for our second virtual network prod-vnet2 in the same manner.

• I will name it prod-vnet2.
• Deployment model will be resource manager.
• Virtual network will be prod-vnet1 which is our first virtual network.
• Rest all settings will be default.

And now click on ok.

Azure starts adding this virtual network peering. And after some time a notification appears that virtual network peering has been added.

Let’s go back to this virtual network properties blade and then go to peerings blade. And here you can see that peering status is connected now.

If you ever want to remove this peering then you can go to context menu and select delete here.

Let’s validate peering status of our first virtual network.

And its status is also now connected. So our peering relationship has been established. So theoretically we should now be able to establish communication using IP address. Hostname will still not work because we will have to set up DNS for hostname resolution which we have done in another post on Azure DNS.

Let’s go to our second VM and let’s do a ping test to the private IP address of our first VM once again.

And you can see above that we are receiving response now. And if you try to ping with host name then it still would not work.

Let’s go to our first virtual machine and let’s ping private IP address of our second virtual machine.

And it is pinging. So our peering relationship is established and the two virtual networks are able to connect to each other. But our hostname resolution is still not working. For this we need to configure DNS records. We have discussed about Azure DNS for hostname resolution in detail in our post…

I would recommend going through that post to understand Azure DNS.

Global VNet Peering is used for doing peer across Azure regions. It is not only cross-region, but even cross-subscription.

Some benefits of Global VNet peering includes:

• Private Peering traffic stays on Azure network backbone.
• It provides low latency and high bandwidth VNet region to VNet region connectivity.
• No more VNet to VNet VPN configuration which means no VPN encryption, no gateways, no public internet necessary.
• No downtime setting up Global VNet peering with portal or ARM templates.

There are also limitations on the virtual machine classes that support Global VNet peering.

• We cannot use Global VNet peering to communicate with VIPs of load balancers in another region. VIP communication requires source IP to be on the same VNet as the LB IP.
• We cannot use remote gateways or allow gateway transit.
• VNet Global peerings are not transitive meaning downstream VNets in one region cannot talk with downstream VNets in another region.

We can implement global VNet peering in the same way in which we have implemented peering previously.

So I have two virtual networks in my subscription. One of my virtual networks is “west-vnet” which is in resource group pracapproach and it is deployed in West India location. My second virtual network is “south-vnet” which is in the same resource group pracapproach but it is deployed in a different location which is South India.

So these two virtual networks are deployed in different geographical locations. Let’s see how we can add a global VNet peering relationship between them to establish communication.

Go to the properties blade of west vnet and click on peerings tab. The peerings blade will open on the right hand side. Click on add button at the top.

An add peering blade appears which we have seen earlier also. I will assign it a name west-south. Deployment manager will be resource manager.

And its virtual network will be south-vnet with which we want to establish peering relationship.

Let’s go ahead and click on ok. Azure will start adding virtual network peering. In couple of seconds the virtual network peering will be added and you will receive a notification. Once peering has been added let’s again go to the peering blade of the same virtual network. And you can now see that the peering status for this virtual network is initiated.

Now we need to add peering relationship for our second virtual network to change its status from initiated to connected. Let’s open virtual network blade once again and go to the properties blade of south-vnet and once again click on peerings tab and then click on “Add” button.

And I will give it a name south-west. Deployment model will be resource manager.

And in virtual network I will select west-vnet. Click on OK.

In just couple of seconds azure added virtual network peering.

Let’s again go to virtual network. Open the properties blade of south-vnet and go to peerings tab. And you can now see that the peering status is now connected.

And if you go to the properties blade of west-vnet and then go to the peerings tab again. Then for this VNet also you can see that the peering status has changed to connected.

So this is how we set global VNet peering.

The process to establish global VNet peering relationship is almost identical to the way we used earlier to establish peering relationship.

So this is how we can connect multiple virtual networks using Peering. I hope this post was helpful and you liked it.

If you like this post, then do not forget to share this post with your friends and subscribe to our newsletter so that you can receive timely update whenever we publish any new post.

Originally published at https://toptechnotes.com on April 5, 2022.