- 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 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 #8 – Internet Clients to Azure Front Door to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: https://elanfrontdoor.azurefd.net (Azure Front Door FQDN) to 23.96.182.139 (VM Public IP).
A QuickStart is available here showing how to deploy Azure Front Door to Front End Global HTTP Traffic. In our case, we are simply forwarding Front Door Traffic to one VM.
Make sure you update your VM’s NSG to allow Front Door Backend to talk to your VM.
Let’s run the test.
The results are that the Source IP of my home computer’s Public IP is not retained when traversing through Azure Front Door. We see the Source IP in WireShark is 147.243.19.178. As Azure Front Door Service is a globally distributed service and it rewrites the Source IP, be very cautious when restricting what filtering you do for traffic coming into your VM.
Thankfully, Microsoft provides the IP Address space used for Azure Front Door Backend Service. This information is provided here. See the section, “How do I lock down the access to my backend to only Azure Front Door?”
One thing I notice differently when using Azure Front Door, is that there are a lot more TCP packets that flow into WireShark than without using Front Door.
Scenario #9 – Internet Clients to Azure Front Door to Application Gateway V2 Public Listener IP to Virtual Machine Private IP
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: https://elanfrontdoor.azurefd.net (Azure Front Door FQDN) to 23.100.227.3 (Application Gateway V1 Public Listener IP) to 10.50.1.6 (VM Private IP).
If you have been following along, in Part 1, we changed our Application Gateway Listener to Private. Change it back to using the Public IP Configuration.
You will also want to update Front Door to point to your Application Gateway.
Let’s wait 10 minutes before testing to give a chance for the Front Door Service to fully replicate the changes to all Front Door POPs worldwide to ensure we are getting accurate results in our Wireshark. According to the Frequently Asked Questions here, it mentions, ” A new Front Door creation or any updates to an existing Front Door takes about 3 to 5 minutes for global deployment. That means in about 3 to 5 minutes, your Front Door configuration will be deployed across all of our POPs globally.” So we’ll wait 10 minutes just to be sure.
After waiting patiently, let’s test.
The results are that the Source IP of my home computer’s Public IP is not retained when traversing Front Door and then through 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. In this case, my home machine hits the Azure Front Door, rewrites the original Source IP, then hits the Application Gateway, and the Source IP is rewritten again.
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 #10 – Internet Clients to Content Delivery Network (CDN) to Virtual Machine
Source IP: 50.x.x.x (My Home’s Public IP)
Destination: Azure Akamai CDN to 10.50.1.6 (VM Private IP).
Make sure you update your VM’s NSG to allow CDN to talk to your VM. I could never find a CDN Service Tag to allow the traffic in. According to this article here, the IP Range for CDN is 147.243.0.0/16. Through testing, I found that is only for Microsoft CDN. As part of this test, I used Akamai CDN because I wanted to show you something.
We’ll configure the NSG to allow this Source to talk to our VM. The IP Range may change at some point in the future when you are reading this article. So be sure to check for the latest ranges to open.
Let’s test.
Unfortunately, no luck. My guess was the wrong IP Range is allowed through the NSG and that IP Range is only for Microsoft’s CDN. So I decided to enable NSG Flow Logging to see. Before I do, I hit refresh a bunch of times to ensure I can differentiate the denied IP Addresses in the NSG Flow Logs. You can follow these instructions here.
After enabling NSG Flow Logging to my Storage Account, I used Azure Storage Explorer to navigate to my Storage Account.
The insights-logs-networksecuritygroupflowevent container will show up. Navigate all the way into the VERY long folder structure till you see a JSON file.
Download the JSON file and open it up. I am using Visual Studio Code. What I see is a bunch of IP Addresses trying to hit port 80 hitting the NSG’s Deny Rule.
{
"rule": "DefaultRule_DenyAllInBound",
"flows": [
{
"mac": "000D3AD2DB52",
"flowTuples": [
"1576630712,36.x.x.x,10.50.1.6,52016,80,T,I,D,B,,,,",
"1576630712,76.x.x.x,10.50.1.6,61426,80,T,I,D,B,,,,",
"1576630713,76.x.x.x,10.50.1.6,61426,80,T,I,D,B,,,,",
"1576630715,76.x.x.x,10.50.1.6,61426,80,T,I,D,B,,,,",
"1576630716,222.x.x.x,10.50.1.6,50829,445,T,I,D,B,,,,",
"1576630717,23.67.252.23,10.50.1.6,57840,80,T,I,D,B,,,,",
"1576630719,23.67.252.23,10.50.1.6,57840,80,T,I,D,B,,,,",
"1576630721,23.67.252.23,10.50.1.6,57840,80,T,I,D,B,,,,",
"1576630722,23.67.252.23,10.50.1.6,58110,80,T,I,D,B,,,,",
"1576630724,23.67.252.23,10.50.1.6,58110,80,T,I,D,B,,,,",
"1576630726,23.67.252.23,10.50.1.6,58110,80,T,I,D,B,,,,",
"1576630728,23.67.252.13,10.50.1.6,51626,80,T,I,D,B,,,,",
"1576630729,23.67.252.13,10.50.1.6,51626,80,T,I,D,B,,,,",
"1576630731,23.67.252.13,10.50.1.6,51626,80,T,I,D,B,,,,",
"1576630733,23.67.252.13,10.50.1.6,51807,80,T,I,D,B,,,,",
"1576630734,23.67.252.13,10.50.1.6,51807,80,T,I,D,B,,,,",
"1576630736,23.67.252.13,10.50.1.6,51807,80,T,I,D,B,,,,",
"1576630738,23.67.252.28,10.50.1.6,45625,80,T,I,D,B,,,,",
"1576630739,23.67.252.28,10.50.1.6,45625,80,T,I,D,B,,,,",
"1576630741,23.67.252.28,10.50.1.6,45625,80,T,I,D,B,,,,",
"1576630743,23.67.252.28,10.50.1.6,45767,80,T,I,D,B,,,,",
"1576630744,23.67.252.28,10.50.1.6,45767,80,T,I,D,B,,,,",
"1576630746,23.67.252.28,10.50.1.6,45767,80,T,I,D,B,,,,",
"1576630748,76.x.x.x,10.50.1.6,61546,80,T,I,D,B,,,,",
"1576630749,76.x.x.x,10.50.1.6,61546,80,T,I,D,B,,,,",
"1576630751,76.x.x.x,10.50.1.6,61546,80,T,I,D,B,,,,"
]
}
]
}A whole bunch of 23.67.252.13 IP Addresses. Good thing I hit refresh a bunch of times. Helped me immediately point out the IP Address. After Googling who this IP Address belongs to, BINGO, it belongs to Akamai!
I’m going to put 23.67.0.0/16 in the NSG as an allowed Source IP to my 10.50.1.6 VM over port 80 and we’ll try again. I’m not sure exactly what Akamai IP Address Ranges are needed, so please don’t put in 23.67.0.0/16. This is for me just to make sure I get an allow in case my next test decides to use a different 23.67.x.x address.
My new NSG Rule is as follows:
Let’s test again.
Success!
The results are that the Source IP of my home computer’s Public IP is not retained when traversing the CDN. The Source IP is the 23.x.x.x IP that we discovered in the NSG Flow Logs that we had to add to the allowed list of IP Addresses. When utilizing Akamai or Verizon for CDN and need to add some extra filtering or need to know the specific IP Range to allow for the NSG, reach out to Akamai and/or Verizon to get a current list of IP Addresses/Ranged you will need to allow.
Thanks for reading all the way to the end. Hopefully you found this valuable. And if you have any questions, as always, feel free to comment.
Leave a Reply