- Prerequisites for how I did my tests
- Scenario #1 – Internet Clients Directly to Virtual Machine Public IP
- Scenario #2 – Internet Clients to Public Load Balancer to Virtual Machine Private IP
- Scenario #3 – Internet Clients to Application Gateway V1 Public Listener IP to Virtual Machine Private IP
- Scenario #4 – Internet Clients to Application Gateway V2 Public Listener IP to Virtual Machine Private IP
- Scenario #5 – Internal Clients to Application Gateway V2 Private Listener to Virtual Machine Private IP
Part 2
- Scenario #5 – Internet Clients to Azure Firewall Public IP to Virtual Machine Private IP
- Scenario #6 – Internet Clients to Azure Firewall to Internal Load Balancer to Virtual Machine Private IP
- Scenario #7 – Internet Clients to Azure Firewall to Azure Application Gateway V2 Private Listener IP to Virtual Machine Private IP
- Scenario #8 – Internet Clients to Azure Front Door to Virtual Machine Private IP
- Scenario #9 – Internet Clients to Azure Front Door to Application Gateway V2 to Virtual Machine Private IP
- Scenario #10 – Internet Clients to Content Delivery Network (CDN) to Virtual Machine
Scenario #5 – Internet Clients to Azure Firewall Public IP to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: 52.252.163.189 (Azure Firewall Public IP) to 10.50.1.6 (VM Private IP). Azure Firewall lives on 10.50.2.0/24 subnet and is configured as having a Private IP of 10.50.2.4.
A QuickStart is available here showing how to deploy an Azure Firewall to allow DNAT (Port Forwarding) to Front End HTTP Traffic.
The results are that the Source IP of my home computer’s Public IP is not retained when traversing an Azure Firewall. An Azure Firewall must be deployed into its own dedicated subnet that has a name of AzureFirewallSubnet. In our case, this dedicated subnet for the Azure Firewall is 10.50.2.0/24. We see the Source IP in WireShark is 10.50.2.5. Is that the actual Private IP Address of our Azure Firewall? Let’s take a look.
We can see the Private IP Address of our Azure Firewall is 10.50.2.4. That is different than the Source Private IP listened in Wireshark. Therefore, it’s clear that the traffic passing through Azure Firewall is then being passed off through some obfuscated Load Balancer before being passed off to the Virtual Machine.
Unfortunately, Microsoft does not allow us to explicitly see what Private IP Addresses are used in the backend connection. Therefore, if doing any kind of port filtering from your Azure Firewall subnet, it would be a wise choice to allow the entire Azure Firewall subnet to communicate to your VM over whatever ports you need as the private IP the Azure Firewall uses to communicate to your VM can change at any point.. In our case, we would allow port 80 from the Azure Firewall Subnet to our VM.
Scenario #6 – Internet Clients to Azure Firewall Public IP to Azure Internal Load Balancer to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: 52.252.163.189 (Azure Firewall Public IP) to 10.50.1.100 (Internal Load Balancer Static Private IP) to 10.50.1.6 (VM Private IP). Azure Firewall lives on 10.50.2.0/24 subnet and is configured as having a Private IP of 10.50.2.4.
The results are that the Source IP of my home computer’s Public IP is not retained when traversing an Azure Firewall > Internal Load Balancer > Azure VM. An Azure Firewall must be deployed into its own dedicated subnet that has a name of AzureFirewallSubnet. In our case, this dedicated subnet for the Azure Firewall is 10.50.2.0/24.
If you recall from Part 1, an Azure Load Balancer retains the original Source IP. And from Scenario #5, you can see that Azure Firewall rewrites the original Source IP. Therefore we can see what is happening is that Azure Firewall rewrites the original IP to 10.50.2.5 (since 10.50.2.0/24 subnet is the Azure Firewall subnet) and then the Internal Load Balancer retains the original Source IP.
We see the Source IP in WireShark is 10.50.2.5. Is that the actual Private IP Address of our Azure Firewall? Let’s take a look.
We can see the Private IP Address of our Azure Firewall is 10.50.2.4. That is different than the Source Private IP listened in Wireshark. Therefore, it’s clear that the traffic passing through Azure Firewall is then being passed off through some obfuscated Load Balancer before being passed off to the Virtual Machine.
Unfortunately, Microsoft does not allow us to explicitly see what Private IP Addresses are used in the backend connection. Therefore, if doing any kind of port filtering from your Azure Firewall subnet, it would be a wise choice to allow the entire Azure Firewall subnet to communicate to your VM over whatever ports you need as the private IP the Azure Firewall uses to communicate to your VM can change at any point.. In our case, we would allow port 80 from the Azure Firewall Subnet to our VM.
This Scenario looks identical to the results of Scenario #5. Which it ultimately is as far as Source IP that gets passed to the VM. Again, this is because the Internal Load Balancer doesn’t rewrite the Source IP. Here’s a look at my Internal Load Balancer Config as well as the Azure Firewall showing the traffic is indeed passing through the Internal Load Balancer.
Scenario #7 – Internet Clients to Azure Firewall to Azure Application Gateway V2 Private Listener IP to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: 52.252.163.189 (Azure Firewall Public IP) to 10.50.0.10 (Application Gateway V2 Private Listener Static IP) to 10.50.1.6 (VM Private IP). Azure Firewall lives on 10.50.2.0/24 subnet and is configured as having a Private IP of 10.50.2.4.
The results are that the Source IP of my home computer’s Public IP is not retained when traversing an Azure Firewall > Azure Application Gateway V2 Private IP Listener > Azure VM. An Azure Firewall must be deployed into its own dedicated subnet that has a name of AzureFirewallSubnet. In our case, this dedicated subnet for the Azure Firewall is 10.50.2.0/24. An Azure Application Gateway must also be deployed into its own dedicated subnet. In our case, this dedicated subnet for the Azure Application Gateway is 10.50.0.0/24.
If you recall from Part 1, an Azure Application Gateway rewrites the original Source IP. And from Scenario #5, you can see that Azure Firewall rewrites the original Source IP as well. In this case, my home machine hits the Azure Firewall, rewrites the original Source IP, then hits the Application Gateway, and the Source IP is rewritten again. Therefore, the Source IP displayed on our VM is the overwritten IP Address from the Azure Application Gateway Subnet.
You can see the Private IP configuration of our Azure Application Gateway in the following screenshot.
And we can see our Azure Firewall is pointing to the Private IP of the Application Gateway.
What’s interesting in this test is that even though we configured our Application Gateway to use a Private IP Configuration with a Static IP of 10.50.0.10 (which you can clearly see in the above screenshot where Azure Firewall is sending this traffic to the Azure Application Gateway via the Static IP of 10.50.0.10. But the Source IP in Wireshark shows the Source IP as 10.50.0.7.
Unfortunately, Microsoft does not allow us to explicitly see the Private IP Address of an Application Gateway or what Private IP Addresses are used in the backend connection. Therefore, if doing any kind of port filtering from your dedicated Application Gateway subnet, it would be a wise choice to allow the entire application gateway subnet to communicate to your VM over whatever ports you need as the private IP the Application Gateway uses to communicate to your VM can change at any point.. In our case, we would allow port 80 from the Application Gateway Subnet to our VM.
In Part 3, we take a look at additional scenarios with devices such as Azure Front Door and Content Delivery Network. If you are following along and testing, keep your Application Gateway V2 around as it’ll continue to be leveraged in our tests.
Leave a Reply