Virtual Wan Traffic Flow Scenarios

 

This guide offers an exploration of the essential elements related to vWAN traffic flows, including their significance in shaping flow topology patterns. At the heart of the vWAN branch architecture lie pivotal components such as VPN, SD-WAN, and ExpressRoute. Within the vHub ecosystem, the routing instances hold the crucial role in managing traffic flows, employing BGP for communication. These routing instances, concealed from the end user within the vHub, serve as the linchpin of the vWAN system. The routing instances bear the responsibility of intercepting and directing traffic flows, ensuring the smooth transmission of data packets. If packet flow inspection is also required, these can be aided by an Azure Firewall (AzFW) or Network Virtual Appliance (NVA) inside the vHub. The moment an NVA or AzFW is incorporated into the vHub, they gain control over the data plane packet interception. To enable this inspection, Routing Intent must be enabled on multi-vhub scenarios, or Private/Internet Traffic must be enabled via Firewall policy if an Azure Firewall is deployed within the vHub(s). The subsequent diagrams offer a pictorial depiction of the various flow patterns observed for single and multiple hubs within the vWAN infrastructure. The intent of this article is to provide a more detailed depiction of flow patterns than currently available in the Azure public documents, vWAN Flow Patterns. Understanding the flows and components involved in vWAN pricing is also essential, and this can help explain how vWAN pricing works. For details on vWAN pricing, please refer to the vWAN Pricing Page

 

Single vWAN Hub

 

Traffic Flows	Traffic Flow Paths
Flow A	Spoke VM-->Routing Instances-->Spoke VM
Flow B	Spoke VM-->vHub VPN-->Branch VPN Concentrator
Flow C	Spoke VM-->MSEE IP-->Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)
Flow D	Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->Spoke VM
Flow E	Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->vHub VPN Gateway-->Branch VPN Concentrator
Flow F	Branch VPN Concentrator-->vHub VPN--->MSEE IP-->Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)

 

Quick Take-Aways

In the aforementioned flow paths, it's pertinent to note that the Virtual Private Network (VPN) can be substituted with a Software-Defined Wide Area Network (SD-WAN) tunnels to yield identical results in the diagram above. If either an Azure Firewall or Network Virtual Appliance (NVA) is deployed within the virtual hub (vHub), they will intercept packets in lieu of the route service's Virtual IP (VIP), granted that Routing Intent is activated, or Private/Internet security via Azure Firewall policy on a single vHub!

During operations within a single vHub, it's important to realize that flows to and from branches, whether via IPSEC, SD-WAN, or ExpressRoute, do not traverse the route service instances. Instead, this pattern is only observed in Spoke to Spoke flows, which contributes towards the vHub infrastructure limit, currently capped at 50Gbps per vHub, For additional details, please refer to the linked resource. Lastly, it should be mentioned that Branch to Branch flows also bypass the route service instances.

 

Multiple vWAN Hubs

 

Traffic Flows	Traffic Flow Paths
Flow A	Spoke VM-->Routing Instances-->Remote Routing Instances-->Remote Spoke VM
Flow B	Spoke VM-->Routing Instances--->Remote vhub VPN-->Remote Branch VPN Concentrator
Flow C	Spoke VM-->Routing Instances-->Remote MSEE IP--->Remote Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)
Flow D	Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->Remote Routing Instances-->Remote Spoke VM
Flow E	Branch Customer Edge (CE)-->MSEE IP-->ExpressRoute GW-->Remote vHub VPN GW-->Remote Branch VPN Concentrator
Flow F	Branch VPN Concentrator-->Remote MSEE IP-->Remote Branch Customer Edge (CE) (Egress flows for ExR bypass the ExR GW!)

 

The same principles apply to multiple vHubs in terms of SD-WAN tunnels and Azure Firewall/NVA behavior as they do a single vHub.

In the flow patterns for multiple vHubs, we note that Spoke-to-Spoke communication across hubs invariably involves the routing instances. Traffic moving from Spoke to Branch and vice versa also traverses a single set of routing instances. However, Branch-to-Branch traffic does not pass through the routing instances, just like single vHub behavior.

 

I hoped this guide helped shed more light on the comprehension of packet flow dynamics within the services employed in vWAN. Armed with this understanding, users are enabled to make informed decisions regarding the infrastructure units, in terms of (Gbps), that should be allocated to each respective vHub, and also the size of their branch gateways (VPN/ExpressRoute) and SD-WAN devices.