While designing the azure landing zone we need to ensure that our network is secured.VNet protects inbound flow (from users) and outbound traffic flow (to the Internet). Now the question arises how do we secure this traffic? Azure provides services like Azure firewall and Azure Application Gateway. It is very confusing when to use Azure firewall vs. Azure Application Gateway. There can be other combinations that can make the design more and more complex. This article provides the definitive guide and scenarios-based approach to help what design should be used. When it should be used? How it should be used?
Traffic Types
Before designing the solution we need to ensure what types of traffic we need to protect. Essentially there are two types of traffic:
- Https Traffic: Web application Traffic when users browse the internet or hit the web application hosted on VM.
- Non-HTTP Traffic: Non-web application traffic for example TCP traffic to connect to SQL server on port 1433.DNS server listening on port 53 is also non-HTTP traffic.
Address Translation
The most important part of security is to protect the devices by hiding their IP address. This way sender will not be able to attack the IP address from where the traffic is emanating. This is done by network address translation. There are two types of network address translation:
Source Network Address Translation: SNAT is used when you want to hide the IP address of an internal/private host trying to initiate a connection to an external/public host. The device performing NAT (Azure Firewall) changes the private IP address of the source host to a public IP address. In this process, It may also change the source port in the TCP/UDP headers. An example of SNAT is when we need to change the private address or port into a public address or port when the packets are leaving the network.
Destination Network Address Translation: DNAT is used to redirect incoming packets with a destination of a public address/port to a private IP address/port inside your network. Destination NAT is performed on incoming packets, where the firewall translates a public destination address to a private address. DNAT performs translation with the option to perform port forwarding or port translation. One example of DNAT would be that users trying to access a web server hosted in a Data Center where DNAT is used to hide the private address of the web server and NAT device (for example Azure Firewall) translates the public destination IP reachable to Internet users to Private IP address of Web Server.
What is Azure Application Gateway?
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to web applications. Azure Application Gateway operates at the Application layer (OSI layer 7 – Application Layer) and routes traffic based on the source IP address and port, to a destination IP address and port.
Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example, URI path or host headers. This means you can route traffic based on the incoming URL. for example if images are in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If a video is in the URL, that traffic is routed to another pool that’s optimized for videos.
What is a Web Application Firewall?
Web Application Firewall (WAF) provides centralized protection of web applications from common exploits and vulnerabilities. Web applications are increasingly targeted by malicious attacks (SQL injection, Cross Site scripting, etc.) that exploit commonly known vulnerabilities. SQL injection and cross-site scripting are among the most common attacks.
Preventing such attacks in application code is a herculean task. It can require rigorous maintenance, patching, and monitoring at multiple layers of the application topology. A centralized web application firewall helps make security management much simpler. A WAF also gives application administrators better assurance of protection against threats and intrusions.
What is Azure Firewall?
Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It’s a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. By default, Azure Firewall blocks traffic.
SNAT, DNAT, Network packet filtering, and Application FQDN filtering rules are the main features of the Azure firewall.
Traffic filtering choice between Azure firewall vs WAF?
HTTP(s) and Non-HTTP(s) traffic from/to azure can be filtered by the Azure firewall but WAF can only filter inbound traffic from on-premise /internet to Azure.
When to use a standalone Azure firewall?
If there are no web-based workloads in the virtual network that can benefit from WAF, you can use Azure Firewall only.
When to use standalone Application Gateway?
Use Application Gateway where only web applications exist in the virtual network, and inspecting outbound traffic with NSGs is sufficient to protect outbound flows to the internet.
When to use Azure Firewall and Application Gateway in parallel?
if there’s a mix of web and non-web workloads in the virtual network. Azure WAF protects inbound traffic to the web workloads, and the Azure Firewall inspects inbound traffic for the other applications. The Azure Firewall will cover outbound flows from both workload types.
Inbound connection from outside client:
An inbound connection is self-explanatory on how traffic is flowing.
Outbound connection from network VM to the internet:
outbound connection is self-explanatory on how traffic is flowing.
Application Gateway before the firewall
When to use: Inbound web traffic goes through both Azure Firewall and WAF. The WAF provides protection at the web application layer. Azure Firewall acts as a central logging and control point, and it inspects traffic between the Application Gateway and the backend servers. The important point to consider here is that the Azure Firewall applies TLS inspection to do IDPS on the encrypted traffic between the Application Gateway and the web backend. This design is suitable for scenarios where applications need to know incoming client source IP addresses. Let’s take an example application server serves the location-specific content so users coming from the EU locations will be served different content vs. users coming from the AP region.
Application Gateway in front of Azure Firewall captures the incoming packet’s source IP address in the X-forwarded-for header, so the web server can see the original IP address in this header.
Non-HTTP(s) traffic will be hitting thru Azure Firewall’s private or public interface depending upon where the traffic is coming from. Private traffic will be coming from the private interface and internet traffic will be coming from the public interface.
Application Gateway after Firewall
When to use This design lets Azure Firewall filter and discard malicious traffic before it reaches the Application Gateway. Azure firewall can apply features like threat intelligence-based filtering. Another main benefit is that the application gets the same public IP address for both inbound and outbound traffic.
Limited benefit of this design because Azure firewall always sees the encrypted traffic with which it can not do much. This scenario is only useful when you want to use WAF before the firewall or you want to use multiple public IP addresses and you want to direct all the traffic via one firewall for central logging and monitoring mechanism.
On-premise client connectivity
There are some caveats when you use this design from on-premise clients:
Hub and spoke considerations
When you implement Hub and spoke topology you need to carefully design the UDR to avoid asymmetric routing
Asymmetric Routing: In the routing diagram depicted below, the traffic from instance 1 of the firewall goes back to Instance 0 of the firewall causing Asymmetric routing. To avoid it in the routing table next hop should not contain the whole Vnet address space where Azure Firewall is kept instead it should contain the specific subnet like the common services subnet. That is why the routing table is depicted in red.
I hope this post helps to understand the Architecture best practices.