Petri Newsletter Sign-up
Tech Tuesday

Subscribe to Tech Tuesday, the latest insights from Petri.com for IT Pros.

    See All Petri Newsletters

    Azure Firewall in a Single Virtual Network

    Posted on by Aidan Finn in Microsoft Azure with 1 Comment

    Design Concept

    Because of the cost of Azure Firewall, I would normally expect it to be used in larger implementations. But high-value assets do not have to be large; a few virtual machines can be responsible for millions of dollars of business – I have seen it – and that is something that the business will wish to protect.

    Therefore, one might expect to see a design such as the below. Although Microsoft normally sees Azure Firewall being deployed into a hub-and-spoke virtual network deployment (peered VNets), you can deploy Azure Firewall into a dedicated subnet in a single VNet.

    Azure Firewall in a Single Virtual Network
    Azure Firewall deployed into a single virtual network [Image Credit: Aidan Finn]
    For the purposes of illustration and explanation, I have kept this architecture simple, but I will expand on it later in the post.

    The Firewall

    As is required by Azure Firewall, a dedicated subnet is deployed. This subnet, which must be called AzureFirewallSubnet, must have a subnet mask of at least /25.

    The Azure Firewall has two IP addresses:

    • A public IP address (PIP): You must note the IPv4 address of the PIP for any NAT rules that you want to create. NAT rules require a “destination IP address”, which is the address that Internet traffic will be sent to.
    • Internal IP Address: The Azure Firewall will consume a single IP address from the AzureFirewallSubnet. This address will be later used in route tables for the web and backend subnets.

    Web Subnet

    A subnet for web servers is created. This subnet has:

    • A dedicated network security group (NSG): This NSG will control what TCP/UDP traffic can flow into and out of the subnet from any source/destination, including the Internet, other machines in the VNet, other machines in the same subnet, and the Azure Firewall.
    • A dedicated route table: The route table will send all traffic to the internal IP address of the Azure Firewall.

    Let’s dig into routing for a moment. If your intention is to route all traffic, including internal traffic, through the firewall then you must create very granular rules. 0.0.0.0/0 will route external traffic through the firewall; traffic to the same/other subnets in the same VNet will route directly, bypassing the firewall. To get the web servers to route to the backend (let’s assume the backend is 10.0.3.0/24) then you must create a rule sending all traffic to 10.0.3.0/24 to the internal IP address of the firewall, as well as a rule for 0.0.0.0/0.

    Taking full control over routing and sending all internal traffic through the firewall can be complicated, especially if there will be other services with public IP addresses (split routing). But the benefits of this “micro-segmentation” are:

    • All traffic is inspected by Azure Firewall
    • All traffic is logged by Azure Firewall

    You might notice that the web servers have an internal IP load balancer; this provides a single internal IP address (translation address) that can be used for NAT rules.

    Backend Subnet

    A subnet for backend servers is created. This subnet has:

    • A dedicated network security group (NSG): This NSG will control what TCP/UDP traffic can flow into and out of the subnet from any source/destination, including the Internet, other machines in the VNet, other machines in the same subnet, and the Azure Firewall.
    • A dedicated route table: The route table will send all traffic to the internal IP address of the Azure Firewall.

    The conversation about routing from above can be repeated here. Note that no traffic will NAT from the Internet to this subnet. Instead, application and/or network rules in the Azure Firewall will allow traffic to flow from the web subnet to the backend subnet – assuming you followed the above advice on taking full control over routing.

    Expansion

    Let’s say you have other services that will have public IP addresses. Maybe a jump box virtual machine (bastion host) will have a dedicated PIP, or maybe you want to put a web application gateway/firewall in front of the web servers (another dedicated PIP)? If you anything like these, then you must be careful about routing. If you have a route table that sends all traffic through the firewall, then:

    • External clients will see responses coming from a different IP address than they sent the request to.
    • Azure Firewall might block the outbound traffic because it wasn’t seen as a response to an allowed inbound rule.

    In this case, you will have to pay much more attention to subnet design, machine/appliance placement, and how traffic routes to the outside world.

    BECOME A PETRI MEMBER:

    Don't have a login but want to join the conversation? Sign up for a Petri Account

    Register