In this post I explain the configuration options available when configuring Virtual Network Peering in Azure. The post will mention Azure Virtual Networks, Azure VPN Gateway, Network Security Groups, Network Service Tags and User Defined Routes, however, these features will not be covered in this post. You can click the embedded links to learn more. The aim of this post is to explain the Virtual Network Peering configuration options only.
When configuring VNET (Virtual Network) peering in the Azure Portal, we come across the options below and we’ll take a look at the purpose of each one.
In my demo, I have named my Virtual Networks VNET1, VNET2 and VNET3.
Configuration option 1: Allow ‘VNET1’ to access ‘VNET2’
Explanation:
This option is enabled by default and allows resources in VNET1 to communicate with resources in VNET2 over the Microsoft private network. If you disable this default option, resources in VNET1 cannot communicate with resources in VNET2, you’re basically disabling communication between the VNET’s.
Note: If you’re using Network Security Groups (NSG) which are used to allow and deny inbound and outbound traffic, the default VirtualNetwork service tag inside a Network Security Group (NSG) allows Virtual Network and peered traffic by default, therefore, communication between VNET1 and VNET2 could be blocked if you deny the default traffic inside an Network Security Group (NSG).
Configuration option 2: Allow ‘VNET1’ to receive forwarded traffic from ‘VNET2’
Explanation:
This option is not enabled by default.
To explain the purpose of this configuration I have drawn a diagram. In the drawing below VNET1 is peered to VNET2 and VNET2 is peered to VNET3.
If we enable this option on VNET1 (Allow ‘VNET1’ to receive forwarded traffic from ‘VNET2’), this means that VNET1 can receive traffic from VNET3. The traffic which flows through an NVA (Network Virtual Appliance) deployed in VNET2 is forwarded from VNET2 to VNET1. The blue line below represents traffic from VNET3 flowing through the NVA located in VNET2 and forwarded to VNET1.
Note: this option is only enabling the capability and does not automatically create an Network Virtual Appliance (NVA) or a User Defined Route (UDR) for you. You will need to create these as separate tasks.
I’ll be covering the last two options (options 3 and 4) together as they relate to each other.
Configuration option 3: Allow gateway in ‘VNET2’ to forward traffic to ‘VNET1’
Note: This option is enabled on VNET2 settings as shown in the image below
Configuration option 4: Enable ‘VNET1’ to use ‘VNET2’s’ remote gateway
Note: This option is enabled on VNET1 settings as shown in the image below
Explanation:
Both options are not selected by default.
Firstly, Option 4 (Enable ‘VNET1’ to use ‘VNET2’s’ remote gateway can only be enabled if ‘VNET2′ has a remote gateway. By enabling this option we are allowing VNET1 to use the remote gateway in VNET2’. Let’s dig deeper to understand this further.
You would enable this option if you have implemented a Gateway and required traffic to flow through this appliance. For example, VNET2, the Virtual Network you’re peering with has a Azure VPN gateway that enables communication to an on-premises network. You would need to enable this option to instruct VNET1 to use the VPN gateway (located in VNET2) if traffic needs to flow to on-premises. A user defined route would need to be created to facilitate the communication alongside this option. A User Defined Route (UDR) is not automatically created.
Once the above configuration is enabled, there is another requirement. This is where Option 3 comes in. However, we don’t enable this option in the configuration of VNET1, but it’s configured in VNET2 settings. Let me explain further below.
When we create a VNET peering, the peering wizard in the portal creates two VNET peering’s. One from VNET1 to VNET2 and one back from VNET2 to VNET1. As shown in the image below. There are two peering link names.
In this example, lets assume that a Azure VPN Gateway has been deployed in VNET2, which is the virtual appliance connecting to our on-premises network. Because the VPN Gateway resides in VNET2, I would configure the option, ‘Enable ‘VNET1’ to use ‘VNET2’s’ remote gateway’ in VNET1 settings. That’s where the first arrow in the image below points to.
In VNET2 settings which is peering back to VNET1, I configure the option, ‘Allow gateway in ‘VNET2’ to forward traffic to ‘VNET1’. This setting will allow ‘VNET1’ to receive forwarded traffic from ‘VNET2’s’ VPN gateway. Again, a reminder that ‘VNET2’ must contain a gateway in order for this option to be enabled.
Now, if resources in VNET1 required to communicate with the on-premises network, the traffic from VNET1 would be allowed to flow through the VPN Gateway located in VNET2 and down to on-premises. And traffic flowing from the VPN Gateway located in VNET2 would be able to communicate with resources in VNET1 forwarded through the VPN Gateway, for example traffic coming from on-premises, Site-to-Site (S2S) or a Point-to-Site (P2S) VPN could flow through the VPN Gateway and access VNET1. As mentioned earlier you would still need to create a User Defined Route (UDR) to route the traffic accordingly. Let me demonstrate this via a diagram below.
The diagram below shows,
– The option ‘Allow gateway in ‘VNET2′ to forward traffic to VNET1’ enabled on VNET2
– The option ‘Enable ‘VNET1’ to use ‘VNET2’s’ remote gateway configured’ enabled on VNET1
The diagram shows that traffic flowing from on-premises or a Point-to-site (P2S) VPN through the Azure VPN Gateway located in VNET2 could reach VNET1 if needed, and traffic from VNET1 could use the VPNGateway in VNET2 to reach on-premises.
I hope the above drawings and explanations help. If you have any questions or feedback please feel free to comment below. See you at the next post. Thanks for tuning in.
