DEV Community

Cover image for Azure Route Server and NVA: Enforcing VNet Traffic - plus Terraform Code
Gergo Vadasz
Gergo Vadasz

Posted on • Originally published at gergovadasz.hu

Azure Route Server and NVA: Enforcing VNet Traffic - plus Terraform Code

#azure #terraform #networking #bgp

I recently discovered some knowledge gaps regarding Azure Route Server (ARS) during a discussion with a cloud architect, so I decided to explore it in depth using my personal lab environment.

 

Lab Topology

The test environment includes:

  • Hub Virtual Network containing both an NVA (Network Virtual Appliance) and Azure Route Server
  • Two Spoke VNets, each peered only with the hub
  • BGP enabled between the NVA and Azure Route Server
  • Spoke-to-spoke traffic routed through the NVA

The goal: understand how Azure Route Server can dynamically manage routing and its advantages over static approaches.

 

Why Use Azure Route Server?

Limitations of Standard VNet Peering

Default VNet peering provides full connectivity but lacks traffic filtering capabilities. Enterprises often require inspection or filtering of inter-VNet traffic.

Traditional Solutions

Traffic can be redirected through:

  • Azure Firewall (Microsoft's native solution)
  • Third-party NVAs: Cisco ASR/ASA, Palo Alto NGFW, FortiGate NGFW, F5 Load Balancer, or Linux VMs running iptables/UFW

Manual implementation requires creating User-Defined Routes (UDRs), assigning next-hop values to the NVA, and updating routes when topology changes. This becomes complex and error-prone — especially in environments with dozens of VNets and subnets.

 

How Azure Route Server Solves This

ARS simplifies routing through dynamic BGP-based route injection:

  • Eliminates manual UDR management — routes learned dynamically from NVAs
  • Automatically updates routes — no manual next-hop modifications needed
  • Scales efficiently — supports multiple NVAs for redundancy
  • Provides high availability — deploys two redundant BGP peering IPs

Once an NVA establishes BGP peering with ARS, learned routes inject automatically into Azure's routing tables. All VNet resources route through the NVA without manual UDRs.

 

Testing Spoke-to-Spoke Routing via the NVA

Lab Configuration

  • Hub VNet hosting NVA and Azure Route Server
  • Spoke VNets peered only with hub (no direct spoke-to-spoke peering)
  • BGP session established between NVA and ARS
  • Spoke-to-spoke traffic constrained through NVA only

Azure Route Server spoke-to-spoke diagram

 

Validation Results

ARS received routes from the NVA, learned routes were injected into spoke VNets, and spoke-to-spoke traffic was successfully routed via NVA.

BGP Neighborship Summary:

nva-test# sh ip bgp summary

IPv4 Unicast Summary (VRF default):
BGP router identifier 10.0.1.4, local AS number 65020 vrf-id 0
BGP table version 6
RIB entries 8, using 1472 bytes of memory
Peers 2, using 1446 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.0.3.4        4      65515       175       160        0    0    0 00:01:37            3        1 N/A
10.0.3.5        4      65515       173       160        0    0    0 00:01:37            3        1 N/A
Enter fullscreen mode Exit fullscreen mode

BGP Routes Table:

nva-test# sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
   10.0.0.0/8       0.0.0.0                  0         32768 i
   10.0.0.0/16      10.0.3.5                               0 65515 i
                    10.0.3.4                               0 65515 i
   10.1.0.0/16      10.0.3.5                               0 65515 i
                    10.0.3.4                               0 65515 i
   10.2.0.0/16      10.0.3.5                               0 65515 i
                    10.0.3.4                               0 65515 i
Enter fullscreen mode Exit fullscreen mode

 

Spoke VNet Route Evidence

Spoke VNet effective routes

 

Connectivity Validation

Ping from spoke 1 to spoke 2:

gergo@spoke1-vm:~$ ping 10.2.1.4
PING 10.2.1.4 (10.2.1.4) 56(84) bytes of data.
64 bytes from 10.2.1.4: icmp_seq=1 ttl=63 time=5.87 ms
64 bytes from 10.2.1.4: icmp_seq=2 ttl=63 time=2.48 ms
Enter fullscreen mode Exit fullscreen mode

Traceroute confirms traffic goes through the NVA:

gergo@spoke1-vm:~$ traceroute 10.2.1.4
traceroute to 10.2.1.4 (10.2.1.4), 30 hops max, 60 byte packets
 1  10.0.1.4 (10.0.1.4)  1.528 ms  1.503 ms  1.490 ms  # NVA IP
 2  10.2.1.4 (10.2.1.4)  2.736 ms *  2.706 ms           # Spoke-02 server
Enter fullscreen mode Exit fullscreen mode

 

Final Thoughts

Azure Route Server is a powerful tool for simplifying routing and enforcing network policies in cloud environments. By leveraging BGP-based dynamic routing, it eliminates manual UDR management, making it ideal for large-scale enterprise hub-and-spoke architectures in Azure.

Have you used Azure Route Server in production? Share your thoughts or challenges in the comments!

The complete Terraform code for this lab is available at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.

Top comments (0)