Deploy Azure Firewall to inspect traffic to a private endpoint

Introduction

 

Preventing sensitive data, such as customer personal records like Date of Birth or SSN, from traversing the internet helps you maintain compliance with regulations such as GDPR, CCPA and payment card industry (PCI). It is critical for customers in the financial services, healthcare, and government sectors. Azure Private Link, when combined with Azure Firewall, ensures sensitive traffic not only stays on the Azure network but is also monitored, audited, and secured.

 

Securing traffic using Azure Firewall

 

To help meet data security, customers use Azure Firewall to inspect traffic flowing between their on-premises networks & cloud infra. Traffic to the private endpoints is inspected/filtered, allowing only specific sources to connect as recommended when you are adopting Zero Trust principles to Azure Infrastructure.

In this blog we will discuss the scenario adopted by Contoso, and provide guidance:

 

1. To deploy a Private Endpoint in a Hub and Spoke topology using Terraform template.
2. To test traffic to Private Endpoint, inspecting and filtering it with Azure Firewall.

 

Deployment Scenarios

 

Contoso has started using Azure Database for MySQL server deployed in Azure and the security team requested to block the traffic coming from the Internet, allowing only traffic from a specific internal network to connect to the MySQL database, and having central logs available for security management and auditing. In order to achieve both requests, Contoso made the decision of using Private Endpoint to enable private access using an internal IP address from their virtual network, and to deploy Azure Firewall to inspect/filter the traffic to MySQL.

 

Contoso also had concerns about performance when adding Azure Firewall in the data path. However, Azure Firewall is a firewall as a service with built-in high availability and cloud scalability which gradually scales when average throughput and CPU consumption is at 60%. For more details about performance, check out Azure Firewall performance | Microsoft Learn.

 

There are 4 different scenarios to inspect/filter traffic destined to a private endpoint:

 

1. Hub and spoke architecture – Dedicated virtual network for private endpoints.
2. Hub and spoke architecture – Shared virtual network for private endpoints and virtual machines.
3. Single virtual network
4. On-premises traffic to private endpoints

 

Contoso deployed the second scenario as demonstrated below, to optimize costs and to simplify the management of the virtual network deployments. This scenario is implemented when:

 

1. It is not possible to have a dedicated virtual network for the private endpoints.
2. When only a few services are exposed in the virtual network using private endpoints.

 

Note: Depending on the overall architecture, it is possible to run into the 400 routes limit per Route Table.

 

 

Below you will find the resources deployed by Contoso’s team:

 

 

If you want to deploy the same environment for testing, you can use this Terraform template which will deploy and configure all the resources needed as listed in the screenshot above.

 

To deploy the environment via Terraform template, you will need to download the file HubAndSpoke.tf. After downloading the file, you will need to:

 

• Configure your Terraform environment. Example using Terraform on Windows with PowerShell: Install Terraform on Windows with Azure PowerShell | Microsoft Learn
• Log in into your Azure Subscription via PowerShell or CLI:
  • Powershell: Login-AzAccount
  • CLI: az login
• Run the following commands:
  • terraform init
  • terraform plan -out HubAndSpoke.tfplan
  • terraform apply HubAndSpoke.tfplan

 

Validating the environment and the configurations

 

Once the deployment is completed, follow the following steps to ensure you have the lab environment configured correctly.

 

1. Check if you have the DNS zone for the respective private endpoint service created. In this example Contoso is using MySql and the zone created is privatelink.mysql.database.azure.com. You also need to confirm if you have the A record for the private endpoint.

 

 

2. In the Private DNS zone resource, check if the virtual network link to the Spoke virtual network is created, allowing it to resolve the private endpoint A record.

 

 

3. Then check the route table to confirm that you have the route to the Private Endpoint added correctly.

 

 

Note: When you deploy a private endpoint, the virtual machines will have /32 system routes pointing to each private endpoint. One route per private endpoint is required to route traffic through Azure Firewall.

 

4. Check the Diagnostic setting of your Firewall. This configuration is needed to send the Firewall logs of Network and Application rule hits.

 

 

5. Then you need to check the Firewall rules. In this example we are using Network rules to allow traffic to the MySql via port 3306.

 

 

Important

 

Using application rules over network rules is recommended when inspecting traffic destined to private endpoints to maintain flow symmetry. If Azure Firewall with network rules are used, SNAT must be configured for traffic destined to private endpoints.

 

In this case, Contoso is using a MySql service which uses TCP port 3306. Since it is not HTTP, HTTPS or MSSQL protocol, Application rule cannot be used, and SNAT needs to be configured for traffic destined to private endpoints using the Private IP Ranges (SNAT) feature in Azure Firewall as follows:

 

 

Testing the environment

 

To start testing the lab you just deployed, you will need to connect into the client VM. In this POC we are using a Windows VM, and to log in into the VM we have created a DNAT rule via Azure Firewall.

 

 

To log in to the VM you will use the credential defined in the Terraform template at lines 292 and 293. Once you are logged into the client VM, you will run a Test-NetConnection command via PowerShell to test connectivity to the private endpoint.

 

The private endpoint deployed by Contoso is “4mk3nw-mysql.mysql.database.azure.com”. So, for your test, verify what random name has been assigned to the MySql server and replace it in the Test-NetConnection command:

 

Test-NetConnection -ComputerName <MYSQLRESOURCENAME>.mysql.database.azure.com -Port 3306

 

 

Here you can see that the client VM has resolved the internal IP address “10.10.11.68” (Private Endpoint’s IP) and the TcpTestSucceeded is True.

 

Now to confirm that the traffic went through the Azure Firewall, you will need to run the following KQL query:

 

AZFWNetworkRule
| where DestinationPort == 3306

 

 

Then here, you will find the logs for all the connection attempts to port 3306.

 

Conclusion

 

A private endpoint is important for building a secure environment allowing you to connect privately to the Azure PaaS resources. However, not all the internal traffic should be trusted and that is why it is recommended to inspect and block traffic, allowing only connections coming from known source networks.

 

Azure Firewall is here to help you protect the traffic to the private endpoints, allowing you to have control of the traffic and detailed visibility by using the Firewall logs.