Azure Firewall is a cloud-native and intelligent network firewall security service that provides the best of breed threat protection for your cloud workloads running in Azure. It's a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. It provides both east-west and north-south traffic inspection.
There are some organizations that require outbound network traffic to be inspected by multiple network security appliances, such as firewalls, before it is sent out to an internet destination. A customer in Azure can use Azure Firewall to filter and apply policies to outbound traffic originating from their Azure resources, but their security policy could dictate that all internet bound traffic be sent to and inspected by another Network Virtual Appliance (NVA) Firewall in Azure or to an on-premises firewall before it is sent to the internet.
Additionally, these organizations may face certain scenarios, such as Windows license activation through the Key Management Services (KMS) system, that require Azure based Windows VMs be activated from a public source IP owned by Microsoft and not their on-premises internet gateway IP.
To help meet this common requirement for a downstream firewall, customers can deploy Azure Firewall in Forced Tunnelling mode. When Azure Firewall is deployed in Forced Tunnelling mode, the traffic from Azure based resources is inspected/filtered by Azure Firewall and then routed to a downstream firewall (NVA/on-prem) for further processing.
Customers can also configure their Azure Firewall environment to Split Tunnel their forced tunneled traffic. Utilizing Route Tables on the AzureFirewallSubnet, we can split internet-direct dependent connections to egress out of the Azure Firewall while still allowing all other connections to be forced downstream.
In this blog, we will provide step-by-step guidance:
I. Deploying Azure Firewall in Forced Tunneling mode
In this section, we will walk you through the steps for deploying Azure Firewall in Forced Tunnelling mode. You'll need to have a Virtual Network with the proper subnets already configured. These subnets are called AzureFirewallSubnet and AzureFirewallManagementSubnet and must be sized at /26 at a minimum.
Note: The minimum size of the AzureFirewallSubnet subnet is /26. For more information about the subnet size, see Azure Firewall FAQ. The same goes for AzureFirewallManagementSubnet subnet where the minimum subnet is /26, see Forced Tunneling Configuration.
Creating Azure Firewall with Availability Zones that use newly created Public IPs is currently not supported. Zonal Public IPs created beforehand may be used without issue or you can use Azure PowerShell, CLI, and ARM Templates for the deployment. For more information about these known issues, see Known Issues.
You've now successfully configured an Azure Firewall in Forced Tunnel mode. If you'd like to test a fully configured environment through a 1-click deployment or Azure PowerShell deployment, move on to the following section.
II. Deploying the environment to test traffic through the Azure Firewall in Forced Tunnelling Mode
The environment we will use in this blog is demonstrated in the diagram below. In this environment, we will route the traffic originating from resources in a Spoke network in Azure to another Azure network that will represent an on-premises environment. We will be using a VPN gateway to securely pass the traffic from Azure resources to another resource on the on-premises site.
If you’d like to learn more about the resources and configurations for this environment, or if you would like a step-by-step guide to deploy this environment via the Azure Portal, please visit the GitHub repository where the template is hosted and review the Read Me document.
III. Test Azure Firewall in Forced Tunneling mode and How-To Split Traffic
Testing traffic from Azure to on-prem
For our first test, we want to verify the connectivity from our Azure VM to the “on-premises” VM to confirm if our forced tunneling setup and routing is correctly configured.
If you look at the diagram in section II, you will see that the traffic originates from the VM hosted in the subnet snet-trust-workers within the virtual network vnet-spoke-workers, which routes the packets to the Hub Azure Firewall in the virtual network vnet-hub-secured. Azure Firewall will then send the traffic to the VPN gateway, vgw-vnet-hub-secured, because of the default route learned from the GatewayDefaultSite command. Typically default route would be learned via BGP. Our traffic is then sent to the “on-premises” firewall where it will be forwarded to the “on-premises” VM. It will take the same route going back to the Azure VM to avoid asymmetric routing.
Connect to your VM in the vnet-spoke-workers virtual network using the DNAT rule configured in Azure Firewall policy and bring up a PowerShell command prompt. Type in the following command:
Test-NetConnection -ComputerName 10.100.0.68 -port 3389
This command will initiate a TCP connection to port 3389 which is by default opened on Windows machines. 10.100.0.68 is the IP address of our "on-premises" VM.
If you get the following output TcpTestSucceeded : True, that indicates that our first test is successful and forced tunneling is setup correctly.
Testing On-premises as an internet gateway for your Azure resources
Since we’ve confirmed that the traffic that we’re allowing through is reaching our on-premises VM, let’s now try accessing a public IP from our Azure VM. We'll be able to see how the request is reaching the "on-premises" firewall due to the forced tunnel configuration. This test is to show that forced tunneling throughout the environment is working for traffic with a public IP as the destination and that application rules also work.
Make sure your application rule on Azure Firewall to owaspdirect.azurewebsites.net FQDN is configured with the following details:
Source Type: IP Address
Source IP Addresses: 192.168.2.0/24
Destination Type: FQDN
Target FQDNs: owaspdirect.azurewebsites.net
Protocol: 80, 443
Open the web browser on your Azure VM and navigate to the site owaspdirect.azurewebsites.net. We will use this FQDN since it will resolve the same public IP from any region.
You should see this in your web browser “Action: Deny. Reason: No rule matched. Proceeding with default action.” That’s because the Azure Firewall in the on-premises environment is dropping the traffic. If we go to our log analytics workspace, law-soc, you will see 2 entries for this request, 1 per Azure Firewall.
The first entry will show that the traffic was allowed by the Internet application rule on the “Azure” firewall.
And if we look at the second log, we will see that it was denied by the “on-premises” firewall. This confirms that all internet traffic is being forced to our on-premises network.
If you look at the source IP on the "on-premises" firewall, you will notice that it has been SNAT'd to the private IP of one of the Azure Firewall instances, 192.168.0.70. This behavior is expected and is done by default, as all traffic going through the Azure Firewall with a destination IP address outside of RFC 1918 ranges will be source Nat’d. If you want to change that behavior, then you can change it by going to Private IP ranges (SNAT) tab and choosing one of the available options to control firewall SNAT behavior.
Note: The information above only applies to traffic processed by Network rules, traffic going though Application rules will be Nat’d regardless of the configuration in Private IP ranges (SNAT)
Testing split tunnel traffic to the Internet
For our third test, we will create a split tunnel to route specified traffic to the internet. A common scenario where this is necessary, is during Windows activation, when activations fail due to forced tunneling. Since all the traffic from our virtual machine is routed back to our on-premises network, the VMs can’t connect to KMS servers to activate Windows. You can read more about this scenario here:
We will show you how we configured our setup to prevent this issue from happening and enable connection from our Azure VMs to KMS servers for Windows activation.
First, we added a route to our route table, route-fw-snet, which is attached to the AzureFirewallSubnet. We called this route send-to-kms and added 188.8.131.52/32 as the destination and chose Internet as Next hop type. The IP 184.108.40.206, is one of three KMS servers that handle the Windows Activations for Azure VMs globally.
Next, we needed to allow this traffic through the Azure Firewall. We added a rule collection called To-Internet and applied 1 rule with the following details:
Name: KMS Activation
Source type: IP Address
Destination Ports: 1688
Destination Type: IP Address
We are basically allowing any connections from 192.168.2.0/24 subnet to KMS servers through the internet.
Let’s test the connection. Run this command in your Azure VM PowerShell session:
Test-NetConnection -ComputerName 220.127.116.11 -port 1688
Port 1688 is an open port on KMS servers used for testing and troubleshooting connectivity. If the connection is successful, you will see TcpTestSucceeded : True, which means that our Azure VM now has connection to KMS servers for windows activation and all other traffic will be sent to on-prem.
If you look at your Azure Firewall logs, you will see the following log which confirms that the traffic went through the firewall and the TCP request was allowed to the internet.
Forced tunneling continues to be a critical security requirement for enterprise security teams. The need to inspect and audit internet bound traffic sourced from Azure resources grows as our adoption into the cloud expands. Configuring the Azure Firewall to force tunnel all its respective traffic downstream for additional auditing allows security teams to meet these stringent requirements and to maintain compliance for their environments. Additionally, having the capability to split specific traffic to meet other dependencies and requirements is key in maintaining an operational and controlled infrastructure.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.