What is Azure Network Virtual Appliance (NVA)?

Azure Network Virtual Appliances (NVAs) are instrumental in enhancing high availability and controlling traffic flows within Azure applications. They are particularly significant in constructing demilitarized zones (DMZ) in the cloud. NVAs in Azure scrutinize all incoming and outgoing traffic, permitting only the traffic that complies with predefined rules, thus ensuring a secure network boundary.

NVA Architecture & Functionality

1. DMZ and Traffic Control: In the architecture where an NVA is placed in a DMZ, it monitors and regulates network traffic, ensuring compliance with security rules. However, a limitation is noted in the event of NVA failure, as there may not be an alternative network path available.
2. High Availability in Ingress and Egress:
   1. Ingress with Layer 7 NVAs: This architecture employs an Internet-facing load balancer to direct layer 7 traffic (e.g., HTTP/HTTPS) to Azure workloads. The advantage here is the active status of all NVAs; in case of failure, the load balancer redistributes the traffic to another NVA.
   2. Egress with Layer 7 NVAs: This setup ensures the high availability of NVAs in the DMZ for layer 7 traffic. Outgoing requests from Azure are routed through an internal load balancer to a set of NVAs, which then direct traffic to the Internet.
   3. Ingress-Egress with Layer 7 NVAs: Combining both ingress and egress, this architecture manages incoming and outgoing layer 7 traffic. It requires NVAs to handle session affinity due to the separate routing mechanisms of the application gateway and the load balancer.
3. PIP-UDR Switch with Layer 4 NVAs: This architecture involves a passive and active NVA for layer 4 traffic. In case of an active NVA failure, the passive NVA takes over, with UDR and PIP adjustments made manually or via an automated process.
4. PIP-UDR NVAs without SNAT: Designed for scenarios where SNAT is not feasible, this architecture uses an active-passive NVA firewall setup with automated failover. It allows connection to original IP addresses without SNAT translation.

DMZ and Traffic Control

In the above architecture, the network virtual appliance sits in a DMZ checks all incoming and outgoing traffic, and only allows network traffic that meets the set rules hence providing a secure network boundary. However, if the Network virtual appliance fails there is no other path of network path available.

Ingress with layer 7 NVAs

The following figure illustrates a high availability architecture that implements an entry demilitarized zone behind an Internet-facing load balancer. This architecture is designed to provide connectivity to Azure workloads for layer 7 traffic, such as HTTP or HTTPS

The advantage of this architecture is that all NVAs are active and in case of failure, the load balancer directs the network traffic to the other NVA. Both NVAs route traffic to the internal load balancer so that as long as an AVN is active, the traffic continues to flow. The AVNs must terminate the SSL traffic destined for Web-level virtual machines. These NVAs cannot be expanded to handle on-site traffic because the on-site traffic requires another dedicated set of NVAs with their own network routes.

Egress with layer 7 NVAs

An egress provides high availability of the Network virtual appliances in the Demilitarized Zone (DMZ) for layer 7 packets namely the HTTP and HTTPS. The egress DMZ deals with requests coming from the azure workload.

In this architecture, all traffic from Azure is routed to an internal load balancer. The load balancer distributes outgoing requests between a set of NVAs. These NVAs direct traffic to the Internet using their individual public IP addresses.

Ingress-egress with layer 7 NVAs

The following architecture combines both the ingress and egress in the creation of the DMZ for layer 7 traffic.

The NVAs process incoming requests from the application gateway. The NVAs also process the outgoing requests from the workload virtual machines in the main pool of the load balancer. Because incoming traffic is routed with an application gateway and outbound traffic is routed with a load balancer, the NVAs are responsible for handling session affinity. In other words, the application gateway manages to map incoming and outgoing requests in order to be able to transmit the correct response to the originating requester. However, the internal load balancer does not have access to application gateway mappings and uses its own logic to send responses to the NVA. The load balancer might send a response to an NVA that did not initially receive the request from the application gateway. In this case, the AVNs must communicate and transfer the response between them so that the correct AVN can transmit the response to the application gateway.

PIP-UDR switch with layer 4 NVAs

The architecture shows the implementation architecture of a passive NVA and an NVA asset. The architecture addresses both the output and the input of Layer 4 traffic. In case of failure of the active NVA, the passive NVA becomes active and the UDR and PIP are modified to point to the NICs of the now active NVA. These changes to the UDR and PIP can be made manually or using an automated process. The automated process is usually a daemon or other monitoring service running in Azure. It polls an integrity probe on the active NVA and performs the UDR and PIP switches when it detects a failure of the NVA.

PIP-UDR NVAs without SNAT

This architecture uses two Azure VMs to host the NVA firewall in an active-passive configuration that supports automatic failover but does not require SNAT (Source Network Address Translation) translation.

This solution is designed for Azure customers who cannot configure SNAT for incoming requests on their NVA firewalls. SNAT hides the IP address of the original source client. If you need to connect to the original IP addresses or use them in other layered security components behind your NVAs, this solution provides a basic approach.

Failover of the UDR table entries is automated by a next hop address set to the IP address of an active NVA firewall virtual machine interface. Automated failover logic is hosted in a function application that you create using Azure Functions. If the changes made to the virtual network have an impact on the NVA firewalls, the function application continues to run independently..

To check the availability of the NVA firewall, the core function of the application tests it in one of two ways:

• By monitoring the status of Azure VMs hosting the NVA firewall.
• By testing, if there is an open port through the firewall to the main web server. For this option, the NVA must expose a socket via PIP for the code of the application to be tested.

Network Appliance Vendor Ecosystem

Microsoft Azure supports a broad ecosystem of third-party network device providers, such as Citrix, Palo Alto Networks, Cisco, and Fortinet. These vendor appliances, available in the Azure Marketplace, facilitate migration and leverage existing team skills.

Advantages of NVAs

• Protocol Versatility: Azure NVAs can handle a wide range of protocols and offer services akin to vendor-specific local firewalls.
• Standard Management Tools: The ability to use familiar network management tools and firewall rules is a significant advantage for many organizations.

Disadvantages of NVAs

• Complexity and Cost: Implementing NVAs in Azure can introduce complexity in routing tables and infrastructure. Features common in on-premises products may not be fully functional due to Azure networking limitations.
• Additional Costs: The use of NVAs incurs costs related to the underlying Azure virtual machines and vendor device license fees.