Introduction
Azure Firewall is a fully managed firewall service provided by Microsoft. It was only released in 2018, but there have been significant improvements during that time. Azure Firewall premium was also made generally available on July 19th, 2021. The new features that were released with premium are documented here.
This post will go over how to force traffic from an Azure Virtual Network (VNET) to an on-premise data centre via Azure Firewall. I couldn’t find many step-by-step guides on this specific use case, so hopefully this will assist someone.
Scenario
Below is a network diagram portraying the example scenario we will be working towards:
The topology comprises of the following Azure resources:
- Site-to-Site VPN Tunnel: The on-premise network on the left-hand side is situated in a physical on-premise data centre. A site-to-site VPN tunnel has been configured to extend its network into Azure.
- VPN Gateway: A VPN gateway has been configured in Azure to support the VPN tunnel.
- Local Network Gateway: A local network gateway has been created to represent the public gateway address from the on-premise VPN device (Firewall).
- Connection: A connection has been configured within the VPN gateway to establish connectivity from on-premises to Azure using the relevant phase 1 and phase 2 protocols.
- Azure Firewall: An Azure Firewall Premium instance has been stood up in UK South.
- Virtual Networks: A single VNET and 3 subnets have been created to support the setup. Note, that the Firewall subnet must be called “AzureFirewallSubnet” or the firewall will not deploy. The VNET address space has been configured with the following address space: 10.8.0.0/18
- Virtual Machine: A VM has been configured in Azure, so connectivity can be tested back to the on-premises data centre.
- Route Table: Finally, the most important component, two route tables are required (as per diagram above) to direct the necessary traffic via the Firewall.
This guide assumes that the VPN Gateway, virtual networks, subnets and VM have already been created.
Deploy Azure Firewall
Follow the below instructions to successfully deploy Azure Firewall:
- In Azure marketplace search for “Azure Firewall” and select “Firewall”:
- Provide the firewall with a suitable name and resource group. You must also create a new Firewall policy which is where all the configuration will be done, so provide an appropriate name:
- Create a public IP address (this is mandatory) and associate the firewall to the existing VNET where the “AzureFirewallSubnet” lives:
Azure Firewall Policy
During step 2, a new Firewall policy was created. This is where you create all the firewall rules. Rule types come in three different flavours:
- DNAT Rules: Destination Network Address Translation rules can be created to control inbound traffic. For example, gaining access to an Azure based VM using RDP. Azure firewall will translate the traffic to the necessary VM.
- Network Rules: These are the most common rule types that handle multiple situations. These rules closely relate to on-premise firewalls. We will be using this rule type to allow ICMP traffic to flow from Azure to the on-premise data centre.
- Application Rules: These are powerful rules that can be used to grant outbound connectivity to FQDN and websites.
Create Network Rule
To test connectivity, we will ping a VM from the Azure VNET1 (Infra subnet) to a VM based in the on-premise data centre. Navigate to the resource group where Azure Firewall was created. There you will find the new Azure Firewall Policy. Click on the Azure policy to create a network rule.
- Click on Network Rules:
- Click on the Add Rule button and create a rule that matches the below (replace the source and destination IP addresses to match the address spaces that you are using):
This rule will allow ICMP traffic to flow from Azure to on-premise. Remember to allow ICMP via the Windows firewall on the VM you are trying to reach too.
Route Table
To configure the traffic to filter through Azure Firewall, a Route table must be configured. The route then needs to be applied to the Infra Subnet as this is where the VM is situated. Once the route table has been created, create a new route:
The Address prefix is the address range of the on-premise network. Remember, this will always be the destination address (route). The next hop type is defined as a “Virtual Appliance” (this is valid for Azure Firewall as well as NVAs). Finally, the next hop address should be the private IP address of the Azure Firewall. Once completed, there is an additional step. The route must be associated with the Infra subnet. This must be done to force traffic via Azure Firewall.
Finally, a route table will need to be configured and associated with the gateway subnet. This will allow traffic from the on-premises network (172.16.0.0/24) reach the spoke network via Azure Firewall:
Testing
After waiting for a minute, you can initiate a ping from the Azure VM (located in the Infra subnet) to an on-premise VM. As long as Windows firewall or the on-premise firewall is not blocking ICMP traffic, it will successfully work:
To sanity check whether traffic is definitely flowing via Azure Firewall, you can delete the ICMP rule from the network rules and test again. The ping won’t be successful.
Conclusion
This post demonstrated the process of standing up Azure Firewall. A network rule and routing table was then created to ensure that traffic correctly flowed from the Infra subnet to the Azure Firewall. Based on the network rule set, ICMP traffic was successfully passed to the on-premise network through the VPN gateway.
This of course is only scratching the surface on the Azure Firewall feature set. But by following this guide, it should be a breeze to successfully navigate traffic through Azure Firewall utilising network rules and route tables.
This is misleading.
When you route the traffic to the firewall, the firewall doesnt route the traffic to on premise, breaking the flow.
I suggest you edit this article, as it doesnt work.
Hi Gaz,
Thanks for the comment. Have you experienced this issue in a test or customer environment? Would you mind sharing what issues you exactly faced and how you confirmed the flow was broken? I’ve confirmed the traffic flow from the topology in this blog in a live customer environment. To sanity check, I also went into Azure Firewall network logs to confirm the packet flow was happening as expected (from Azure Firewall to the on-premise network).
Furthermore, Microsoft also validated the setup. The only thing I didn’t mention in the blog was that it’s recommended to include a route table in the Gateway subnet, to ensure that the reverse traffic flows correctly from on-premises to Azure – via Azure Firewall. This is advised to avoid asymmetric routing. Let me know if I’ve misunderstood anything as I’m keen to apply any updates to the blog to ensure I’m not spreading false information.
Cheers
Hello Mohnish Kumar,
Thank you for sharing this article, I am to route my on-prem traffic and azure traffic via the Azure firewall.
My only suggestion would be adding the steps to route on-prem traffic via the azure firewall.
Hi Kiran,
Thank you for the feedback. You’re right, these steps should ideally be included as it is a critical step. I’ll look to update this article or create a new one especially for the on-premises steps in the future.
Thanks
Absolutely agree with this comment. Adding those extra steps on routing on-prem traffic through firewall would be so beneficial!
Huge thank you for the article – just what I was looking for!
Keep up the good work!
Hi Mohnish,
Thanks for the amazing blog. Now on the Gateway subnet I will set up UDR for the so that traffic coming into Azure will be routed via the firewall. My question is this, since UDR will not be applied to the Azure Firewall, how does Azure Firewall learn about the On-premise routes for traffic going back to On-prem.
Hi Mahavir,
This is a common question, I didn’t make this clear in the article initially, apologies. I have updated the article and scenario diagram to help with this question. Essentially, two route tables are required, one on the gateway subnet and the other on the infra subnet. The gateway subnet route will route traffic to the infra subnet via Azure Firewall (from on-premises). Finally, a route table also needs to be associated to the infra subnet (please see diagram and route table section for details). It is the “infra-subnet-to-azf” route that controls traffic back to on-premises. I hope this answers the question.
This was a very useful tutorial, thanks for posting. The only issue I had with this… and I couldn’t for the sake of me figure out why, was that with routing going through the firewall in both directions, the only things I could actually get working from Azure VMs to On-prem were ICMP and Remote Desktop. Calls to SSH, SMB, from what I could tell from the on-prem endpoint they didn’t even leave Azure. I tried network rules, opening any/any from the VM to an on-prem system, vice versa left it wide open to try it. Same on the NSG for that Azure VM, none of that made any difference. As soon as I route the Azure VM back through the virtual gateway instead of the firewall, all is well again. Any insights as to why that may have been?
It sounds like you followed all the correct steps. I would firstly check the effective routes on the Azure VMs to ensure that traffic is being pushed to Azure firewall successfully. Then inspect the network rule data logs in Azure firewall to ensure the SSH/SMB packets are reaching the firewall (if you haven’t already). If you can see the network packets being received in the firewall, then it is indeed a routing issue. As a test, you can try creating a new route table and associating it with the Azure Firewall subnet. In here, you would want a route to list the address prefix for the on-premises range to go via the virtual network gateway as the next hop. You will also want a 0.0.0.0/0 route as next hop Internet. That should hopefully do the trick.
When you create a UDR on Gateway subnet. *click Route- – (Route name), (address prefix destination), (next hop type),
(next hop address). ‘This configuration was fine’
Next: click Subnet- – please what will you associate when you click the subnet?
Hi Mike, please refer to the Route Table section of the article. You will need to create two different route tables and associate them to the GatewaySubnet and the Infra Subnet. The diagram in the scenario section should also help with this. I hope this helps.