In this lecture, we'll review creating a virtual WAN and hub. Before we get to that, let's consider options for connecting multiple locations. We'll use North America and Europe for this example. One option is to connect the locations to a central location, East US for this example, with a site-to-site VPN. A VPN encrypts data packets at the source, sends the traffic over the public internet, then decrypts them at the destination. This works, and it's a common way to connect sites as well as connect users to private networks. But it has some downfalls.

First, we are dependent on the public internet to route traffic. There is no control over how the traffic is routed between two points. The packets could be delayed due to congestion at any point, causing high latency, and there is no guarantee if the packets will get routed to the destination at all. Even if there is no issues with the connection, having all traffic in Europe go through North America would be incredibly inefficient. What if two offices in Europe had to transfer data? The speed of light is only so fast and this is an inefficient way to pass traffic. Not to mention potential data sovereignty issues with passing data through a different country. For many organizations, that level of uncertainty on the network is not acceptable.

Another option is a site-to-site VPN or private connection between each location. As we've mentioned previously, a full mesh network becomes nearly unmanageable as sites are added, and a hub and spoke introduces a single point of failure. Also, a hub and spoke does not address the high latency between points in distant offices. Traffic still passes through the hub. Let's design a solution that leverages Azure virtual WAN. In this example, the organization has a mix of on-premises and Azure Cloud resources. There is an office in Europe and another in North America. There is also resources in the East US and West Europe Azure regions. We could, in this instance, create a virtual WAN and a single hub, in say, West Europe, and connect the physical locations with a site-to-site VPN and add the VNets from each region.

This would successfully route traffic between all sites. But you probably see the error with this configuration. We're still relying on the public internet over a long distance for a portion of our traffic. Here's the point. When we're designing a virtual WAN, we want to keep any traffic that's outside the Azure network to a minimum. We only need one hub to connect all the endpoints together, but by doing so, we have some long distances over a public network. This is referred to as the last mile. The last mile is the distance between the endpoint, either a site or user, and the private network. This is often a VPN connection over the internet. We want to keep the last mile as short as possible to limit the potential for congestion or latency and other network errors.

A better design is to use a virtual WAN hub in the regions closest to the remote endpoints. From there, the endpoints connect to the closest hub. A hub-to-hub connection is used to route traffic over the private Azure network, providing transitive routing between all endpoints connected to the hubs. This configuration minimizes the last mile, all traffic to and from the same geography stay in that geography, and we leverage the Azure global network for cross-region connectivity. The hub-to-hub connectivity is automatically established for all hubs that are part of a virtual WAN. For this example, we'll deploy the following configuration. We have one virtual WAN located in the East US region. We have two resources to connect to the virtual WAN, a VNet located in East US and a remote site located in West Europe.

Now, I don't actually have a site in West Europe. For this example, an Azure Lab located in the West Europe region will be used to simulate a physical location. We'll create two virtual WAN hubs, one in West Europe and one in East US. We'll connect our two locations to each of the hubs using a virtual network connection for the VNet in East US and a site-to-site VPN in West Europe. Once completed, we'll verify connectivity between computers in the two networks.

Here's the information used to configure the lab. Notice there're no overlapping blocks of IP addresses. We have a virtual WAN in the East US region. We also have a VNet and subnet in its own resource group and a VM that we'll test with in another resource group. There's a virtual WAN hub in East US. This is what the North American resources will connect to. For West Europe, we have a VNet and subnet in a resource group. Although this is in Azure, we're using this to simulate an on-premises network. We have a resource group for the VM. This will act as a gateway device and allow us to test connectivity. The Windows server has routing and remote access installed and will act as the site-to-site VPN endpoint. There's also a West Europe hub where we'll add a gateway that the endpoints will connect to. Let's get started by setting up the virtual WAN in the Azure portal.