Today we are excited to make announcements in multiple areas of Azure Virtual WAN (vWAN), networking as a service that brings networking, security, and routing functionalities together to provide a single operational interface. As enterprises increasingly adopt the cloud while reducing their costs, IT teams looking to consolidate, accelerate, or even revamp their wide area network should consider Azure Virtual WAN. You don’t need to have all these use cases to start using Virtual WAN—you can get started with just one. With ease of use and simplicity built in, vWAN is a one-stop shop to connect, protect, route traffic, and monitor your wide area network.
“Microsoft Azure Virtual WAN is driving outcomes for Accenture. Migrating 250+ corporate networks to Virtual WAN with code-based deployments creates flexible, cheaper, and consistent networks for our customers. We can now easily connect new work sites in hours.”—Conrad Johnson, Cloud Networks Service Director, Accenture.
The following areas have key announcements:
- Remote user connectivity (also known as point-to-site VPN).
- Routing.
- Branch connectivity (also known as site-to-site VPN).
- Private connectivity (also known as ExpressRoute).
- Third-Party Network Virtual Appliance Integrations.
Remote-user connectivity (also known as point-to-site VPN)
Multipool user group support preview
Multipool user group support for remote-user (point-to-site) VPN allows you to assign different IP address pools to connecting users based on their credentials. With this feature, you can segment your remote users into distinct groups, assign each group unique IP addresses and use the assigned IPs to control and restrict access to business-critical applications hosted both in Azure and on-premises.
User groups within a Virtual WAN can be defined based on Azure Active Directory membership, Certificate Common Name domain or custom RADIUS attributes.
In this example, Contoso corporation has three departments, human resources, finance, and engineering. Contoso also has an on-premises datacenter hosting several business applications connected to Virtual WAN via an ExpressRoute circuit. Contoso leverages Azure Active Directory groups and Virtual WAN remote user/point-to-site VPN groups to segment and assigns different IPs to HR, finance, and engineering users.
Contoso then configures Azure Firewall and on-premises Firewall rules to allow each functional department to only access relevant applications. For example, Azure Firewall is configured to restrict access to applications in the HR VNet to HR Users. Likewise, on-premises firewalls are also configured to allow users access to applications based on need.
- To learn more, read about the underlying concepts behind remote-user connectivity and watch a step-by-step tutorial.
Routing
Secure hub routing intent preview
Routing intent and routing policies allow you to simplify securing your Azure Virtual WAN deployments. With a single click, you can send all traffic (including inter-region and branch-to-branch) to be inspected by Azure Firewall or select Next-Generation Firewall (NGFW) Network Virtual Appliances deployed in the virtual WAN hub. Virtual WAN’s router manages this all for you dynamically by using BGP so that you can avoid error-prone configurations.1
Configuring a routing policy on a hub makes that hub a regional security boundary—all traffic entering or leaving that hub will be sent to Azure Firewall or NVA of choice for inspection before being forwarded to its destination. Routing policies allow you to deploy Azure Firewall/NVA as a bump-in-the-wire solution to inspect East-West (VNet-to-VNet, branch-to-branch (ExpressRoute, P2S VPN, S2S VPN), North-South (branch-to-VNet) traffic between resources connected to the same hub and different hubs. Azure Firewall or a Network virtual appliance Firewall can also serve as the egress point for internet traffic for Virtual Networks and on-premises.
- For more information on how to use routing intent and policies, please see how to configure Virtual WAN Hub routing policies.
- For a list of available Next-Generation Firewall (NGFW) NVA’s deployed in the hub and appropriate instructions for deploying and accessing previews, please see our Network Virtual Appliances documentation.
Hub routing preference (HRP) is generally available
When a virtual hub router learns multiple routes across S2S VPN, ER, and SD-WAN NVA connections for a destination route prefix on-premises, the virtual hub router makes routing decisions using a built-in route selection algorithm. Being able to select virtual hub routing preference provides the ability to influence routing decisions in a virtual hub router for traffic flowing towards on-premises.
Hub routing preference gives you more control over your infrastructure by allowing you to select how your traffic is routed when a virtual hub router learns multiple routes across S2S VPN, ER and SD-WAN NVA connections. Hub routing preference provides the ability to select between ExpressRoute, AS Path, and VPN to create your desired traffic flow.
Routes are selected in the following order:
- Select routes with Longest Prefix Match (LPM).
- Prefer static routes over BGP routes.
- Hub routing preference lets you select between ExpressRoute, AS Path, and VPN.
- For more information on hub routing preference, please see Virtual WAN virtual hub routing preference – Preview – Azure Virtual WAN | Microsoft Learn.
Bypass next hop IP for workloads within a spoke VNet connected to the virtual WAN hub generally available
One of Virtual WANs most popular routing use cases is deploying an NVA in a spoke VNet attached to a virtual WAN hub, then routing traffic through the NVA. Bypassing next hop IP for workloads within a spoke VNet connected to the virtual WAN hub lets you deploy and access other resources in the VNet with your NVA without any additional configuration.
Bypassing next hop IP for workloads within a spoke VNet connected to the virtual WAN hub allows you to have greater flexibility in how you deploy NVAs. This feature allows you to deploy NVAs and other workloads into the same VNet without forcing all the traffic through the NVA.
- Learn how to configure virtual hub routing and more about Bypass next hop IP for workloads within a spoke VNet connected to the virtual WAN hub.
Border Gateway Protocol (BGP) Peering with a virtual hub is generally available
BGP Peering with a virtual hub exposes the ability to peer with the virtual hub router directly using the Border Gateway Protocol (BGP) routing protocol. This feature now eliminates the need to configure static routes between a Network Virtual Appliance (NVA) and the virtual hub router.
BGP Peering with a virtual hub enables you to deploy an NVA in a spoke VNet and dynamically exchange routes with your branch and on-premises sites. You can then peer that same NVA with the virtual hub dynamically using BGP. Now you can exchange routes between your branch and the virtual hub without using static routes!
- Read more about BGP peering with a virtual hub on Microsoft Learn.
- Learn how to configure BGP peering to an NVA virtual hub.
Branch connectivity (also known as site-to-site VPN)
BGP dashboard is now generally available
The BGP dashboard provides the ability to monitor BGP peers, advertised routes, and learned routes for your site-to-site VPNs configured to use BGP in one place.
The BGP dashboard provides greater visibility into your branch offices connected to Virtual WAN. You now have the ability to see what routes your branch office is sending to the virtual WAN router, while also seeing what routes the Virtual WAN router is sending to your branch offices.
- See more information on how to monitor S2S VPN BGP routes on the BGP dashboard.
For customers that want to use a non-vWAN VPN gateway, also known as a Virtual Network gateway, which can be used to set up a site-to-site connection within Azure to a Virtual WAN system, the following Virtual WAN–enabled capabilities are worth checking out.
Virtual Network Gateway VPN over ExpressRoute private peering (AZ and non-AZ regions) is generally available
Customers can now use VPN over ExpressRoute private peering connectivity in non-AZ regions. Earlier, this feature was only available for regions having availability zones. The following gateway SKUs can be used for setting up VPN connectivity:
- VpnGw1/2/3/4/5 SKUs with standard public IP for regions with no availability zones
- VpnGw1AZ/2AZ3AZ/4AZ/5AZ SKUs with standard public IP for regions having one or more availability zones
Point-to-site users connecting to a virtual network gateway can use ExpressRoute (via the site-to-site tunnel) to access on-premises resources.
Customers can deploy site-to-site VPN connections over ExpressRoute private peering at the same time as site-to-site VPN connection via the Internet on the same VPN gateway.
Custom traffic selectors (portal)–generally available
Customers may want to set traffic selectors to narrow down address prefixes from both ends of a VPN tunnel. Custom traffic selectors are particularly useful for customers who have large VNet address spaces but want to use one of their subnets for IPsec/IKE negotiation. Customers can add custom traffic selectors when creating a new connection or update an existing connection.
Earlier, we enabled custom traffic selectors using PowerShell. Customers can now also use the portal to set custom traffic selectors on their Virtual Network Gateway VPN connections.
The TrafficSelectorPolicy parameter consists of an array of traffic selectors, with each traffic selector holding a collection of local and remote address ranges in CIDR format.
- See more information on setting up traffic selectors.
High availability for Azure VPN client using secondary profile is generally available
Customers can now use Azure VPN client in Windows to add a secondary gateway preference in their primary gateway configuration. This feature improves connection availability for point-to-site customers by having a pre-configured additional profile. If for some reason, the primary gateway encounters an outage, VPN client will automatically failover to connect with the secondary gateway.
- See more information on Azure VPN client using secondary profile.
Private connectivity (also known as ExpressRoute)
ExpressRoute circuit with visibility of Virtual WAN connection
Previously in Azure Portal, when navigating to an ExpressRoute circuit connected to a Virtual WAN hub, the ExpressRoute circuit’s Connections page did not display the connections to the virtual hub’s ExpressRoute gateway. With this feature, these connections to the virtual hub’s ExpressRoute gateways are now visible.
By displaying these connections to the ExpressRoute gateways in the virtual hub, this feature provides you with more visibility into your Azure architecture. Not only does this enable you to gain a deeper understanding of your topology, but this will allow you to better monitor and troubleshoot your ExpressRoute connectivity.
- Watch a tutorial on how to create an ExpressRoute association to Azure Virtual WAN.
Third-party integrations
Fortinet SDWAN is generally available
We are pleased to announce the general availability of Fortinet SD-WAN in Virtual WAN. Fortinet’s security-driven approach consolidates next-generation Azure Firewall and SD-WAN into a single set of hassle-free solutions to deploy and bootstrap highly available virtual appliances and provide full security inspection at the point of cloud connectivity.
Fortinet SD-WAN dynamically exchanges routes with the Virtual Hub Router using BGP to effortlessly simplify routing between Fortinet SD-WAN branch devices, your applications hosted in Azure Virtual Networks, and services hosted on ExpressRoute-connected on-premises.2
- Find more information about Network Virtual Appliances in Virtual WAN on Microsoft Learn.
- Read more about Fortinet SD-WAN in Virtual WAN.
Aruba EdgeConnect Enterprise SDWAN preview
We are pleased to announce the preview of Aruba EdgeConnect Enterprise SD-WAN solution in Azure Virtual WAN. The Aruba EdgeConnect Enterprise SD-WAN solution delivers optimized, secured, and automated branch connectivity to, and through, Azure.
The Aruba EdgeConnect Enterprise solution provides a fully-automated, scalable, and software-defined experience connecting branch offices and data centers to Azure Virtual WAN with application-aware traffic steering.
- See more on how to deploy the Aruba EdgeConnect Enterprise SD-WAN in Virtual WAN.
- Read about Integrated Network Virtual Appliances in Virtual WAN on Microsoft Learn.
Checkpoint NG Firewall preview
We are pleased to announce the preview of Check Point’s Next-Generation Firewall in Virtual WAN. This deep integration allows you to deploy a Check Point Cloud Guard Network Security (CGNS) NVA in the Virtual WAN hub, which lets you enjoy Check Point capabilities without having to worry about provisioning high availability, bootstrapping, or managing upgrades. A major benefit of this NVA integration is simplified routing, as the NVA peers use BGP with the Virtual WAN hub router, which intelligently handles routing decisions within and across Virtual WAN hubs.
Check Point CGNS provides many next-generation firewall capabilities, such as advanced threat detection to prevent malware attacks. In addition, you can configure Check Point security policies via a single pane of glass with Check Point Security Management.2
- Watch a demo on this integration.
- Read more about the Check Point Azure Virtual WAN security solution announcement.
- Find more information about Integrated Network Virtual Appliances on Microsoft Learn.
We want your feedback
We look forward to continuing to build out Azure Virtual WAN and adding more capabilities in the future. We encourage you to try out Azure Virtual WAN and its new features and look forward to hearing more about your experiences and so we can incorporate your feedback into the product.
Learn more
For additional information, please explore these resources:
1. Support for inter-region traffic inspection is currently rolling out and is available today for a limited set of regions. To learn more, please reach out to previewinterhub@microsoft.com.
2. NGFW use cases for Routing Intent are currently in preview. Please see Routing Intent section above for more details.