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:

• Create UDRs that list precise subnet prefixes.
• Break the subnets out into different virtual networks that are peered with a hub/firewall virtual network.

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:

• Deploy the Azure Firewall in a dedicated subnet and route traffic from other subnets through it. This might be good for a small deployment where you need the functionality (at a cost) of the Azure Firewall.
• Deploy the Azure Firewall in a central (hub) VNet and deploy applications in other (spoke) VNets. Peer the VNets and send as much traffic as possible through the firewall. The VNets must be in the same Azure region as the Azure Firewall – global VNet peering is not supported.
• Place a VPN gateway and Azure Firewall into a hub virtual network. Create a VPN connection to the gateway from an on-premises network. Deploy applications into peered spoke VNets behind the Azure Firewall.

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:

• The Azure Firewall blocking the outbound traffic because it isn’t seen as a “response” by the stateful inspection.
• The client is confused by communicating with two different public IP addresses (the WAG/WAF and the Azure Firewall).

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.