In May 2023, we announced the general availability of Routing intent and routing policies for all Virtual WAN customers. This feature is powered by the Virtual WAN routing infrastructure and enables Azure Firewall customers to set up policies for private and internet traffic. We are also extending the same routing capabilities to all Firewall solutions deployed within Azure Virtual WAN including Network Virtual Appliances and software-as-a-service (SaaS) solutions that provide Firewall capabilities.
Routing Intent also completes two secured hub use cases wherein users can secure traffic between Virtual WAN hubs as well as inspect traffic between different on-premises (branch/ExpressRoute/SD-WAN) that transits through Virtual WAN hubs.
Azure Virtual WAN (vWAN), networking-as-a-service, brings networking, security, and routing functionalities together to simplify networking in Azure. 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.
In this blog, we will first describe routing intent use cases, product experiences, and summarize with some additional considerations and resources for using routing intent with Virtual WAN.
Use cases for Virtual WAN
You can use Routing Intent to engineer traffic within Virtual WAN in multiple ways. Here are the main use cases:
Apply routing policies for Virtual Networks and on-premises
Customers implementing hub-and-spoke network architectures with large numbers of routes often find their networks hard to understand, maintain, and troubleshoot. In Virtual WAN, these routes can be simplified for traffic between Azure Virtual Networks and on-premises (ExpressRoute, VPN, and SD-WAN).
Virtual WAN makes this easier for customers by allowing customers to configure simple and declarative private routing policies. It is assumed that private routing policies will be applied for all Azure Virtual Networks and on-premises networks connected to Virtual WAN. Further customizations for Virtual Network and on-premises prefixes are currently not supported. Private routing policies instruct Virtual WAN to program the underlying Virtual WAN routing infrastructure to enable transit between two different on-premises (1) via a security solution deployed in the Virtual Hub. It also enables traffic transiting between two Azure Virtual Networks (2) or between an Azure Virtual Network and an on-premises endpoint (3) via a security solution deployed in the Virtual Hub. The same traffic use cases are supported for Azure Firewall, Network Virtual Appliances, and software-as-a-service solutions deployed in the hub.
Figure 1: Diagram of a Virtual Hub showing sample private traffic flows (between on-premises and Azure).
Apply routing policies for internet traffic
Virtual WAN lets you set up routing policies for internet traffic in order to advertise a default (0.0.0.0/0) route to your Azure Virtual Networks and on-premises. Internet traffic routing configurations allow you to configure Azure Virtual Networks and on-premises networks to send internet outbound traffic (1) to security appliances in the hub. You can also leverage Destination-Network Address Translation (DNAT) features of your security appliance if you want to provide external users access to applications in an Azure Virtual Network or on-premises (2).
Figure 2: Diagram of a Virtual Hub showing internet outbound and inbound DNAT traffic flows.
Apply routing policies for inter-hub cross-region traffic
Virtual WAN automatically deploys all Virtual Hubs across your Virtual WAN in a full mesh, providing zero-touch any-to-any connectivity region-to-region and hub-to-hub using the Microsoft global backbone. Routing policies program Virtual WAN to inspect inter-hub and inter-region traffic between two Azure Virtual Networks (1), between two on-premises (2), and between Azure Virtual Networks and on-premises (3) connected to different hubs. Every packet entering or leaving the hub is routed to the security solution deployed in the Virtual Hub before being routed to its final destination.
Figure 3: Diagram of inter-region and inter-hub traffic flows inspected by security solutions in the hub.
User experience for routing intent
To use routing intent, navigate to your Virtual WAN hub. Under Routing, select Routing Intent and routing policies.
Configure an Internet or Private Routing Policy to send traffic to a security solution deployed in the hub by selecting the next hop type (Azure Firewall, Network Virtual Appliance, or SaaS solution) and corresponding next hop resource.
Figure 4: Example configuration of routing intent with both Private and Internet routing policy in Virtual WAN Portal.
Azure Firewall customers can also configure routing intent using Azure Firewall Manager by enabling the ‘inter-hub’ setting.
Figure 5: Enabling Routing Intent through Azure Firewall Manager.
After configuring routing intent, you can view the effective routes of the security solution by navigating to your Virtual Hub, then select Routing, and click Effective Routes. The effective routes of the security solution provide additional visibility to troubleshoot how Virtual WAN routes traffic that has been inspected by the Virtual hub’s security solution.
Figure 6: View of getting the effective routes on a security solution deployed in the hub.
Before you get started with this feature, here are some key considerations:
1. The feature caters to users that consider Virtual Network and on-premises traffic as private traffic. Virtual WAN applies private routing policies to all Virtual Networks and on-premises traffic.
2. Routing intent is mutually exclusive with custom routing and static routes in the ‘defaultRouteTable’ pointing to Network Virtual Appliance (NVA) deployed in a Virtual Network spoke connected to Virtual WAN. As a result, use cases where users are using custom route tables or NVA-in-spoke use cases are not applicable.
3. Routing Intent advertises prefixes corresponding to all connections to Virtual WAN towards on-premises networks. Users may use Route Maps to summarize and aggregate routes and filter based on defined match conditions.
Source: microsoft.com
Posts
0 comments:
Post a Comment