Blob storage firewall rules block access from VNet subnet despite service endpoint

Cloud Platforms Microsoft Azure
, , , , , , , ,
1

Our archiving service running in Azure App Service can’t access a storage account after we enabled firewall rules. The storage account is configured with ‘Selected networks’ and we added the App Service’s VNet subnet to the firewall rules, but we’re getting 403 errors.

The error response:

{"error": {"code": "AuthorizationPermissionMismatch",
"message": "This request is not authorized to perform
this operation using this permission."}}

The subnet has Microsoft.Storage service endpoint enabled. The firewall configuration shows our subnet in the allowed list. We’ve verified the App Service is using VNet integration and the subnet assignment looks correct. Storage account is using standard tier with hot access tier.

Is there something specific about service endpoints and firewall rules interaction that we’re missing? The archiving jobs are failing and we have a backlog building up.

2

Just to add - when you enable Route All, be aware it changes the egress path for all traffic, not just storage. If your App Service connects to other external services, those will now route through the VNet too. Make sure your subnet has appropriate NSG rules and a NAT Gateway or route to an NVA if you need specific egress IPs for external services. The service endpoint itself is just a route optimization within Azure’s backbone network.

3

Check if ‘Allow Azure services on the trusted services list’ is enabled in your storage account firewall settings. Even with VNet service endpoints, some Azure services need this exception. Also verify the App Service’s outbound IP addresses - if VNet integration isn’t forcing all traffic through the VNet, some requests might still use the App Service’s public IPs which would be blocked by your firewall rules.

4

Yes, that’s likely your issue! With Route All disabled, only RFC1918 traffic (private IPs) goes through the VNet - traffic to Azure Storage public endpoints bypasses the VNet and uses App Service’s public IPs. Enable ‘Route All’ in your VNet integration settings. This forces ALL outbound traffic through the integrated subnet, allowing the service endpoint to work. After enabling, your storage requests will originate from the subnet and match your firewall rules.

5

Perfect timing to close this out. Here’s the complete picture of storage account firewall rules and VNet service endpoints:

Root Cause Analysis: App Service VNet integration with ‘Route All’ disabled only routes RFC1918 (private IP) traffic through the integrated subnet. Azure Storage public endpoints (*.blob.core.windows.net) are public IPs, so traffic bypassed the VNet and originated from App Service’s public outbound IPs, which weren’t in the storage firewall allowlist.

Complete Solution:

1. Enable Route All on VNet Integration: In App Service → Networking → VNet integration → Enable ‘Route All’


az webapp config set --resource-group rg-apps \
  --name my-app --vnet-route-all-enabled true

2. Verify Service Endpoint Configuration: Ensure Microsoft.Storage service endpoint is enabled on the subnet:


az network vnet subnet update --resource-group rg-network \
  --vnet-name prod-vnet --name app-subnet \
  --service-endpoints Microsoft.Storage

3. Configure Storage Account Firewall: Add the subnet to storage account network rules:

  • Networking → Firewalls and virtual networks → Selected networks
  • Add existing virtual network → Select VNet and subnet
  • Enable ‘Allow Azure services on the trusted services list’ as backup

How Service Endpoints Work: Service endpoints create optimized routes in the subnet’s route table that direct traffic to Azure Storage through Microsoft’s backbone network instead of the internet. The traffic still uses public IPs but originates from your VNet’s address space, allowing firewall rules to identify and permit it.

Route All vs Default Routing:

  • Default: Only RFC1918 (10.x, 172.16.x, 192.168.x) routed through VNet
  • Route All: ALL outbound traffic routed through VNet (required for service endpoints to work)

Verification Steps:

  1. Check effective routes: Azure Portal → Subnet → Effective routes (should see Microsoft.Storage service tag route)
  2. Test storage access from App Service
  3. Review storage account metrics: Check requests by ‘Authentication’ dimension show ‘SAS’ or ‘Account Key’ from VNet

Additional Considerations:

  • Subnet must have sufficient IP addresses for App Service scale-out
  • NSG rules on subnet must allow outbound to Storage service tag
  • If using private endpoints instead, disable service endpoints and follow different configuration
  • Route All increases data processing charges slightly for VNet integration

The key takeaway: VNet integration alone isn’t enough - Route All must be enabled for service endpoints to function with App Service, as storage endpoints use public IPs that would otherwise bypass the VNet routing.

6

Enabled Route All and the 403 errors stopped immediately! The archiving service is now processing the backlog. I can see in the storage account metrics that requests are coming from the VNet now. Thanks for the clarification on how VNet integration and service endpoints interact.

7

I enabled the trusted services option but still seeing 403 errors. Looking at the App Service configuration, I see ‘Route All’ is disabled under VNet integration settings. Could this be causing traffic to bypass the service endpoint? Should I enable Route All to force all outbound traffic through the VNet?