Virtual WAN architecture optimized for department-specific requirements

A global manufacturing company provided the architecture that this article describes. The company's operational technology and information technology departments are highly integrated, demanding a single internal network. But the environments have drastically different security and performance requirements. Because of the sensitive nature of the company's operations, all traffic needs to be firewall protected by a network virtual appliance (NVA) the customer hosts on their own virtual machines and an Intrusion Detection and Protection System (IDPS) solution needs to be in place. The information technology department has less demanding security requirements for the network, but that department wants to optimize for performance, so users have low-latency access to IT applications.

Decision makers at the company turned to Azure Virtual WAN to meet global needs for a single network with varying security and performance requirements. They also got a solution that's easy to manage, deploy, and scale. As they add regions, they can continue to grow seamlessly with a network that's highly optimized for their needs.

Potential use cases

Typical use cases for this architecture include:

• A global organization that requires a centralized file solution for business-critical work.
• High-performing file workloads that require localized cached files.
• A flexible remote workforce for users both in and out of the office.
• A requirement to use self-hosted NVAs.

Architecture

Download a Visio file of this architecture.

Here's a summary of the architecture:

• Users access virtual networks from a branch.
• Azure ExpressRoute extends the on-premises networks into the Microsoft cloud over a private connection, with the help of a connectivity provider.
• A Virtual WAN hub routes traffic appropriately for security or performance. The hub contains various service endpoints to enable connectivity.
• User-defined routes force traffic to the NVAs when necessary.
• Each NVA inspects traffic that's flowing into a virtual network.
• Virtual network peering provides VNet-to-VNet inspection in the performance-optimized environment.

The company has multiple regions and continues to deploy regions to the model. The company deploys a security-optimized or performance-optimized environment only when needed. The environments route the following traffic through the network virtual appliance (NVA):

Traffic pathways

As the preceding diagram shows, an NVA and routing architecture force all traffic pathways in the security-optimized environment to use the NVA between the virtual networks and the hub in a common layered architecture.

The performance-optimized environment has a more customized routing schema. This schema provides a firewall and traffic inspection where they're needed. It doesn't provide a firewall where it's not needed. VNet-to-VNet traffic in the performance-optimized space is forced through NVA2, but branch-to-VNet traffic can go directly across the hub. Likewise, anything headed to the secure environment doesn't need to go to NVA VNet2 because it's inspected at the edge of the secure environment by the NVA in NVA VNet1. The result is high-speed access to the branch. The architecture still provides VNet-to-VNet inspection in the performance-optimized environment. This isn't necessary for all customers but can be accomplished through the peerings that you can see in the architecture.

Associations and propagations of the Virtual WAN hub

Configure routes for the Virtual WAN hub as follows:

Routing requirements

• A custom route on the default route table in the Virtual WAN hub to route all traffic for VNet1 and VNet2 to secOptConnection.

  Route name	Destination type	Destination prefix	Next hop	Next hop IP
  Security optimized route	CIDR	10.1.0.0/16	secOptConnection	<IP address of NVA1>

• A static route on the secOptConnection forwarding the traffic for VNet1 and VNet2 to the IP address of NVA1.

  Name	Address prefix	Next hop type	Next hop IP address
  rt-to-secOptimized	10.1.0.0/16	Virtual appliance	<IP address of NVA1>

• A custom route table on the Virtual WAN hub that's named perfOptimizedRouteTable. This table is used to ensure the performance-optimized virtual networks can't communicate with each other over the hub and must use the peering to NVA VNet2.

• A UDR associated with all subnets in VNet1 and VNet2 to route all traffic back to NVA1.

  Name	Address prefix	Next hop type	Next hop IP address
  rt-all	0.0.0.0/0	Virtual appliance	<IP address of NVA1>

• A UDR associated with all subnets in VNet3 and VNet4 to route VNet-to-VNet traffic and internet traffic to NVA2.

  Name	Address prefix	Next hop type	Next hop IP address
  rt-to-internet	0.0.0.0/0	Virtual appliance	<IP of address NVA2>
  vnet-to-vnet	10.2.0.0/16	Virtual appliance	<IP address of NVA2>

