Brad Dickinson

What To Consider when Building Your Azure Firewall Design

The content below is taken from the original ( What To Consider when Building Your Azure Firewall Design), to continue reading please visit the site. Remember to respect the Author & Copyright.

Post General Availability

The Azure Firewall was quite limited during its preview. In fact, I would go as far as saying that if it had not improved, I would not consider it as a firewall option in Azure – but that’s not the case anymore! I have recommended the Azure Firewall because it has the core features I commonly need for customers now, plus I can “set it and forget it”.

The most important feature of all is the ability to create NAT rules (DNAT to be precise) for inbound traffic. Yes; during the preview, the Azure Firewall only inspected outbound traffic.

Network Security Groups (NSGs)

Azure Firewall does not replace NSGs. Defense in depth is still a good thing. Typically, you will use 1 NSG per subnet for local or distributed firewalling, plus the Azure Firewall for central or edge protection.

There are scenarios where internal traffic will not be inspected by the Azure Firewall. If packets are routing from one subnet to another inside a virtual network, then those packets will not be routed by the firewall even if a user-defined route (UDR) in a route table directs traffic via the internal IP address of the firewall. If you want to force inspection then you can do one of the following:

Common Designs

Microsoft has been slow to produce reference architectures for the Azure Firewall – you can find some really good ones from Microsoft for many kinds of IaaS scenarios. However, if you read through the Microsoft docs for Azure Firewall you can figure out some designs/scenarios:

Note that the Azure Firewall must be deployed into a subnet called AzureFirewallSubnet.

Web Application Gateways & Firewalls

The Web Application Gateway (WAG)/Web Application Firewall (WAF) still has a function. The WAG/WAF is intended for inspecting inbound HTTP/HTTPS traffic. The Azure Firewall can inspect application traffic (RDP, SSH, FTP and so on) as well as all outbound traffic.

Note that the WAG/WAF should be deployed with a public IP address at this time – yes; that does complicate architecture and increases the number of public IP addresses in your designs.

Split Routing

If you deploy services with their own public IP address with the Azure Firewall then you might encounter split routing. Traffic will come into those services, such as web servers behind a WAG/WAF via a public IP address, but a UDR will route the traffic out to the Internet via the Azure Firewall. That could cause some issues such as:

To avoid this you can be careful with your UDR. For example, I might route traffic to the virtual network(s) via the Azure Firewall, but not use the “everything” 0.0.0.0 destination in the route table associated with the affected web services.

If you use split routing and the Azure Firewall is effectively the default gateway for the subnet via routing, then Just-In-Time VM Access (Azure Security Center) will not work.

Service Endpoints

Enabling service endpoints on subnets has become more common; this enables secure access to Azure services, such as Azure SQL or storage accounts, from your virtual machines through your virtual network(s).

Microsoft recommends enabling service endpoints in your Azure Firewall subnet and disabling them in your other subnets. The idea is that the Azure Firewall would inspect and log all outbound traffic, including this would require a 0.0.0.0 routing rule to force all traffic through the Azure Firewall. Note that this design might require split routing if you have services with their own public IP address, so this is a “think about it before you do it” design recommendation.

The post What To Consider when Building Your Azure Firewall Design appeared first on Petri.

Exit mobile version