Ever wonder how to tell your packets to take the scenic route through your security stack instead of bolting straight to the internet? That’s where NVAs and Azure routing step in. Whether you’re centralising inspection or shaping network flows, understanding next hops and the power of User Defined Routes (UDRs) is what keeps your Azure environment secure and predictable.

If you missed our intro to routing and UDRs, check out Azure Route Tables 101 — Controlling Traffic in the Cloud. That post covers the basics: route types, priorities, and the ins and outs of custom routes. In this one, we’re building on that foundation — applying UDRs to route traffic through a network security stack using Network Virtual Appliances (NVAs) or Azure Firewall.

Imagine your network traffic like a fleet of delivery vans. By default, they follow GPS (system routes) and take the shortest path to the destination. But if you’ve got a checkpoint (like a firewall), you’ll want to add some signs — custom routes — to guide them through it. Welcome to routing through NVAs.

What Is an NVA?

A Network Virtual Appliance (NVA) is a virtual machine that performs network-related functions — firewalls, proxy servers, intrusion detection systems, you name it. In Azure, it’s just another VM in a subnet, except instead of serving users, it’s inspecting and controlling traffic flows.

NVAs are commonly used to:

• Enforce centralised firewall policies
• Inspect traffic between on-prem and cloud
• Perform deep packet inspection (e.g., IDS/IPS)
• Proxy internet-bound traffic for logging or threat detection

Common options include third-party firewalls like Palo Alto, Fortinet, Check Point, or even native Azure solutions like Azure Firewall, which behaves like an NVA with cloud-native benefits.

How It Works

Azure sets up system routes automatically, letting your traffic flow between subnets, VNets, on-prem, or the internet. But to redirect traffic through an NVA, you need to override those defaults using User Defined Routes (UDRs).

The key is the “next hop” type. Here’s a quick refresher:

To route through an NVA:

• Create a route with the destination CIDR (e.g. 0.0.0.0/0 for internet)
• Set the next hop to “Virtual Appliance”
• Enter the NVA’s private IP as the next hop address

This gives you full control over east-west or north-south flows.

Real-World Impact

Here’s where this setup shines:

• Centralised security inspection: All traffic from spoke VNets is filtered through a single point in the hub
• Forced tunnelling: Internet-bound packets must pass through an on-premises firewall or cloud-based NVA
• East-West flow control: You can monitor and restrict traffic between subnets or VNets

This approach helps ensure you’re seeing and securing everything — not just trusting default paths.

Architecture: Hub-and-Spoke with Azure Firewall

Let’s say you want all traffic from spoke VMs to be inspected before heading to the internet. You place Azure Firewall in the hub and customise routing to send everything through it.

Key points:

• Spoke VM wants to talk to the internet (or another spoke)
• UDR routes that traffic to Azure Firewall
• Firewall inspects and forwards traffic accordingly

This is how you bring traditional perimeter-style security into your cloud landscape.

Azure Portal Steps

1. Deploy Azure Firewall (or your preferred NVA) into the hub VNet
2. Grab the private IP of the firewall
3. Create a route table:
   • Prefix: 0.0.0.0/0
   • Next hop type: Virtual Appliance
   • Next hop IP: private IP of the firewall
4. Associate that route table with the subnet in your spoke VNet
5. Make sure IP forwarding is enabled on the NVA (not needed for Azure Firewall)
6. Ensure NSGs allow traffic from your source subnet to the firewall

Bicep Example

Here’s a simple Bicep snippet for the UDR setup:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

resource routeTable 'Microsoft.Network/routeTables@2022-09-01' = {
  name: 'spoke-udr'
  location: resourceGroup().location
  properties: {
    routes: [
      {
        name: 'default-to-nva'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.1.0.4' // Make sure this IP has IP forwarding enabled if it’s a custom NVA
        }
      }
    ]
  }
}

// Lookup existing VNET
resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' existing = {
  name: 'MyVNet-01'
}

// Assign the UDR to my spoke subnet
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-02-01' = {
  parent: vnet
  name: 'MySubnet-01'
  properties: {
    addressPrefix: '10.0.1.0/24'
    routeTable: {
      id: routeTable.id
    }
  }
}

Gotchas & Edge Cases

Trying to route through NVAs? Watch out for these:

• IP Forwarding: NVAs (except Azure Firewall) must have IP forwarding enabled
• Return Path: If return traffic skips the firewall, you’ll get asymmetric routing — and broken flows
• Appliance scaling: If your NVA scales out using VMSS, routing to a single IP becomes tricky. You might need a load balancer or go with Azure Firewall’s native scaling
• VPN/ER conflicts: BGP-advertised routes from on-prem can override your UDRs unless you disable route propagation

Best Practices

• Use Azure Firewall if you’re going all-in on native tooling
• Always enable NSG flow logs — auditability is half the value
• Test routing with az network watcher topologies or diagnostics
• Keep return traffic symmetric, or use Source NAT to ensure replies go back through the firewall
• Tag and document route tables carefully — circular or conflicting routes cause pain

Learn More

• User-defined routes (UDRs) in Azure
• What is Azure Firewall?
• Network Virtual Appliances on a Virtual Network
• Enable IP forwarding for a VM NVA