An example of Azure <-> Azure PaaS resource network routing “never leaving the backbone” and how it impacts Security.

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


So how do you restrict access? Simply add a firewall rule to your storage account that allows! 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.

Join the Conversation


  1. Thanks , this helps. can you explain how you added a firewall rule to your storage account that allows 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

      1. If you are seeing something in the 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 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.

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

  2. 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 range? Error log shows Client IP as

    1. Awesome, glad you found it helpful. As you probably know, is a part of the range. I found the IP by enabling Logging / Diagnostics on the Storage Account. You can find more information about that here.

Leave a comment

Close Bitnami banner