Overview
There are many different network devices that can front-end traffic before that traffic hits a Virtual Machine. In this article, we’ll take a look at several of these devices and what Source IP is provided when connecting to a Virtual Machine. This can be useful if you are doing any kind of firewalling and are unsure what the Source IP Address is that is hitting your VM in order to know what to allow.
The front-end devices we will test include:
- None – Internet client connects directly to the Public IP of a Virtual Machine
- Azure Public Load Balancer
- Azure Application Gateway v1
- Azure Application Gateway v2
- Azure Firewall
- Azure Front Door
- Azure CDN
This will also include a mixture of the above such as Azure Firewall to Internal Load Balancer to Virtual Machine, Azure Firewall to Application Gateway (no Public/Internet Listener), etc…
Going into the installation of the various devices that will Front End our VM traffic is out of the scope of this article. It is simply to document and share how the Source IP gets displayed on the Virtual Machine for future reference.
This will be a multiple-part series.
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
- Scenario #5 – Internet Clients to Azure Firewall 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
Prerequisites
- Provision a Windows Server Virtual Machine (VM)
- Install and Configure WireShark
- Install barebones Internet Information Services (IIS) to allow port 80 HTTP connections.
- Configure Azure Network Security Group (NSG) to allow port 80
Provision a VM
Follow a QuickStart on how to provision a VM.
Install and Configure WireShark
Install WireShark using this guide here.
We will also be using a WireShark Display Filter to reduce the amount of noise in the network capture. The WireShark Display Filter used is as follows:
tcp.port == 80 and (ip.dst == 10.50.1.6) and !(ip.src == 168.63.129.16)168.63.129.16 is the IP that Health Probes from a Load Balancer use to connect. Therefore, we will exclude this IP.
As a side note, if you want to see why ip.src or ip.dst or ip.addr != is incorrect syntax, see the documentation here and see section 6.4.7.
Install barebones Internet Information Services
You can easily install IIS using PowerShell (launched as Administrator) using the below command. I included the Management Tools installation in case you want to make any changes:
Install-WindowsFeature -name Web-Server -IncludeManagementToolsOnce installed, you will see the following:
To ensure we have a functioning barebones website, open a browser and navigate to https://127.0.0.1
Configure Azure Network Security Group (NSG) to allow port 80
Use this guide here on how to configure your NSG to allow an inbound port.
What you should end up with is an Inbound Rule that looks similar to the following. You can change the Source to the entire Internet using a Service Tag and Destination to your Virtual Network instead of a specific IP Address. I decided to lock it down tightly during my testing. Principal of Least Priviledge! As we get deeper into the scenarios, you will see there are additional NSG rules that will be required to allow access via Azure Front Door and Azure CDN. More on that later…
Scenario #1 – Internet Clients Directly to Virtual Machine Public IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: 23.96.182.139 (VM Public IP) to 10.50.1.6 (VM Private IP)
The results are that the Source IP of my home computer’s Public IP is retained. You can see I’m connected to my 23.96.182.139 RDP session running wireshark. The browser is running on my home machine and simply hovering it over my RDP session for the screenshot.
If I remove the 168.63.129.16 portion of the WireShark Display Filter, we can see a Source IP of 168.63.129.16 connect to the VM. This is the Load Balancer Health Probe IP as mentioned earlier. Even though we have a single VM with IIS installed and are connecting directly to the Public IP of the VM over port 80, we are clearly hitting a Public Load Balancer resource that is obfuscated.
Scenario #2 – Internet Clients to Public Load Balancer to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: 52.162.244.4 (Load Balancer Public IP) to 10.50.1.6 (VM Private IP)
A QuickStart is available here showing how to deploy a Load Balancer to Front End HTTP Traffic.
The results are that the Source IP of my home computer’s Public IP is retained even through the Public Load Balancer. This makes sense as we saw that even in Scenario #1, we seem to be connected through a Public Load Balancer that is obfuscated whereas in this scenario, we are specifying a Load Balancer for the traffic to flow through.
You can see I’m connected to my 23.96.182.139 RDP session running wireshark. The browser is running on my home machine and simply hovering it over my RDP session for the screenshot and I’m connecting through the Load Balancer Public IP, not the VM’s Public IP.
Scenario #3 – Internet Clients to Application Gateway V1 Public Listener IP to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: 65.52.197.213 (Application Gateway V1 Public Listener IP) to 10.50.1.6 (VM Private IP). Application Gateway lives on 10.50.0.0/24 subnet.
A QuickStart is available here showing how to deploy an Application Gateway to Front End HTTP Traffic. The article discusses V2 but choose V1 instead for this test. V1 Application Gateways can take 20-30 minutes to deploy.
The results are that the Source IP of my home computer’s Public IP is not retained when traversing an Application Gateway V1. An Application Gateway must be deployed into its own dedicated subnet. In our case, this dedicated subnet for the Application Gateway is 10.50.0.0/24. It is clear that the Source IP is being overwritten with the Private IP Address of the Application Gateway.
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.
Scenario #4 – Internet Clients to Application Gateway V2 Public Listener IP to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: 23.100.227.3 (Application Gateway V2 Public Listener IP) to 10.50.1.6 (VM Private IP). Application Gateway lives on 10.50.0.0/24 subnet.
A QuickStart is available here showing how to deploy an Application Gateway to Front End HTTP Traffic. The article discusses V2. V2 Application Gateways will deploy faster than a V1 Application Gateway but will still take at least 10 minutes.
The results are that the Source IP of my home computer’s Public IP is not retained when traversing an Application Gateway V2. An Application Gateway must be deployed into its own dedicated subnet. In our case, this dedicated subnet for the Application Gateway is 10.50.0.0/24. It is clear that the Source IP is being overwritten with the Private IP Address of the Application Gateway.
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. We don’t have a list of explicit Application Gateway Private IPs that are used when connecting to our VMs. 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.
Scenario #5 – Internet Clients to Application Gateway V2 Private Listener IP to Virtual Machine Private IP
Source IP: 10.50.1.5 (I spun up another VM alongside my IIS Virtual Machine)
Destination: 10.50.0.10 (Application Gateway V2 Private Listener Static IP) to 10.50.1.6 (IIS VM Private IP). Application Gateway lives on 10.50.0.0/24 subnet.
For this test, I simply created a Private Frontend IP Configuration with a Private Static IP (Static Private IP required for V2 Gateway) and in the Listener Configuration, re-associated the Listener to use Private Frontend IP Configuration.
The results are that the Source IP of my 2nd VM is not retained when traversing an Application Gateway V2. An Application Gateway must be deployed into its own dedicated subnet. In our case, this dedicated subnet for the Application Gateway is 10.50.0.0/24. It is clear that the Source IP is being overwritten with the Private IP Address 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 in the browser connecting to https://10.50.0.10), the Source IPs on the VM are not the 10.50.0.10.
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 2, we take a look at additional scenarios with Azure Firewall. 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