Azure Storage Account access logs CallerIpAddress is showing Private IP Address

Question

Hello folks,
I have an Azure Storage account that I’m trying to access from an Azure Win19 VM. The storage account is configured to allow public access only from specific public IP addresses.

When I attempt to access the storage blob from the VM, I receive a 403 (Network blockage) error, even though I’ve allowed the public IP assigned by Microsoft under default outbound access, when I check the StorageBlobLogs, the source IP logged (CallerIpAddress) is the private IP of the VM—not the public IP given by MS under default outbound access.

To troubleshoot, I routed the traffic from the VM through our firewall, which has a dedicated public IP assigned via a Public Load Balancer. We can see the traffic hitting the firewall and being allowed. However, when I checked the StorageBlobLogs again, the source IP logged (CallerIpAddress) is the private IP of the firewall instance—not the public IP (again).

Initially, I assumed this was just a logging issue, but the access still fails even though the dedicated public IP is whitelisted.

Could someone please help me understand below:

1. Why does Azure log the private IP (VM’s private IP in default outbound scenario, and firewall’s private IP when forced routing) instead of the public IP?
2. Is there any way to ensure Azure recognizes the public IP for access control?
3. If it's Azure logging issue, can we avoid it?

PFB snippet of the IP entry which we see.

Any guidance would be greatly appreciated.

Answer 1

Hello @Apurva Pathak,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

Thank you for your detailed description of the scenario and sharing the log snippets. Here’s some clarity on what’s happening:

When you access Azure Storage from within Azure using private connectivity options such as Service Endpoints or Private Endpoints, the traffic remains inside Azure’s internal network. In this case, Azure Storage logs the source IP as the private IP address of your VM or firewall, not the public IP. This is expected behavior because the connection never goes out over the public internet.

As a result, if you have configured your Storage account to allow access only from specific public IP addresses, it won't align with which IP is actually logged or used for access control when private connectivity is involved.

If you want Azure Storage to recognize and log your public IP for access control, you need to:

• Avoid using private connectivity options like Service Endpoints or Private Endpoints.
• Ensure your VM or firewall egresses traffic directly to the internet using its dedicated public IP.
• Whitelist this public IP in the Storage account’s firewall and virtual network settings.

Once set up this way, Azure Storage will log the public IP and enforce access based on IP allow-listing correctly.

Alternatively, if you want to keep using private connectivity for better security, here’s what to know:

• Access control happens using virtual network and subnet rules instead of public IP allow-listing.
• Azure Storage will always log the internal private IP of your VM or firewall.
• You must configure the Storage account firewall to allow the virtual network or subnet that your VM/firewall belongs to.

To verify whether you are hitting a private endpoint, you can run the command:

nslookup <yourstorageaccount>.blob.core.windows.net

To resolve this issue and ensure the storage account correctly identifies the outbound public IP, the most reliable solution is to route traffic through a NAT Gateway or an Azure Firewall with SNAT enabled. This guarantees that all outbound traffic uses a consistent public IP address, which will then appear in logs and match firewall rules.

If you prefer to retain private connectivity for security purposes, avoid relying on public IP–based firewall rules. Instead, configure Virtual Network rules or use Private Endpoints along with Private DNS zones. These approaches are fully supported and documented under Azure NAT Gateway, Private Endpoint and DNS, and Storage Firewall and VNet rules.

Azure Storage Private Endpoints https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints

Troubleshoot Azure Private Endpoint DNS issues https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns

Configure network rules for Azure Storage https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security-guide

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hello Apurva Pathak,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure Storage Account access logs CallerIpAddress is showing Private IP Address.

This happens because when you use Service Endpoints or Private Endpoints, traffic flows through Azure’s internal backbone network, and the storage service logs the VM’s private IP by design. Therefore, even if you whitelist the public IP, the request will still be blocked since the logged source remains private.

To resolve this and ensure the storage account recognizes the public IP, the most reliable approach is to route traffic through a NAT Gateway or Azure Firewall with SNAT enabled. This forces outbound traffic to use a designated public IP, which will appear in the logs and align with firewall rules. If you prefer to maintain private connectivity for security reasons, you should avoid relying on public IP-based firewall rules and instead configure Virtual Network rules or Private Endpoints with Private DNS zones. These methods are documented here: Azure NAT Gateway, Private Endpoint and DNS, and Storage Firewall and VNet rules.

Finally, if your compliance or monitoring requirements demand public IP logging, you must disable Service Endpoints and Private Endpoints and allow public network access through a controlled NAT Gateway. Alternatively, for hybrid setups, use Azure Firewall or Application Gateway to manage SNAT and enforce outbound traffic policies. This ensures accurate CallerIpAddress logging while maintaining security. For implementation, see these docs on Configure NAT Gateway for subnets and Azure Firewall SNAT.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.