Unable to use Azure services after changing Public Network Access from "All networks" to "Selected IP addresses

Add the public egress IP actually seen by each target service—not the workstation’s private address or an Azure resource’s nominal IP—and configure Storage and Azure AI Search separately because their firewall capabilities differ.

1. Identify the request’s real source

The address to allow depends on where the request originates:

• Local PC or corporate network: allow the internet-facing IPv4 address after any corporate proxy, VPN, NAT gateway, or Azure Firewall SNAT.
• Azure workload: allow its effective outbound public IP, which might be an App Service/Function outbound address, NAT Gateway public IP, or Azure Firewall public IP.
• Do not enter 10.x.x.x, 172.16–31.x.x, or 192.168.x.x; Storage IP rules accept public IPv4 addresses only.^1^

If Azure Firewall controls outbound traffic, inspect its network-rule logs or public IP configuration and allow the firewall’s translated public IP. If a VPN or proxy is involved, test without it or obtain the egress IP from the network administrator.

2. Configure each resource

Azure AI Search

1. Open Azure portal → Azure AI Search service → Settings → Networking.
2. Select Public network access → Selected IP addresses.
3. Under IP Firewall, select Add your client IP address for the current portal client.
4. Add the other clients’ effective public egress addresses or CIDR ranges.
5. Select Save and wait at least 15 minutes before testing.

Requests outside the allowlist receive 403 Forbidden.^2^

Storage account

1. Open Storage account → Security + networking → Networking.
2. Under Resource settings: Virtual networks, IP addresses, and exceptions, select View.
3. Enter the effective public IPv4 address or CIDR range.
4. Select Save.^3^

Storage authentication still applies after the network request is admitted; the firewall rule does not grant data permissions.^4^

3. Apply the matching network-path branch

• The client is in a VNet subnet with a Storage service endpoint: add a Storage virtual-network rule for that subnet, not an IP rule. Once a service endpoint is enabled, traffic uses a private source address and public IP rules for that subnet no longer apply.^4^
• An Azure service in the same region is calling Storage: do not rely on that service’s public outbound IP. Same-region Azure services use private Azure addresses, so Storage public-IP rules cannot identify them. Use a supported virtual-network rule, resource-instance rule, or trusted-service exception, depending on the caller.^1^
• Azure AI Search indexer is reading Storage: whitelisting the PC that starts the indexer is insufficient—the data request originates from Azure AI Search. Depending on topology, configure the Search service IP plus the regional AzureCognitiveSearch service-tag ranges, or use the documented trusted-service/resource-instance option. Firewall updates can take 5–10 minutes.^5^
• Another Azure service is calling Azure AI Search: add that service’s effective outbound addresses. The Search “trusted services” exception is not a blanket exception for every Azure service; the documented list includes specific Microsoft Cognitive Services and Machine Learning resource types, and requires managed identity plus an appropriate Search role.^2^

Test the direct data endpoint after propagation. If the result is 403, the request reached the service but its source was not admitted or authorization failed. A timeout or DNS failure instead points to the routing, private-endpoint, or DNS path rather than the IP allowlist.

References

1. Guidelines and limitations for the Azure Storage firewall
2. Configure network access and firewall rules for Azure AI Search
3. Create an IP network rule for Azure Storage
4. Firewall rules and network access control for Azure Blob, Data Lake, Queue, and Table Storage
5. Configure IP firewall rules to allow indexer connections from Azure AI Search