If you have multiple virtual networks, then they’ll be isolated from each other by default. There are two ways to connect them: using VNet peering or using a virtual network gateway. VNet peering is by far the easiest method, so we’ll start with that. I’m not going to show you the process of creating the two VNets, though, because I’m assuming you already know how to do that. Just make sure you don’t give them overlapping IP address spaces.

Go into one of the virtual networks in the portal, select Peerings from the menu, and click Add. Give it a name. I’ll use the name of the first virtual network dash and the name of the second virtual network. Then choose the subscription where the second virtual network resides, and finally, choose the second VNet. To complete the connection, you also need to create a peering in the other direction in the second virtual network. 

“Allow virtual network access” is enabled, which is what we want. Otherwise, the peering wouldn’t allow traffic between the VNets, which would make it kind of useless. There are a few other configuration options as well, but I’ll tell you more about those later.

Okay, it’s done. The peering from vnet1 to vnet2 is showing a status of “Connected”. Let’s check the second peering as well. It’s connected, too. Once the status of both peerings is “Connected”, instances in the two VNets will be able to communicate with each other as if they were in the same VNet.

You can even do this with virtual networks that are in different regions, which is known as global VNet peering, or across subscriptions. Traffic between them still goes through the Microsoft backbone network rather than through the internet, so the connection is private and has high bandwidth and low latency.

There are a couple of restrictions to keep in mind when you’re designing your networks. First, you can only peer two VNets if they have non-overlapping IP address spaces. That makes sense because otherwise you could end up with duplicate IP addresses, which would wreak havoc on your networks. Also, once you’ve peered two VNets, you can’t add or remove any of their address ranges. The only way to do it is to delete the peerings, make the change, and then create the peerings again.

Another restriction is that peerings are not transitive. That is, even though vnet1 is connected to vnet2 and vnet2 is connected to vnet3, vnet1 is not connected to vnet3. If you do want them to be connected, then there are a couple of ways to do it. 

The most obvious way is to create a peering between vnet1 and vnet3. Although that would work, you may want to use a different method for a couple of reasons. First, if you add more networks to this mesh, then your network topology would get pretty complicated. Second, you might want to have more control over the traffic between networks.

An alternative to peering all of the networks together is to use a hub-and-spoke topology, with the hub acting as a router. In this configuration, the only way for two spokes to communicate with each other is through the hub. One big advantage of this architecture is that you could put shared services in the hub that could be used by all of the spokes. Some examples are firewalls, DNS servers, and intrusion detection systems.

One option for creating a router in the hub network is to deploy a simple Linux VM that can route traffic. To make this work, you also need to add route tables with user-defined routes so the spokes will know to send their external traffic to the hub. In addition, you need to check the “Allow forwarded traffic” option when you’re creating the peerings. This means to allow traffic from the hub VNet that was forwarded from another spoke VNet.

An alternative to deploying a virtual machine as a router is to deploy a virtual network gateway. If you do this, then you’ll still have to create route tables, but instead of checking the “Allow forwarded traffic” option, you’ll have to check the “Allow gateway transit” option on the peering connections from the hub. Then you’ll have to check the “Use remote gateways” option on the peering connections from the spokes to the hub. If you don’t enable both of those settings, then traffic won’t flow through the gateway in the hub.

And that’s it for virtual network peering.