How to extend peering with User-Defined Routes (UDRs) and Service Chaining

Extending VNet Peering with User-Defined Routes (UDRs) and Service Chaining enables advanced traffic management and network customization.

This guide explains how to implement these features effectively.

Key Concepts

VNet Peering

• Direct connectivity between VNets in Azure, enabling seamless communication.

User-Defined Routes (UDRs)

• Custom routing rules to override Azure's default system routes.

• Direct traffic to specific destinations, such as a Network Virtual Appliance (NVA).

Service Chaining

• Redirect traffic through an intermediary service or resource, such as a firewall or an NVA, for inspection or processing before it reaches its destination.

Prerequisites

1. VNet Peering Configured

Ensure VNets are already peered, and communication between them is functional.

2. Network Virtual Appliance (Optional)

Deploy an NVA, such as an Azure Firewall, a third-party firewall, or a custom solution, if service chaining is needed.

3. Permissions

Ensure you have the Network Contributor role for the VNets.

Configuring User-Defined Routes (UDRs)

Step 1: Create a Route Table

1. Navigate to Azure Portal → Route Tables → + Create.

2. Configure:

   • Name: Example, SpokeRouteTable.

   • Region: Match the region of the VNet where it will be applied.

3. Attach the route table to a subnet:

   • Under the Subnets tab, click + Associate and select the appropriate subnet.

Step 2: Add Routes

1. In the route table, click Routes → + Add.

2. Define a route:

   • Name: E.g., RouteToNVA.

   • Address Prefix: The destination IP range (e.g., 10.1.0.0/16 for the peer VNet).

   • Next Hop Type:

     • Select Virtual Appliance for NVAs.

     • Provide the Next Hop Address (e.g., the private IP of the NVA).

   • For Service Chaining: Use the NVA IP.

3. Save the route.

Extending VNet Peering with UDRs

Scenario: Routing Traffic Through a Centralized Firewall

1. Architecture

• Hub VNet: Contains the NVA (e.g., Azure Firewall).

• Spoke VNets: Use peering to connect to the hub.

2. Steps

Configure Gateway Transit (if applicable):

• Enable Allow Gateway Transit in the hub VNet.

• Enable Use Remote Gateways in the spoke VNets.

Apply Route Tables:

• Associate UDRs with the subnets in the spoke VNets.

• Direct traffic destined for other VNets or on-premises networks through the NVA in the hub.

Service Chaining with VNet Peering

Purpose

Redirect traffic through an NVA for inspection, transformation, or additional processing before reaching the final destination.

Steps

1. Deploy the NVA

• Place the NVA in the Hub VNet on a dedicated subnet.

• Assign a static private IP to the NVA.

2. Configure Routes

• Create a UDR in the spoke VNet subnets.

• Set the NVA's private IP as the Next Hop.

3. Enable Forwarded Traffic

• In the peering configuration, enable Allow Forwarded Traffic for both VNets.

4. Validate and Test

• Deploy VMs in the spoke VNets.

• Test traffic redirection using tools like tracert or ping.

Use Case Example: Hub-and-Spoke with Service Chaining

Architecture

Hub VNet

Contains Azure Firewall (NVA) in a dedicated subnet.

Spoke VNets

Applications and workloads reside in spoke VNets.

Traffic Flow

1. Traffic from Spoke VNet 1 destined for Spoke VNet 2 is redirected to the hub.

2. The hub processes traffic through the NVA (e.g., performs firewall checks or logging).

3. Traffic is forwarded to Spoke VNet 2.

Configuration Summary

1. Peering between hub and spoke VNets.

2. UDRs in spoke VNets redirect traffic to the NVA in the hub.

3. Allow Forwarded Traffic in the peering settings.

Verification

Check Effective Routes:

1. Navigate to Network Watcher → Effective Routes.

2. Select the subnet or NIC to verify if the UDR is applied correctly.

Test Traffic Flow:

1. Deploy test VMs in each subnet.

2. Use tools like traceroute to confirm traffic is redirected via the NVA.

Troubleshooting

1. UDR Not Working

• Ensure the route table is associated with the correct subnet.

• Check for conflicts with Azure's system routes.

2. Service Chaining Issues

• Verify that Allow Forwarded Traffic is enabled in peering settings.

• Check the NVA configuration (e.g., IP forwarding is enabled).

3. Connectivity Issues

• Confirm that NSGs allow traffic to and from the NVA.

• Validate peering connections are in the Connected state.

Best Practices

1. Minimize Overlapping IP Ranges

Ensure VNets have unique CIDR blocks to prevent routing conflicts.

2. Centralize Security

Use a hub VNet with a centralized NVA to simplify management and enforcement.

3. Monitor Routes

Use Azure Monitor and Network Watcher to track traffic patterns and validate routing.

4. Use Managed Solutions

Consider Azure Firewall for built-in scalability, logging, and rule management.

This approach ensures scalability and flexibility while maintaining centralized traffic control and security.