Components

• Azure Virtual WAN. Virtual WAN is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface. In this case, it simplifies and scales routing to the attached virtual networks and branches.
• Azure ExpressRoute. ExpressRoute extends on-premises networks into the Microsoft cloud over a private connection.
• Azure Virtual Network. Virtual Network is the fundamental building block for your private network in Azure. Virtual Network enables many types of Azure resources, like Azure virtual machines (VMs), to communicate with improved security with each other, the internet, and on-premises networks.
• Virtual WAN hub. A virtual hub is a virtual network that Microsoft manages. The hub contains various service endpoints to enable connectivity.
• Hub virtual network connections. The hub virtual network connection resource connects the hub seamlessly to your virtual networks.
• Static routes. Static routes provide a mechanism for steering traffic through a next hop IP.
• Hub route tables. You can create a virtual hub route and apply the route to the virtual hub route table.
• Virtual network peering. By using virtual network peering, you can seamlessly connect two or more virtual networks in Azure.
• User-defined routes. User-defined routes are static routes that override the default Azure system routes or add more routes to a subnet's route table. They're used here to force traffic to the NVAs when necessary.
• Network virtual appliances. Network virtual appliances are marketplace-offered network appliances. In this case, the company deployed Palo Alto's NVA, but any NVA firewall would work here.

Alternatives

If self-hosting NVAs is not a requirement, a simpler solution exists where the NVA is hosted in an Azure VWAN secured hub and internal traffic inspection is modified for each virtual network connection. However, this solution does not allow you to discriminate between vnet-to-vnet and vnet-to-cross-premises traffic.

To deploy only a high-security NVA environment, you can follow this model: Route traffic through an NVA.

To deploy a custom NVA model that supports both routing traffic to a dedicated firewall for the internet and routing branch traffic over an NVA, see Route traffic through NVAs by using custom settings.

The previous alternative deploys a high-security environment behind an NVA and offers some capability to deploy a custom environment. But it differs from the use case described in this article in two ways. First, it shows the two models in isolation instead of in combination. Second, it doesn't support VNet-to-VNet traffic in the custom environment (what we call the Performance-optimized environment here).

Considerations

In this deployment, routes that cross the Virtual WAN hub to a performance-optimized environment don't pass through the NVA in that environment. This presents a potential problem with cross-regional traffic that's illustrated here:

Traffic across regions between performance-optimized environments doesn't cross the NVA. This is a limitation of directly routing hub traffic to the virtual networks.

Availability

Virtual WAN is a highly available networking service. You can set up more connectivity or paths from the branch to get multiple pathways to the Virtual WAN service. But you don't need anything additional within the VWAN service.

You should set up NVAs in a highly available architecture similar to the one described here: Deploy highly available NVAs.

Performance

This solution optimizes performance of the network where necessary. You can modify the routing according to your own requirements, enabling the traffic to the branch to cross the NVA and the traffic between virtual networks to flow freely or to use a single firewall for internet egress.

Scalability

This architecture is scalable across regions. Consider your requirements when you set up routing labels for grouping routes and branch traffic forwarding between the virtual hubs.

Security

With NVAs, you can use features like IDPS with Virtual WAN.

Resiliency

For information about resiliency, see Availability, earlier in this article.

Cost optimization

Pricing for this architecture depends heavily on the NVAs that you deploy. For a 2-Gbps ER connection and a Virtual WAN hub that processes 10 TB per month, see this pricing estimate.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal author:

• John Poetzinger | Senior Cloud Solution Architect

Next steps

• What is Azure Virtual WAN?
• What is Azure ExpressRoute?
• How to configure virtual hub routing - Azure Virtual WAN
• Firewall and Application Gateway for virtual networks
• Azure Virtual WAN and supporting remote work

Related resources

• Hub-spoke network topology with Azure Virtual WAN
• Choose between virtual network peering and VPN gateways
• Low-latency network connections for industry