In general, Virtual Networks (VNets) are quite straight forward. It's an Azure Resource which requires little configuration when deployed. Every VNet has a subnet with an IP range assigned and the connected devices are protected by an NSG.
Another cool feature is VNet peering. You can easily peer a VNet with one or multiple other VNets. The beautiful thing of a VNet is; it just works!
The devices are connected instantly and can communicatie with each other without further configurations required. This includes routing between peered VNets. However, when you are deploying a network for a larger company, with many VNets, and where you want to implement segregation, things might get complex.
Peering with the hub/spoke model
In the traditional approach, or with smaller companies, you probably deploy only a few VNets. And you peer VNets only if connectivity between the VNets is required. All the routing is taken care of by Azure. An all just works fine.
Today's best practice when deploying many VNets - for example for every service or application a separate VNET - is to use the Hub/Spoke model. I won't go into too much details of what a Hub/spoke model is. In short: in a Hub/Spoke architecture you have one main VNet also called the Hub, and many separate VNets, known as the spokes. Naturally, the Spoke VNets are peered with the Hub. Below an image of a Hub/Spoke architecture as provided by Microsoft Docs.
In the hub/spoke architecture best practice would be to connect all the VNets only with the Hub.
Note: you can peer a maximum of 500 VNets with one VNet.
In a hybrid cloud environment, the Hub VNet will be connected with your on-premise environment using a Virtual Network Gateway.
Again, the VNets are connected and the devices can connect each other.
However, things are getting more complicated now. For example in the above image, if you want devices from VNet A to connect with devices in VNet B. The traffic would have to travel from VNet A, via the Hub to VNet B. This is not something in place by default in Azure, and you will have to configure routing.
You could create VNet peering directly between VNet A and VNet B but then you lose the value of the hub/spoke model with no control of which VNets are connected with each other.
Before we deep-dive into the routing, let's have a quick look at VNet peering and it's available configurations.
Virtual Network Peering
Peering is nothing more than connecting two VNets. Even if the IP ranges are completely different.
Peering is created from within one VNet, to a so called 'remote' VNet. The setup also creates a peering from the remote VNet to the VNet. That is why you need to enter the peering configuration twice.
When creating a peering, you have only three options to configure:
Traffic to remote virtual network
Traffic forwarded from remote virtual network
Allow gateway transit
Let's discuss these options.
Traffic to remote virtual network.
The first option "Traffic to remote virtual network" (allow/disable) gives you the option either to allow or to block traffic from the VNet to the peered/remote VNet. The VNet where you initiate the peering is considered the local VNet. Traffic from the remote VNet to the local VNet is still possible.
Microsoft's Description
Select this option if you wish to allow communication between the two virtual networks. This allows the remote virtual network address space to be included as part of the Virtual_Network tag.Traffic forwarded from remote virtual network
The next option is called "Traffic forwarded from remote virtual network" In this sentence, the keyword is the word 'forwarded'. This configuration is not referring to the traffic from the remote VNet to the local VNet, but it's referring specifically to the traffic that is forwarded from a third VNet via the remote VNet to the local VNet.
If we look back at the Hub/Spoke model. If you're configuring peering from VNet A to Hub. Let's consider VNet A as the local VNet and Hub as the remote VNet. Traffic forwarded from the remote VNet is traffic coming from VNet B and forwarded from the Hub VNet into VNet A.
If you choose to block forward traffic from the remote VNet then:
traffic from Hub is allowed into VNet A.
traffic from VNet B via Hub is blocked into VNet A.
Microsoft's Description
This setting allows forwarded traffic from remote virtual network (traffic not originating from inside remote virtual network) into VNETA.Allow Gateway Transit
For this configuration, a little explanation is required.
As mentioned before, Azure has limited default routing. Although routing between two peered VNets or other Azure PaaS/SaaS resources is taken care of by Azure, forwarded traffic via another VNet is not part of the default routing. Traffic simply will not find it's way to the destination. Therefore you will have to configure an alternative way of routing. This can be accomplished with for example a Virtual Network Gateway used for a Site-to-Site VPN. Another option is the Azure Firewall.
If you have a resource capable of routing deployed in the Hub VNet, the option "Allow gateway transit" allows your traffic to be routed by those resources.
Microsoft's Description
Dynamic routes for virtual machines in a virtual network are programmed by virtual network gateways or Route Servers. Additionally, a virtual network gateway routes traffic between on-premises networks and Azure virtual networks. A virtual network gateway can be created for either VPN Gateway or ExpressRoute.You might wonder why this option is available, instead of always turned on by default for routing purposes. It's a security consideration. Generally a Virtual Network Gateway is deployed to connect one or multiple sites with Site-to-Site VPN Connections, or an expressroute. Either with your on-premise environment or with the network of a external partner or supplier.
If you have sensitive data which is not allowed to leave the network, then you should turn off Gateway Transit.
If we look back at the hub/spoke architecture. The Hub VNet is connected with your on-premise network. If we turn off Gateway Transit on the VNet peering between VNet A and hub, and if we turn on Gateway Transit on the VNet peering between VNet B and Hub, then:
traffic from VNet A is blocked to travel from Hub to your on-premise network using the Virtual Network Gateway.
traffic from VNet B is allowed to travel from Hub to your on-premise network using the Virtual Network Gateway.
As mentioned, the same can be accomplished with Azure Firewall. Again, in the Azure Firewall anything can be configured for routing to any destination. Therefore the option to block gateway transit is a security consideration.
Configure Route Tables
How that you have peered the VNets, and allowed the traffic, and allowed Transit Gateway, still the traffic flow between VNet A and VNet B is not taking place. Why? You will have to configure Route Tables in VNet A and VNet B. Although the VNets are peered with the Hub, still you will have to publish routes from VNet A to VNet B to travel via the Virtual Network Gateway. You will have to configure a Route Table within both VNets.
Use VNet Gateway or Azure Firewall?
You might wonder whether you should use the Virtual Network Gateway or Azure Firewall. This depends on your situation. If you Azure Environment is only connected with your on-premise environment, and from a security perspective, all traffic is allowed to travel between Azure and your on-premise network, then you are good with your Virtual Network Gateway dealing with Gateway Transit.
However, if you have a more complex environment, with multiple (external) environments connected. And if your VNets might contain sensitive or private data, you're better of using Azure Firewall. The Azure Firewall has a high manageability allowing you to configure exactly what is, and what is not allowed to transit.
Azure Route Server (Public Preview)
At the moment of writing, Azure Route Server(ARS) is in public preview. You should not use resources in public preview for your production environment.
Azure Route Server is an extension to your Network Virtual Appliance in another location. It will learn the routes from your NVA and apply them in your Azure Virtual Neworks. It will also apply them to your Virtual Machines, and it can share the Azure Default Routes with your Network Virtual Appliance. It's only used for routing to other networks outside your Azure Tenant (on-premise or partners).
Support + troubleshooting
If you find traffic to be blocked but routing is in place, consider using the following Azure Troubleshooting tools:
Effective routes: shows the Azure Route table on your VNet with default routes, VNet routes and User Routes.
Next Hop: shows what the actual next hop is.
Connection Troubleshoot: performs a test from one to another VM and shows the result per hop.
Conclusion
Azure VNets and VNet peering are very powerful functionalities. Azure will handle most of your required routing. No need for manual configurations.
If you want network traffic routed from one VNet, via a peered VNet to another third VNet. Then you will have to consider a solution for routing.
My advise is to go with the Azure Firewall. Azure Firewall is a secure way of managing your routing. Best practice is to let any traffic from one VNet to another network, even another VNet in your subscription, to flow via Azure Firewall. You have good control over traffic flow and manageable from within one place. By default, anything is blocked and you open traffic flow at the port level.
If you have a Virtual Network Gateway deployed in your Hub VNet, connected with your on-premise environment already. And your environment is relatively small with no connections to other partners, you could consider using the VNet Gateway doing your peering. But do realize all traffic flows are open between the VNets and you fully rely on your Network Security Groups.
Comments