There are a few relatively decent sources of documentation for Azure Networking available, but generally they center around VNET-based scenarios. If you’re trying to stay strictly on PaaS offerings, things tend to not be quite as clear. The lack of information makes sense in a way… why do you need to know anything about Azure-to-Azure PaaS routing? The answer is–Security.
The routing itself seems straight-forward enough. If one Azure service is talking to another Azure service, the traffic never leaves the Azure network. What if you’re designing a system leveraging the Azure SQL PaaS service and you want to load some data from a blob on an Azure Storage account, and that file needs strict security controls?
Obviously, you’d want to enforce secure transfer at the storage account level and leverage the storage encryption service. It is also highly recommended to leverage firewall rules at the storage account level and this is where it becomes a little unclear. When Azure SQL initiates a connection to the storage account, what will the source IP be? If you are like me, you assumed it’d be one of the addresses listed in the Azure Datacenter IP Address Ranges document. Even then, which one?
As it turns out, none of them. After locking down a storage account via the storage firewall service, I saw an interesting failure. The source IP of the Azure SQL server was actually an address within the 100.64.0.0/10 range. I had never heard of this range, but apparently it was designed and reserved as a Carrier-grade NAT address space to be used only within a provider’s network.
;;2019-10-04T14:00:20.1266850Z;GetBlobProperties;SASIpAuthorizationError;403;4;4;sas;;storageaccount;blob;"https://storage.blob.core.usgovcloudapi.net/stuff/MoreStuff/hello/AFile.txt?sv=2018-03-28&si=AccessPolicyName&sr=c&sig=XXXXX";"/";06e1138d-901e-0081-6ebc-7a903e000000;0;100.75.52.43:41306;2018-03-28;379;0;110;0;0;;;;;;"SQLBLOBACCESS";;
So how do you restrict access? Simply add a firewall rule to your storage account that allows 100.64.0.0/10! While I’ve seen a reference to this address space in Azure Virtual Networking documentation, it all revolves around VNETS. I’ve yet to find anything in regards to whitelisting it in a PaaS-only deployment.
Thanks , this helps. can you explain how you added a firewall rule to your storage account that allows 100.64.0.0/10. I was trying to add it but couldnt do it through VNET and the ip option just enables public ip. A screenshot would help if possible
essentially the sql ip i am seeing is 10.0.0.0/8 instead of the 100.64.0.0
If you are seeing something in the 10.0.0.0/8 range, I would imagine it is a Sql Server deployed directly in to a VNET and not actually a PaaS Azure Sql server. Are you running Sql on a VM? Or maybe a Managed Instance? If you’re running Sql on a VM, you wouldn’t see something in the 100.64.0.0 range, but instead something more along the lines of what you’re seeing… an RFC reserved address. Please confirm how your Sql Server is deployed.
Oops, I overlooked this somehow. You can’t add it as a VNET, but it will allow you to add it where you normally add public IP addresses. Just add it there and save, it’ll work.
This article is great. I see a similar issue when trying to access Azure Storage from Azure Logic Apps through SAP connector. One Question would be how did you find source IP range 100.64.0.0 range? Error log shows Client IP as 100.75.52.43:41306
Awesome, glad you found it helpful. As you probably know, 100.75.52.43 is a part of the 100.64.0.0/10 range. I found the IP by enabling Logging / Diagnostics on the Storage Account. You can find more information about that here.