This chapter covers Network Virtual Appliances (NVAs) in Azure, including their purpose, deployment patterns, and how they integrate with routing and security. NVAs are a key topic for the AZ-104 exam, typically appearing in 5-10% of questions related to networking and hybrid connectivity. Understanding NVAs is critical for scenarios where Azure-native services like Azure Firewall or load balancers are insufficient, especially for advanced traffic inspection, custom routing, or third-party integrations. This chapter will prepare you to design, configure, and troubleshoot NVA deployments for the exam and real-world scenarios.
Jump to a section
Think of an NVA as a private security checkpoint at the entrance of a corporate campus. The campus has multiple buildings (subnets) and a main gate (internet connection). Without a checkpoint, anyone could drive from one building to another or leave the campus without inspection. The checkpoint is a dedicated building with guards (firewall rules) that inspect every vehicle (packet) entering or leaving. Each guard has a list of rules: 'Allow delivery trucks from known carriers only between 8 AM and 6 PM' or 'Block any vehicle with tinted windows (encrypted traffic without inspection)'. When a vehicle approaches, the guard checks the vehicle's license plate (source IP), destination building (destination IP), and cargo (protocol/port). If allowed, the guard opens the gate and logs the passage (flow logs). If denied, the guard turns the vehicle away and records the attempt (deny log). The checkpoint also has a separate lane for internal traffic between buildings — but that traffic is also inspected because guards are stationed at intersections (forced tunneling via UDR). The checkpoint can be scaled by adding more guards (scale set) and can be upgraded to include package scanning (IDS/IPS). In the cloud, this checkpoint is a virtual appliance that intercepts traffic based on user-defined routes, not physical gates. The key difference: the cloud checkpoint can be duplicated across multiple sites (availability zones) and can inspect traffic that never leaves the virtual campus (same VNet), which is impossible in a physical campus without multiple checkpoints.
What is a Network Virtual Appliance (NVA)?
A Network Virtual Appliance (NVA) is a virtual machine (or set of VMs) that performs a network function such as firewall, WAN optimization, intrusion detection/prevention (IDS/IPS), load balancing, or routing. Unlike Azure's platform-as-a-service (PaaS) network services (e.g., Azure Firewall, Application Gateway), NVAs are typically third-party solutions from vendors like Palo Alto Networks, Check Point, Cisco, Fortinet, or Barracuda, deployed as IaaS VMs. They can also be custom-built using open-source software like pfSense or Squid.
NVAs fill gaps where native Azure services lack feature parity. For example, Azure Firewall does not support TLS inspection (decryption), but many NVA offerings do. Similarly, some enterprises require a consistent security policy across on-premises and cloud, which NVAs enable by running the same software stack.
How NVAs Work: Traffic Interception and Routing
An NVA is placed in a virtual network (VNet) and intercepts traffic using User-Defined Routes (UDRs). UDRs override Azure's default system routes. For an NVA to inspect traffic, the route table associated with a subnet must have a route with 'Next hop type' set to 'Virtual appliance' and the 'Next hop IP address' pointing to the NVA's private IP.
Example: To force all internet-bound traffic from a subnet to go through an NVA for inspection, create a route with address prefix '0.0.0.0/0' and next hop IP 10.0.1.100 (NVA's IP). This is called forced tunneling.
For traffic between subnets (east-west), you can create routes for the destination subnet prefixes pointing to the NVA. For example, to force traffic from subnet A (10.0.0.0/24) to subnet B (10.0.1.0/24) through the NVA, add a route with prefix '10.0.1.0/24' and next hop NVA IP.
Key Components and Configuration
NVA VM: Runs the network software. Must have IP forwarding enabled at the OS level (in Windows: netsh interface ipv4 set interface "Ethernet" forwarding=enabled; in Linux: sysctl net.ipv4.ip_forward=1).
NIC: The VM's network interface. Must have 'IP forwarding' enabled in Azure portal or PowerShell ($nic = Get-AzNetworkInterface -Name myNic; $nic.EnableIPForwarding = $true; $nic | Set-AzNetworkInterface).
UDR: A route table associated with the source subnet. Contains routes specifying the NVA's private IP as the next hop.
Public IP: Optional, for internet-facing NVAs. The NVA can have a public IP for inbound traffic from the internet.
Load Balancer: For high availability, multiple NVA instances are placed behind an internal or public load balancer. The UDR points to the load balancer's frontend IP.
Traffic Flow Example: Internet Outbound
A VM in subnet A (10.0.0.0/24) sends a packet to 8.8.8.8.
The source VM checks its routing table. The system route for 0.0.0.0/0 points to the internet by default, but a UDR on subnet A overrides it with next hop 10.0.1.100 (NVA).
The packet is sent to the NVA. The NVA inspects the packet (stateful firewall, IDS, etc.).
If allowed, the NVA performs source NAT (SNAT) to its own public IP (if outbound) and forwards the packet to the internet.
Return traffic arrives at the NVA's public IP, which performs destination NAT (DNAT) and forwards to the original VM.
High Availability and Scaling
Single NVA is a single point of failure. For production, deploy at least two NVAs in an availability set or across availability zones. Use Azure Load Balancer (internal) to distribute traffic. The UDR points to the load balancer's frontend IP. Health probes monitor the NVA instances; if one fails, traffic is sent only to healthy instances.
For active-passive, only one NVA handles traffic; the other is standby. For active-active, both handle traffic, but stateful inspection requires session synchronization between NVAs.
Integration with Azure Services
Azure Firewall vs NVA: Azure Firewall is a managed PaaS service with built-in high availability and auto-scaling. It supports FQDN filtering, threat intelligence, and outbound SNAT. NVAs offer more customization (e.g., TLS inspection, custom IDS signatures).
VPN Gateway: NVAs can be used as VPN endpoints instead of Azure VPN Gateway, offering advanced routing protocols (BGP) and encryption algorithms.
Azure Route Server: Simplifies dynamic routing between NVAs and Azure. It enables BGP peering between NVAs and Azure, automatically propagating routes from NVAs to the VNet. This eliminates the need for static UDRs for complex topologies.
Azure Virtual WAN: Can integrate NVAs as a Network Virtual Appliance in the Virtual Hub, allowing centralized inspection of all branch-to-branch and branch-to-Azure traffic.
Defaults and Timers
UDR propagation: UDRs are applied immediately to new VMs in the subnet, but existing VMs may need a reboot if they cache routes.
Route priority: More specific prefix wins. If two routes have the same prefix, the one with the lower 'next hop type' priority is used (UDR overrides system).
IP forwarding: Must be enabled at both Azure NIC and OS. If not, the NVA drops traffic not destined to its own IP.
Health probes: Load balancer probes default to TCP port 80 every 5 seconds, with 2 consecutive failures marking instance down.
Verification Commands
Check effective routes on a VM:
az network nic show-effective-route-table --resource-group myRG --name myVMNicVerify IP forwarding on NIC:
az network nic show --resource-group myRG --name myNIC --query "enableIpForwarding"Check route table:
az network route-table route list --resource-group myRG --route-table-name myRTCommon Pitfalls
Asymmetric routing: If return traffic from the internet does not go through the NVA, it may be dropped due to stateful inspection. Ensure all traffic (inbound and outbound) is routed symmetrically.
Missing IP forwarding: The most common issue. Without it, the NVA drops packets not addressed to its own IP.
UDR not applied to the correct subnet: Each subnet must have its own route table association.
NVA performance: Single VM may be insufficient for high throughput. Use VM sizes with accelerated networking and multiple vCPUs.
Enable IP Forwarding on NVA NIC
In Azure portal, navigate to the NVA's network interface, select 'IP configurations', and set 'IP forwarding' to Enabled. Alternatively, use PowerShell: `$nic = Get-AzNetworkInterface -Name myNIC -ResourceGroupName myRG; $nic.EnableIPForwarding = $true; $nic | Set-AzNetworkInterface`. At the OS level, enable IP forwarding: on Windows, run `netsh interface ipv4 set interface "Ethernet" forwarding=enabled`; on Linux, set `net.ipv4.ip_forward = 1` in /etc/sysctl.conf and apply with `sysctl -p`. Without both settings, the NVA will drop packets not destined to its own IP.
Create User-Defined Route Table
Create a route table in the same region as the VNet. Add routes with address prefixes for traffic you want to inspect (e.g., 0.0.0.0/0 for internet, or specific subnet ranges for east-west). Set the 'Next hop type' to 'Virtual appliance' and the 'Next hop IP address' to the NVA's private IP (or load balancer frontend IP). Associate the route table with the source subnet(s). For example, to force all outbound traffic from subnet A, add route 0.0.0.0/0 -> NVA IP.
Configure NVA Software for Routing
The NVA must be configured to accept traffic on its internal interface and forward it appropriately. For a firewall NVA, define security rules (allow/deny). For a router NVA, enable routing protocols (e.g., BGP) or static routes. Ensure the NVA has a route back to the source subnet (usually via default gateway). For outbound internet, configure SNAT so return traffic comes back to the NVA. Test connectivity from a source VM to an external destination; if traffic fails, check UDR propagation and NVA logs.
Configure Load Balancer for HA (Optional)
For high availability, deploy two or more NVA instances in an availability set or zones. Create an internal Azure Load Balancer (Standard SKU) with a frontend IP in the same subnet as the NVAs. Configure backend pool with the NVAs. Add health probes (e.g., TCP on port 80) to monitor NVA health. Update the UDR's next hop to the load balancer's frontend IP instead of a single NVA IP. This distributes traffic across healthy NVAs and provides failover.
Verify Traffic Flow and Troubleshoot
After configuration, test traffic from a VM in the source subnet to a destination (e.g., 8.8.8.8). Use `tracert` or `pathping` to see if traffic goes through the NVA's IP. On the NVA, check logs for accepted/denied packets. Use Azure's 'Next hop' diagnostics in Network Watcher to verify the path: select the source VM, destination IP, and see if next hop is the NVA. Common issues: asymmetric routing (fix by ensuring NVA is also the return path), dropped packets due to security rules, or incorrect UDR association.
Enterprise Scenario 1: Centralized Internet Egress with Security Inspection
A multinational corporation migrates its workloads to Azure. They require all outbound internet traffic from VNets to be inspected by a Palo Alto Networks NVA for threat prevention and data loss prevention (DLP). The architecture: each workload VNet has a route table with 0.0.0.0/0 pointing to the NVA's internal load balancer IP (10.0.0.4). The NVA is deployed in a hub VNet (hub-and-spoke topology) with two instances in an availability set behind an internal load balancer. The NVA has a public IP for outbound SNAT. Traffic flows: VM -> NVA (inspection) -> internet. Return traffic comes back to NVA's public IP, which DNATs to the VM. This setup provides consistent security policies across all subscriptions. Performance considerations: each NVM instance (Standard_D8s_v3) can handle ~1 Gbps throughput; for higher throughput, use larger instances or multiple active-active pairs. Common misconfiguration: forgetting to enable IP forwarding on the NVA NIC, causing traffic to be dropped silently. Also, if the NVA's outbound SNAT uses a different public IP than expected, external firewalls may block return traffic (solved by using dedicated public IPs).
Enterprise Scenario 2: East-West Traffic Inspection Between Tiers
A financial services company has a multi-tier application: web tier (subnet A), app tier (subnet B), and database tier (subnet C). They need to inspect all traffic between tiers for compliance (PCI DSS). They deploy a Fortinet NVA in a management subnet. For each source subnet, they create UDRs for the destination subnet prefixes pointing to the NVA's IP. For example, subnet A has a route for 10.0.2.0/24 (subnet B) -> NVA IP. The NVA inspects traffic and applies firewall rules. Since traffic is internal, no SNAT is needed. Asymmetric routing is a risk: if the NVA forwards traffic to subnet B, the return traffic from subnet B to subnet A must also go through the NVA. They add a UDR on subnet B for subnet A's prefix pointing to the same NVA. This ensures symmetric flow. Scaling: for high throughput, they use multiple NVA instances with a load balancer and session synchronization (Fortinet FGCP). Common issue: if the NVA's security rules block legitimate traffic, the application breaks; extensive testing is required before production.
Scenario 3: Hybrid Connectivity with NVA as VPN Endpoint
A company uses an NVA (Cisco CSR 1000v) as a VPN endpoint for site-to-site VPN to on-premises, instead of Azure VPN Gateway. They need BGP for dynamic routing and advanced encryption (AES-256-GCM). The NVA is deployed in a gateway subnet with a public IP. On-premises router peers BGP with the NVA. UDRs are used to direct traffic from on-premises to specific subnets via the NVA. This is common when existing on-premises infrastructure uses Cisco and the team wants consistent management. However, this setup lacks SLA from Microsoft; the NVA's availability is the customer's responsibility. Performance: CSR 1000v supports up to 100 Mbps on smaller instances; for higher throughput, use larger instances or multiple tunnels with ECMP. Misconfiguration: BGP timers mismatch (keepalive 60s vs 10s) can cause flapping; ensure both sides agree.
What AZ-104 Tests on NVAs
The AZ-104 exam covers NVAs under objective 'Configure and manage virtual networking' and 'Configure and manage hybrid networking'. Specific sub-objectives include:
Configure routing: User-defined routes (UDRs), next hop types (Virtual appliance, Internet, None).
Implement forced tunneling: Route 0.0.0.0/0 to NVA.
High availability: Using load balancers with NVAs.
Integration with Azure Firewall: When to choose NVA over Azure Firewall.
IP forwarding: Know that both Azure NIC and OS must have IP forwarding enabled.
Common Wrong Answers and Traps
Choosing 'Virtual network gateway' as next hop type for NVA: Candidates confuse NVA with VPN gateway. The correct next hop type is 'Virtual appliance'. 'Virtual network gateway' is for Azure VPN/ExpressRoute gateways.
Assuming NVAs are PaaS: NVAs are IaaS VMs. Azure Firewall is PaaS. The exam may ask which service is managed (Azure Firewall) vs customer-managed (NVA).
Thinking UDRs automatically apply to all subnets: UDRs must be explicitly associated with each subnet. A common question: 'You create a route table and add routes, but traffic is not going through the NVA. Why?' Answer: The route table is not associated with the subnet.
Forgetting IP forwarding: A scenario where traffic reaches the NVA but is dropped. The candidate might think it's a firewall rule, but the real issue is IP forwarding disabled.
Asymmetric routing not considered: If you force traffic to NVA in one direction but not the other, stateful inspection drops packets. Exam may ask about troubleshooting connectivity issues.
Specific Numbers and Values
Route priority: More specific prefix (longer prefix length) wins. Example: 10.0.0.0/24 overrides 0.0.0.0/0.
Next hop types: VirtualAppliance, Internet, None, VirtualNetworkGateway, VirtualNetwork.
IP forwarding property: Set on NIC via EnableIPForwarding property.
Load balancer health probe: Default interval 5 seconds, threshold 2.
Edge Cases
NVAs in the same subnet as the source VMs: Traffic from a VM to the NVA in the same subnet does not require a UDR because it's directly reachable. However, to force traffic through the NVA for other destinations, UDR is still needed.
NVAs with multiple NICs: For ingress/egress separation, an NVA can have two NICs (one for inbound, one for outbound). Each NIC must have IP forwarding enabled. UDRs point to the appropriate NIC IP.
NVAs and service endpoints: Service endpoints bypass the NVA because they use direct Microsoft backbone. To force traffic through NVA, disable service endpoints or use UDR with next hop Virtual appliance for the service's IP ranges.
How to Eliminate Wrong Answers
If a question mentions 'customer-managed firewall' or 'third-party', it's likely NVA.
If a question asks about 'advanced features like TLS inspection', the answer is NVA (Azure Firewall doesn't support it).
If a question involves 'high availability' and 'load balancer', look for NVA behind load balancer.
If a question asks about 'forced tunneling', the next hop type must be Virtual appliance.
Always check if IP forwarding is mentioned; if not, it's a common oversight.
NVAs are IaaS VMs that perform network functions like firewalling, routing, and inspection.
Traffic is forced through an NVA using User-Defined Routes (UDRs) with next hop type 'Virtual appliance'.
IP forwarding must be enabled on both the Azure NIC and the guest OS for the NVA to forward traffic.
UDRs must be explicitly associated with each subnet; association is not automatic.
For high availability, deploy multiple NVA instances behind an Azure Load Balancer (internal or public).
Common exam trap: forgetting to enable IP forwarding or associate the route table with the correct subnet.
NVAs are chosen over Azure Firewall when advanced features like TLS inspection or custom IDS/IPS are required.
Asymmetric routing is a common issue; ensure return traffic also goes through the NVA.
Azure Route Server can simplify routing by enabling BGP between NVAs and Azure, reducing static UDRs.
NVAs can be used for VPN termination (site-to-site) instead of Azure VPN Gateway, but without Microsoft SLA.
These come up on the exam all the time. Here's how to tell them apart.
Azure Firewall
Fully managed PaaS service by Microsoft
Built-in high availability and auto-scaling
Supports FQDN filtering, threat intelligence, outbound SNAT
Does not support TLS inspection or custom IDS/IPS signatures
Pricing based on data processed and deployment hours
Network Virtual Appliance (NVA)
IaaS VM managed by customer
HA must be configured manually (e.g., load balancer)
Supports advanced features like TLS inspection, custom IDS/IPS, WAN optimization
Allows consistent policy with on-premises (same vendor software)
Pricing based on VM size, licensing, and data transfer
Mistake
NVAs are managed services like Azure Firewall.
Correct
NVAs are IaaS VMs that you deploy, configure, patch, and manage. Azure Firewall is a fully managed PaaS service. The exam distinguishes between customer-managed (NVA) and Microsoft-managed (Azure Firewall) services.
Mistake
Enabling IP forwarding on the Azure NIC is sufficient for the NVA to forward traffic.
Correct
IP forwarding must be enabled in both the Azure NIC (via portal/CLI) and the guest OS (via sysctl or netsh). If OS-level forwarding is disabled, the NVA will drop packets not destined to its own IP.
Mistake
UDRs with next hop type 'Virtual appliance' are automatically applied to all subnets in the VNet.
Correct
UDRs must be explicitly associated with each subnet. A route table can be associated with multiple subnets, but the association is not automatic. Failure to associate is a common exam trap.
Mistake
An NVA can be deployed in any subnet without affecting traffic flow.
Correct
If the NVA is in the same subnet as source VMs, traffic to the NVA itself is direct (no UDR needed), but traffic to other destinations still requires UDRs. Placing NVA in a separate subnet (e.g., 'gateway subnet' or 'DMZ subnet') is best practice for security and manageability.
Mistake
NVAs can only inspect outbound internet traffic.
Correct
NVAs can inspect any traffic: inbound from internet, outbound to internet, east-west between subnets, and hybrid traffic (VPN/ExpressRoute). UDRs can be configured for any address prefix.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Firewall is a fully managed, cloud-native firewall service (PaaS) with built-in high availability and auto-scaling. It supports FQDN filtering, threat intelligence, and outbound SNAT. An NVA is a virtual machine (IaaS) running third-party firewall software (e.g., Palo Alto, Fortinet). NVAs offer more advanced features like TLS inspection, custom IDS/IPS, and consistent policy with on-premises. You manage the NVA's OS and software, while Azure Firewall is managed by Microsoft. For the exam, remember that NVAs are customer-managed and can do things Azure Firewall cannot.
Create a route table and add a route with address prefix 0.0.0.0/0 and next hop type 'Virtual appliance'. Set the next hop IP address to the NVA's private IP (or load balancer frontend IP). Associate this route table with the subnet. Ensure the NVA has IP forwarding enabled and is configured to perform SNAT for outbound traffic. Also, the NVA must have a default route to the internet (via its own public IP or Azure's default internet path).
The most common cause is missing IP forwarding. Check that IP forwarding is enabled on the NVA's NIC in Azure (EnableIPForwarding = true) and at the OS level (sysctl net.ipv4.ip_forward=1 on Linux, or netsh command on Windows). Another cause: the NVA's firewall rules are blocking the traffic. Also verify that the route table is associated with the correct subnet and that the next hop IP is correct. Use Azure Network Watcher's 'Next hop' diagnostic to verify the path.
Yes, but you must ensure symmetric routing. For inbound traffic from the internet, the NVA must have a public IP and be the destination for inbound connections (DNAT). For outbound traffic, the NVA performs SNAT. The challenge is ensuring return traffic for inbound connections also goes through the NVA (asymmetric routing issue). Typically, you configure the NVA as the default gateway for the subnet and use the same public IP for both directions. For high availability, use a load balancer.
In active-passive, only one NVA handles traffic at a time; the other is standby and takes over if the primary fails. This is simpler but wastes resources. In active-active, both NVAs handle traffic simultaneously, increasing throughput. However, stateful inspection requires session synchronization between NVAs (e.g., Fortinet FGCP, Palo Alto Active/Active). The load balancer distributes traffic across both. For the exam, know that NVAs behind a load balancer can be active-active if they support session sync.
By default, Azure routes traffic between subnets within the same VNet directly (system route). To force traffic through an NVA, you must create a UDR on the source subnet with the destination subnet's prefix and next hop set to the NVA. You also need a UDR on the destination subnet for the source subnet's prefix to ensure symmetric routing. Without these, traffic bypasses the NVA.
Yes. Azure Route Server enables dynamic routing between NVAs (running BGP) and Azure. It automatically injects routes learned from NVAs into the VNet, eliminating the need for static UDRs in many cases. This is useful when NVAs advertise routes to on-premises or other VNets. Route Server is a managed service that simplifies routing in hub-and-spoke topologies with NVAs.
You've just covered Network Virtual Appliances (NVA) — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?