What is Azure Network Virtual Appliance (NVA)?
Learning Center | Cloud Security | What is Azure Network Virtual Appliance (NVA)?
Learning Objectives
This article details different types of VPNs, VPN configurations, various architectural implementations of the site to cloud VPNs and a study of the various key distribution mechanisms for security enhancement.
MORE CLOUD SECURITY & OPERATIONS ARTICLES
What is Site to Cloud VPN?
What Do Egress and Ingress Mean in the Cloud?
What is the AWS Console?
Why Use Egress Filtering?
What does AWS Networking Services Offer?
What are Security Groups in AWS?
Network Security in Azure
What is Azure Firewall?
How do I create Network Security Groups in Azure?
What is Azure Network Security Group?
What is Azure Express Route?
What is Azure Network Virtual Appliance (NVA)?
Azure Network Virtual Appliance (NVA)
Azure network virtual appliance is used in the Azure application to enhance high availability. It is used as an advanced level of control over traffic flows, such as when building a demilitarized zone (DMZ) in the cloud.
In the above architecture, the network virtual appliance sits in a DMZ and checks all incoming and outgoing traffic and only allowing 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
Network Appliance Vendor Ecosystem
Microsoft Azure supports a large ecosystem of third-party network device providers. These vendor appliances are available in Azure Marketplace as VM images that you can easily deploy. This facilitates migration to Azure and allows companies to continue using the skills already acquired by the team.
The following are the vendors of NVA
Citrix, Palo Alto Networks, Cisco and Fortinet among others
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.
Advantages of NVAs
Azure Network Virtual Appliance can handle a variety of protocols, limited only by what is available in the Azure network, and can typically offer most of the services associated with their vendor’s local firewalls (traffic not supported by Azure such as broadcast and multicasting). The ability to use standard network management tools, firewall rules, and more is a definite advantage for many organizations, positioning Azure Network Virtual Appliance NVA as a high-performance solution in many scenarios from a technical point of view.
Disadvantages of NVAs
The disadvantages lie mainly in complexity and cost. Certain features expected in on-premises products, such as VRRP and active-active configurations, will not work because of the limitations of Azure networking. Adding an NVA to a virtual network can lead to significant changes in routing tables, additional infrastructure complexity (load balancers, availability sets, and so on), as well as unwanted side effects. On service accessibility and hybrid connectivity. These must be carefully planned and taken into account when dealing with NVA. In most cases, the NVA resides on underlying Azure virtual machines, which support their own computing costs, in addition to the vendor’s device license costs hence increasing cost.