• Skip to main content
  • Skip to secondary menu
  • Skip to primary sidebar
  • Skip to footer
  • Home
  • Disclaimer & Policy

Elan Shudnow's Blog

MVP Logo
  • Azure
  • Exchange
  • Lync

Front Ending Azure Virtual Machines and Source IPs – Part 2

December 18, 2019 by Elan Shudnow Leave a Comment

Part 1

  • 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

Part 3

  • 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.

This image has an empty alt attribute; its file name is SourceIPVMs11.jpg

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.

Share this:

  • Click to share on X (Opens in new window) X
  • Click to share on LinkedIn (Opens in new window) LinkedIn
  • Click to share on Reddit (Opens in new window) Reddit

Filed Under: Azure Tagged With: Azure, Azure Application Gateway, Azure Firewall, Azure Load Balancer, CDN, Virtual Machines

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

  • GitHub
  • LinkedIn
  • RSS
  • YouTube

More to See

Azure AD User Settings

Pre-creating Azure AD App for Azure Migrate

January 24, 2023 By Elan Shudnow

Azure Runbooks Connecting to Exchange Online and Microsoft Graph

July 22, 2022 By Elan Shudnow

Using Python 3.8.0 Azure Runbooks with Python Packages

July 11, 2022 By Elan Shudnow

Preserving UNC Path after Azure Files Migration using DFS-N

April 10, 2022 By Elan Shudnow

Tags

ACR Always Encrypted Ansible Automation Availability Sets Availability Zones Azure Azure Active Directory Azure Application Gateway Azure Files Azure Firewall Azure Key Vault Azure Load Balancer Azure Migrate Azure Monitor Azure Web App CDN Cluster DevOps DFS Docker DPM Event Grid Exchange Exchange 2010 Exchange Online Function App ISA iSCSI Log Analytics Logic App Lync Microsoft Graph OCS Office Personal PowerShell Proximity Placement Groups Runbook SCOM Storage Accounts Symantec Virtual Machines Windows Server 2008 Windows Server 2008 R2

Footer

About Me

Microsoft Cloud Solution Architect focused on Azure IaaS, PaaS, DevOps, Ansible, Terraform, ARM and PowerShell.

Previously a 6x Microsoft MVP in Exchange Server and Lync Server.

My hobbies include watching sports (Baseball, Football and Hockey) as well as Aviation.

Recent

  • GRS Storage and BCDR Considerations
  • Pre-creating Azure AD App for Azure Migrate
  • Azure Runbooks Connecting to Exchange Online and Microsoft Graph
  • Using Python 3.8.0 Azure Runbooks with Python Packages
  • Preserving UNC Path after Azure Files Migration using DFS-N

Search

Tags

ACR Always Encrypted Ansible Automation Availability Sets Availability Zones Azure Azure Active Directory Azure Application Gateway Azure Files Azure Firewall Azure Key Vault Azure Load Balancer Azure Migrate Azure Monitor Azure Web App CDN Cluster DevOps DFS Docker DPM Event Grid Exchange Exchange 2010 Exchange Online Function App ISA iSCSI Log Analytics Logic App Lync Microsoft Graph OCS Office Personal PowerShell Proximity Placement Groups Runbook SCOM Storage Accounts Symantec Virtual Machines Windows Server 2008 Windows Server 2008 R2

Copyright © 2025 · Magazine Pro on Genesis Framework · WordPress · Log in